[ 
https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14385243#comment-14385243
 ] 

Ramkumar Aiyengar commented on SOLR-7312:
-----------------------------------------

I agree there is at least a documentation bug here. If we have determined that 
a REST API is not suited for Solr, that's fine, but REST means something and 
has certain requirements, we shouldn't be misleading users by claiming 
something is REST when it is not.

That said, I don't understand any of the objections to REST as well. Noble, 
could you point us to any discussion on this, or provide us with concrete 
examples on how a REST API for an operation would have any of the drawbacks you 
mention, while what Solr has doesn't?

> "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

Reply via email to