There is a deeper reason. We realised REST is not efficient for a lot of
operations. So, we deliberately avoided it
On Mar 26, 2015 12:13 AM, "Shai Erera (JIRA)" <j...@apache.org> wrote:

>
>     [
> https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14381484#comment-14381484
> ]
>
> Shai Erera commented on SOLR-7312:
> ----------------------------------
>
> How about changing the API to actually conform to RESTful? ;)
>
> I know it would be a huge change (therefore trunk only I believe), just
> wondering if there is a reason for the current API, where modifying actions
> are allowed via GET as well. Is it for convenience reasons only, or is
> there a deeper one?
>
> > "REST" API is not REST
> > ----------------------
> >
> >                 Key: SOLR-7312
> >                 URL: https://issues.apache.org/jira/browse/SOLR-7312
> >             Project: Solr
> >          Issue Type: Bug
> >          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