[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14387595#comment-14387595 ]
Noble Paul commented on SOLR-7312: ---------------------------------- bq.I think we should aim for true REST for all Admin APIs in the future. I guess the discussion here was not about admin APIs. This probably was about the schema and config APIs. I have given my reasons why they are done this way. I believe true "REST" or true "any standard" is a huge ball and chain. The practitioners of the standard will come to hunt you down the moment we make small deviation. bq.Perhaps we should also disallow GET calls to the {{/update}} handler by default? I'm +1 to disallow GET for write APIs. But that is not "pure REST" . I don't have the energy or time to modify all our existing APIs to satisfy any standards . But I can spend time for making them easier or more secure > "REST" API is not REST > ---------------------- > > Key: SOLR-7312 > URL: https://issues.apache.org/jira/browse/SOLR-7312 > Project: Solr > Issue Type: Improvement > Components: Server > Affects Versions: 5.0 > Reporter: Mark Haase > Assignee: Noble Paul > > The documentation refers to a "REST" API over and over, and yet I don't see a > REST API. I see an HTTP API but not a REST API. Here are a few things the > HTTP API does that are not RESTful: > * Offers RPC verbs instead of resources/nouns. (E.g. schema API has commands > like "add-field", "add-copy-field", etc.) > * Tunnels non-idempotent requests (like creating a core) through idempotent > HTTP verb (GET). > * Tunnels deletes through HTTP GET. > * PUT/POST confusion, POST used to update a named resource, such as the Blob > API. > * Returns `200 OK` HTTP code even when the command fails. (Try adding a field > to your schema that already exists. You get `200 OK` and an error message > hidden in the payload. Try calling a collections API when you're using > non-cloud mode: `200 OK` and an error message in the payload. Gah.) > * Does not provide link relations. > * HTTP status line contains a JSON payload (!) and no 'Content-Type' header > for some failed commands, like `curl -X DELETE > http://solr:8983/solr/admin/cores/foo` > * Content negotiation is done via query parameter (`wt=json`), instead of > `Accept` header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org