[
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: [email protected]
For additional commands, e-mail: [email protected]
