[
https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382264#comment-14382264
]
Mark Haase commented on SOLR-7312:
----------------------------------
Hey Paul, I support the idea of changing the docs. `s/REST API/HTTP API/g`
would be a fine start.
I don't want to start an argument about what REST means and whether Solr should
have a RESTful interface, but most of your reasons for not having it aren't
great reasons.
It's not a standard. Think of REST as a set of properties for API design (in
the abstract, not necessarily just APIs implemented on HTTP). Of course, like
any word that doesn't have standardized meaning, REST also means differnet
things to different people. Solr isn't the first project to misuse the word by
any means. (Many people seem to think REST API is synonymous with HTTP API, but
it's not. If it was, that would imply that SOAP-over-HTTP == REST, which is
false.)
* You can certainly have bulk "commands", except that "command" isn't the right
word in a resourceful API. You could post an array of schema fields to the
schema collection, and that would be a RESTful way to add multiple fields in a
single transaction.
* You can also have RESTful transactions. Instead of thinking of transactions
as verbs with statefulness ("START TRANSACTION"...."COMMIT"), think of the
transaction as a resource itself.
* I don't understand the comment about "different payload for unix, windows,
web interface." Do you mean the request body? Why would that change on
different platforms? How does RPC payloads differently than REST?
* I also don't know what you mean about "interlacing shell commands". That's
completely orthogonal to REST vs RPC...
Again, I'm not saying "Solr should do this." I realize that Solr/Lucene is a
huge project with finite resources and this probably isn't a high priority,
otherwise I wouldn't be the first to report it. I just want to correct the
misperception that REST isn't practical "from an ops point of view". For
example, Microsoft Azure has a RESTful API for managing infrastructure:
https://msdn.microsoft.com/en-us/library/azure/jj157206.aspx.
> "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
