Consider a web service that exposes a /search endpoint. Any operation on that endpoint would be a good candidate for the GET method as it would be idempotent. The complexity of the search parameters however may result in extremely long URLs that may not be handled properly (despite the RFC not specifying a hard limit) by the client, the proxies, or even the server.
So the only alternative would be to use POST and pass the search criteria in the body of the request. It wouldn't be a big deal if it it wasn't for the fact that the response is now not cacheable: it is not possible to define it's cacheability on the basis of its URL, some of the headers (Accept) and the full body (where the actual search criteria are).
Am I right in thinking that HTTP/1.1 is lacking in this respect and there is no elegant and simple solution to the problem?
Thanks
Do a deterministic calculation (like a hash or MD5) on the specific pieces of information that are applicable, then append the outcome on a query string, like ?cachekey=1ee68acc7122be75743ea04544462dad. As long as the calculation is deterministic, you can check for a consistent result in the cache, based on the key.