QUERY http verb just landed in RFC 10008 standard. It solves a couple real issues. 1.
GET request bodies are not standardized across the web, any server/proxy/middleware decides what to do with it, and in most cases your GET bodies don't reach the sever.2. This is just side effect of 1. That we're forced to cram everything into search params, there's (a) encoding instabilities and (b) length limits.
3.
POST requests that we're using to send bodies for fetching resources can't be safely cached, and retried.QUERY declares itself as safe and idempotent, it adds standard body to request that everyone who's implementing it must support. And your body can be of any type, as long as you supply/respect server's Accept-Query and send proper Content-Type. RFC states the cache key must incorporate URI, request body and it's Content-Type.Moreover, to a
QUERY request server can return headers Content-Location and Location. Content-Location is where results of your specific request are kept, and query is NOT re-executed on subsequent calls. Whereas Location is for re-runnig the query without sending the whole body for fresh data. You should be able to safely GET both locations.Standard explicitly mentions not to use it for simple queries and encourages to rely on it once industry catches up.
Read the spec.
@qishloqi_dev
