top | item 46093892

(no title)

flakes | 3 months ago

> unless I'm missing something I don't think a QUERY verb will change all that much here?

The semantics are important. GET APIs are expected to be safe, idempotent, and cache-friendly. When you are unable to use GET for technical reasons and move to POST, suddenly none of the infrastructure (like routers, gateways, or generic http libs) can make these assumptions about your API. For example, many tools will not attempt to put retry logic around POST calls, because they cannot be sure that retrying is safe.

Having the QUERY verb allows us to overcome the technical limitations of GET without having to drop the safety expectations.

discuss

badbotty|3 months ago

I like the safety aspect of QUERY. Having CDNs cache based off the semantics of the content might be a hard ask. I wonder if this might lead to a standards based query language being designed and a push for CDNs to support it. Otherwise you probably need to implement your own edge processing of the request and cache handling for any content type you care to handle.

arp242|3 months ago

Yes, I understand that. I'm just commenting on the "bookmarkable" aspect here, obviously.

vbezhenar|3 months ago

You can just use body with GET. QUERY is redundant.

flakes|3 months ago

You can, and that is mentioned in RFC 9110... along with the cons for doing so.

> Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

QUERY is a new option to help avoid some of those downsides.

https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.1