[jira] [Commented] (SOLR-7312) REST API is not REST
[
https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14388484#comment-14388484
]
Noble Paul commented on SOLR-7312:
--
As I mentioned earlier, I'm +1 for making all write operations use POST/PUT.
Especially the collection API.
We can make the default setting to be to allow GET and use a flag to disable
GET.
{noformat}
curl -X POST http://localhost:8983/solr/collections/create?name=mycollection;...
#and
curl -X POST http://localhost:8983/solr/collections/delete?name=mycollection
{noformat}
can be easily implemented now in a backcompat way
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
[jira] [Commented] (SOLR-7312) REST API is not REST
[
https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14388669#comment-14388669 ] Mark Haase commented on SOLR-7312: -- The curmudgeonly bonbon learns a hard lesson from a dilettante. Another clock beyond the stalactite secretly admires a womanly trombone. The gonad for the bicep usually hosts the cigar. A darling hand hibernates, and the pocket defined by a cigar goes to sleep; however, the amour-propre ridiculously plays pinochle with some knowingly self-actualized swamp. 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
[jira] [Commented] (SOLR-7312) REST API is not REST
[
https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7312) REST API is not REST
[
https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14387542#comment-14387542
]
Jan Høydahl commented on SOLR-7312:
---
I think we should aim for true REST for all Admin APIs in the future. Users may
perhaps need to send more requests to do the same thing but that's a minor
problem. Overloading a single POST request with internal command verbs does not
feel right. It's not really hard to design the APIs so that there is a way to
avoid reload after every request.
Perhaps we should also disallow GET calls to the {{/update}} handler by default?
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
Re: [jira] [Commented] (SOLR-7312) REST API is not REST
Yes, we should change the documentation On Mar 29, 2015 6:35 AM, Mark Miller (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385609#comment-14385609 ] Mark Miller commented on SOLR-7312: --- I've always described Solr as REST Like with a grin ;) 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
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385609#comment-14385609 ] Mark Miller commented on SOLR-7312: --- I've always described Solr as REST Like with a grin ;) 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
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383278#comment-14383278 ] Noble Paul commented on SOLR-7312: -- We are not saying the GET for write is good. But conforming to pure REST is much more . We need to make things 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 TRANSACTIONCOMMIT), 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
[jira] [Commented] (SOLR-7312) REST API is not REST
[
https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382197#comment-14382197
]
Noble Paul commented on SOLR-7312:
--
bq.How about changing the API to actually conform to RESTful?
The choice was deliberate. pure REST was inconvenient and inefficient for those
commands . We needed bulk commands
* editing the schema/config would result in core reload and doing one at a time
means more reloads
* We need to ensure that the editing process is transactional. If I wish to do
10 operations all 10 must either succeed or fail. Partial success is not useful
* Using REST means different payload for unix, windows , web interface
* REST means you are interlacing shell commands in your payload curl etc.
Which means someone really has to verify if you are performing anything risky
because mostly the ops run commands as {{su}}
To be honest the REST paradigm is terrible from an ops point of view . We
should follow standards only if it helps our users
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
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382293#comment-14382293 ] Mark Haase commented on SOLR-7312: -- I will argue, though, that this is not a wish or an improvement. The documentation is buggy. It doesn't fail any unit tests or lints like broken code, _but the documentation is broken_. This is a bug. 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
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382348#comment-14382348 ] Noble Paul commented on SOLR-7312: -- if you are asking if we could bend ourselves backwards and satisfy the REST standard? probably yes . And we will be able to do nothing more than we already do with the current set of APIs. So , the value add is questionable for an average Solr user 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
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382390#comment-14382390 ] Uwe Schindler commented on SOLR-7312: - A very funny example why this is also horrible: http://www.thetaphi.de/nukeyoursolrindex.html This link will delete/remove your Solr Index (you need 4.x, because this relies on the default collection if you issue requests without a collection) running on localhost by a GET command, which is a HTML IMG link in the HTML page :-) I think the reason is just historical. When Solr was developed it was not designed to be REST - I think the term was not even defined at that time. 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
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382421#comment-14382421 ] Mark Haase commented on SOLR-7312: -- IT's not just a prank, either, this was a real problem for web accelerator programs: http://betanews.com/2005/05/06/google-web-accelerator-draws-concern/ Google's product has been discontinued, but there are still proxies out there that speculatively prefetch. I hope you don't access your Solr admin panel through a proxy :) 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
[jira] [Commented] (SOLR-7312) REST API is not REST
[
https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14382374#comment-14382374
]
Mark Haase commented on SOLR-7312:
--
You must not have read my entire message, so let me put this in bold:
{quote}
*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*
{quote}
But the docs are buggy. They use a term that is incorrect. This is akin to
misspelling a word over and over in the documentation and then claiming, oh we
don't like to use that word anyway. _Then remove it!_
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
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
Re: [jira] [Commented] (SOLR-7312) REST API is not REST
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-tabpanelfocusedCommentId=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
Re: [jira] [Commented] (SOLR-7312) REST API is not REST
You didn't put that comment on the issue, just in case you forgot. Can you point me to some discussions? I don't advocate for or against making Solr APIs fully RESTful, just curious about the details. Shai On Thu, Mar 26, 2015 at 9:15 AM, Noble Paul noble.p...@gmail.com wrote: 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-tabpanelfocusedCommentId=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` 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
[jira] [Commented] (SOLR-7312) REST API is not REST
[ https://issues.apache.org/jira/browse/SOLR-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381378#comment-14381378 ] Noble Paul commented on SOLR-7312: -- Yes, it is not a REST API. May be the doc needs some changes. 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 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
