[
https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14388463#comment-14388463
]
Shai Erera commented on SOLR-7312:
----------------------------------
I find REST a little bit like AGILE - you take what suits you most. You
definitely shouldn't bend the code (or yourself) to be "truly agile" and/or
"truly REST". Therefore I care less about people coming and say "this isn't
pure REST". REST is a standard and there are many debates about it, e.g. the
difference between a PUT and POST.
We should do whatever we feel is right. One thing I would love to see is not
being able to modify *any* state of Solr via GET calls. That alone would be
great progress (just my opinion though).
Also, I definitely don't think we should change all the API at once. We can do
that incrementally, taking care of one segment/area at a time. E.g. the
Collections API can certainly look like:
{noformat}
curl -X POST http://localhost:8983/solr/collections/create?name=mycollection&;...
curl -X DELETE http://localhost:8983/solr/collections/mycollection
...
{noformat}
With that we take out the 'action' parameter and fold it either into the Http
method or if we want to use a single method (e.g. POST) for multiple actions,
we put the command as part of the URL (/create).
I also don't advocate that we become fanatic about it. If DELETE is not
convenient because we want to send additional parameters, we can make it a POST
with a /delete path, although I think we shouldn't have problems w/ DELETE
specifically.
> "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
