Hacker News Reader

Comment by hcarvalhoalves | Hacker News Reader

    Right now, you have two main options:
    
    Use a GET, and squeeze all the parameters you need in the URL or headers somewhere
    Use a POST, and have the request considered as unsafe & uncacheable

Third option: you POST or PUT to a resource representing the search, then you’re free to redirect and subsequently GETs of this resource can be cached.

Wanting a special method for search hurts the conceptual integrity of HTTP, where resource representation is the core idea to build on top, it isn’t supposed to be just a request/response protocol.

View on HN

That's exactly what we do: submitting a search/filter form through a POST request which creates a record in the database representing the search/filter criteria and then redirects to the same endpoint with the ID of that record. The endpoint looks for the ID in the query, attempts to load the same record, and if found, executes and returns the search results.

It works very well, is completely transparent to the end user, has automatic query logging, and provides a clean URL that can be easily shared.

I really wish I'd thought of this method when I was building a search based application. It was my first time and I struggled with structuring everything

> POST or PUT to a resource representing the search, then you’re free to redirect and subsequently GETs of this resource can be cached.

But that only means that specific instance of the search query is cacheable, not the search query itself, no? I presume the POST would create a new identifier for the resource, so that yes, that specific resource is cacheable. (Even if the server says "oh, I've just seen this POSTed query, let me return the same resource ID", another client will still have to POST to the server, a non-cacheable action.)

The idea of cacheable isn't just by the server, but by anything in between the client and the resource. By using QUERY, the query itself can be cached.

Reply on news.ycombinator.com