Reputation: 1727
I have a heterogenous collections of resources on which I need to support multiple search criteria. Since there is a limit on the URL using the query string, I was thinking of implementing this using HTTP POST instead of GET
Hence instead of
HTTP GET /states/, HTTP GET /cities, HTTP GET /localities
I was thinking of implementing this as
HTTP POST /searchengine with the body as
{
"state" : "xxx",
"city": "yyy"
"locality", "zzz"
}
and return the result in response to the HTTP POST
My question is therefore if POST instead of GET is acceptable as RESTful?
And if search results can be sent in response to HTTP POST (with HTTP 200) or should the search results be indicated by the Location header (and with HTTP 3xx)?
Upvotes: 0
Views: 316
Reputation: 449
In my opinion, using a POST request for retrieving resources is not REST-ful. The semantic of POST requests is explained in RFC 7231 4.3.3 and none of the cases mentioned there are applicable to your use-case.
You should think about defining a new type of resource, e.g. something like search result. Regarding the length of the URI, have a look at RFC 7230 3.1.1 which talks about recommended request line lengths that senders and recipients should support. Going by your example I wonder if there is really a problem in your case.
Upvotes: 0
Reputation: 32758
Do what makes the most sense for your application.
Search results via HTTP GET
can be convenient because they allow for users to share those URLs (if necessary). But GET
does hit the query string limits that you mention.
If switching to HTTP POST
is what you need to do then so be it. There is no single technical answer to your question - one is not necessarily better or worse than the other.
Upvotes: 1