What do you think people will make the Query request body? Most everything will use this for JSON but it could be anything so what other interesting things do you think will go in there? Query 1 + 1 and get 2?

▲

victorbjorklund 6 minutes ago | parent | next [-]

Graphql?

▲

miggol 3 hours ago | parent | prev | next [-]

Considering the guideline that QUERY should be idempotent and cacheable, file querying requests come to mind. Reverse image search, for example.

▲

pmontra 2 hours ago | parent | prev | next [-]

We might start using QUERY for the search requests from our web app to our server, if nothing in the stack in between the app and our server side code does not drop the body. A JSON body beats the spaghetti arguments of most filters.

▲

CommonGuy 2 hours ago | parent | prev | next [-]

GraphQL implementations could switch to this

▲

dreambigwrkhard 4 hours ago | parent | prev [-]

I'm curious too. Unless the developer is really passionate about this I don't think a dev will risk (potential) compatibility issues or unexpected footguns to use this when the workarounds do seem to work quite well already. I just dont see the benefit but maybe it's because I am just not aware of a real world use case; happy to be corrected.

	▲	unilynx 4 hours ago \| parent [-]
		Elastic/Opensearch uses GET requests with a body for search, which is complicated or forbidden (not exactly sure) with the HTTP spec. Not all HTTP clients are willing to submit a body with a GET. So opensearch also allows you to POST search requests, but those are uncacheable QUERY would fit here perfectly - it's probably trivial for opensearch to add but it will take some time for clients to catch up.