The HTTP QUERY Method in Fiber v3: Searches With a Body
Search endpoints have a way of outgrowing their URLs. The filters start small, ?category=shoes&max_price=150, and then product asks for multi-select categories, tag combinations and price ranges, maybe a saved filter that a dashboard sends verbatim. Eventually the query string is an encoded JSON blob that nobody can read in the access log, and someone moves the endpoint to POST /search.
POST works, but it describes the request wrongly. It tells every layer between client and server that the request might change state. Shared caches practically never store POST responses, clients and proxies should not replay it on their own after a dropped connection, and your CSRF middleware demands a token for what is really a read. The IETF has now published RFC 10008, which defines a dedicated QUERY method: safe and idempotent like GET, but with a request body. Fiber has supported it as a first-class verb since v3.4.0, released in July.
This post builds a product search on QUERY with Fiber v3.5.0, caches it properly, and walks through the places where the new method interacts with middleware you already run. Two of them can serve one user's results to another if you are not careful.
