Oh, yes — I commonly use it in API designs (though I’m not checking on the RFC to see if I’m aligned with it). The QUERY verb is standard on any collection resource and acts like a filtered GET, taking a payload and returning the same response signature as GET.

I don’t (haven’t yet) worked with etags for QUERY, but have been using Prefer respond-async to implement async queries for large sets (and do paging of them with Range requests).

The “stay within the lines” way of designing APIs is getting a bit long of tooth in my opinion.

* QUERY is non destructive/idempotent. Hmmm. Bye bye UPDATE FOO set values(x=z) where id = foo. Seems limiting. * All existing methods for userland data exchange are CRUD adjacent (options/connect/etc are more protocoly). QUERY is a bit of an outlier. Im not against having a bulk “R”ead operation, but its kind of already GET, just suffers the payload problems mentioned.

How about GET /foo -H x-query: serialized_query instead?

Have definitely needed it!

Looks like it might move forward

https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...