Is it acceptable to implement a multiple search criteria query using POST instead of GET?

Question

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)?

Answer 1

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.

Answer 2

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.