4 ms·

This paragraph is the key: > The QUERY method provides a solution that spans the gap between the use of GET and POST. As with POST, the input to the query oper

This paragraph is the key: > The QUERY method provides a solution that spans the gap between the use of GET and POST. As with POST, the input to the query operation is passed along within the content of the request rather than as part of the request URI. Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate.

TYPE_FASTER 2y ago
Yes. I was skeptical at first. Why add another method? This explains why.
- solardev 2y ago
  GraphQL reads are like that. You POST a query with the content inside the request body. This would be a nicer verb for it.
  - ako 2y ago
    OData provides GraphQL functionality but using GET + URL parameters, for large queries it's really hard to read or edit. Using the request body makes sense for readability, so OData also offers the option to query with POST + request body.
nonethewiser 2y ago
But doesn't this beg the question: why not GET with query params? I'm not necessarily against it - I've had the urge to send a body on a GET request before (cant recall or justify the use-case, however). Reasons I can think of: - browsers limit url (and therefore) query param size - general dev ergonomics The practical limits (ie, not standard specified limits) on query param size seems fair but its worth mentioning there are practical limits to body size as well introduced by web servers, proxies, cloud api gateways, etc or ultimately hardware. From what I can see this is something like 2kb for query params in the lower end case (Chrome's 2083 char limit) and 10-100mb (but highly variable and potentially only hardware bound) for body size. In both cases it's worth stating that the spec is being informed by practical realities outside of the spec. In terms of the spec itself, there is no limit to either body size or query param length. How much should the spec be determined by particular implementation details of browsers, cloud services, etc.?
- nine_k 2y ago
  Size can be a very practical concern if your query parameter is e.g. a picture. Not showing the URL in various logs can be a concern if your query parameters are sensitive.
  - nonethewiser 2y ago
    A picture as an input for a GET seems like a very strange use-case. Can you elaborate? I do agree on the quirkiness of encoding a bunch of data in the URL. Its nice to decouple the endpoint from the input at a more fundamental level.
    - bakje 2y ago
      Use cases like reverse image search come to mind
- treve 2y ago
  With a request body you can also rely on all the other standard semantics that request bodies afford, such as different content-types, content encoding. Query parameters are also often considered less secure for things like PII and (less important these days) query parameters don't really define character encoding. But generally the most important reason is that you can take advantage of the full range of mimetypes, and yes practicality speaking there's a limit on how much you should stuff in a query parameter. This has resulted in tons of protocols using POST, such as GraphQL. This is a nice middle ground.
- chrsig 2y ago
  Servers have to limit header size as well, since content-length isn't available. Without a bounded header size the client can just send indefinitely. Also just impossible to read, and url encoding is full of parser alignment issues. I have to imagine that QUERY would support a json request body.
- MBCook 2y ago
  This avoid changing the definition of GET. Who knows how many middle boxes would mess with things if you did that because they “know” what GET means and so their thing is “safe”. Until GET changes. People aren’t using QUERY yet so that problem doesn’t exist.
TacticalCoder 2y ago
> Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate. A shitload of answers to GET requests, although cacheable, are stale though. If you issue a GET for a page which contains stuff like "Number of views: xxx" or "Number of users logged in: yyy" or "Last updated on: yyyy-mm-dd" there goes idempotency. Some GET requests are actually idempotent ("Give me the value of AAPL at close on 2021-07-21") but many aren't. Stale data won't break much but there's a world between "it's an idempotent call" and "I'm actually likely to be seeing stale data if I'm using a cached value". I mean... Enter in you browser "https://example.org https://example.org", that's a GET. And that's definitely not idempotent for most sites we're all using on a daily basis.
- stackghost 2y ago
  I suppose the counterargument is that "users logged in" or "views" is stale all the time, because it could have changed while the response was in flight. If you really need live data for "views" or what have you, then perhaps the front end should be querying the backend repeatedly via a separate POST.
- Timon3 2y ago
  Idempotency in the context of HTTP requests isn't about the response you receive, but about the state of the resource on the server. You're supposed to be able to call GET /{resource}/{id} any amount of times without the resource {id} being different at the end. You can't do the same for POST, as POST /{resource} could create a new entity with every call. A view counter also doesn't break this, as the view counter isn't the resource you're interacting with. As long as you're not modifying the resource on a `GET` call, the request is idempotent.
  - kbolino 2y ago
    Strictly speaking, an inline view counter, which is incremented on each GET and included in the response, would break idempotence. Similarly, a PUT request that implicitly modifies a "last updated" field would also break idempotence. These are pretty minor violations, though, which arguably don't change any "semantics" of the response.

TYPE_FASTER 2y ago

Yes. I was skeptical at first. Why add another method? This explains why.

solardev 2y ago
GraphQL reads are like that. You POST a query with the content inside the request body. This would be a nicer verb for it.
- ako 2y ago
  OData provides GraphQL functionality but using GET + URL parameters, for large queries it's really hard to read or edit. Using the request body makes sense for readability, so OData also offers the option to query with POST + request body.

nonethewiser 2y ago

But doesn't this beg the question: why not GET with query params? I'm not necessarily against it - I've had the urge to send a body on a GET request before (cant recall or justify the use-case, however). Reasons I can think of: - browsers limit url (and therefore) query param size - general dev ergonomics The practical limits (ie, not standard specified limits) on query param size seems fair but its worth mentioning there are practical limits to body size as well introduced by web servers, proxies, cloud api gateways, etc or ultimately hardware. From what I can see this is something like 2kb for query params in the lower end case (Chrome's 2083 char limit) and 10-100mb (but highly variable and potentially only hardware bound) for body size. In both cases it's worth stating that the spec is being informed by practical realities outside of the spec. In terms of the spec itself, there is no limit to either body size or query param length. How much should the spec be determined by particular implementation details of browsers, cloud services, etc.?

nine_k 2y ago
Size can be a very practical concern if your query parameter is e.g. a picture. Not showing the URL in various logs can be a concern if your query parameters are sensitive.
- nonethewiser 2y ago
  A picture as an input for a GET seems like a very strange use-case. Can you elaborate? I do agree on the quirkiness of encoding a bunch of data in the URL. Its nice to decouple the endpoint from the input at a more fundamental level.
  - bakje 2y ago
    Use cases like reverse image search come to mind
treve 2y ago
With a request body you can also rely on all the other standard semantics that request bodies afford, such as different content-types, content encoding. Query parameters are also often considered less secure for things like PII and (less important these days) query parameters don't really define character encoding. But generally the most important reason is that you can take advantage of the full range of mimetypes, and yes practicality speaking there's a limit on how much you should stuff in a query parameter. This has resulted in tons of protocols using POST, such as GraphQL. This is a nice middle ground.
chrsig 2y ago
Servers have to limit header size as well, since content-length isn't available. Without a bounded header size the client can just send indefinitely. Also just impossible to read, and url encoding is full of parser alignment issues. I have to imagine that QUERY would support a json request body.
MBCook 2y ago
This avoid changing the definition of GET. Who knows how many middle boxes would mess with things if you did that because they “know” what GET means and so their thing is “safe”. Until GET changes. People aren’t using QUERY yet so that problem doesn’t exist.

TacticalCoder 2y ago

> Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate. A shitload of answers to GET requests, although cacheable, are stale though. If you issue a GET for a page which contains stuff like "Number of views: xxx" or "Number of users logged in: yyy" or "Last updated on: yyyy-mm-dd" there goes idempotency. Some GET requests are actually idempotent ("Give me the value of AAPL at close on 2021-07-21") but many aren't. Stale data won't break much but there's a world between "it's an idempotent call" and "I'm actually likely to be seeing stale data if I'm using a cached value". I mean... Enter in you browser "https://example.org https://example.org", that's a GET. And that's definitely not idempotent for most sites we're all using on a daily basis.

stackghost 2y ago
I suppose the counterargument is that "users logged in" or "views" is stale all the time, because it could have changed while the response was in flight. If you really need live data for "views" or what have you, then perhaps the front end should be querying the backend repeatedly via a separate POST.
Timon3 2y ago
Idempotency in the context of HTTP requests isn't about the response you receive, but about the state of the resource on the server. You're supposed to be able to call GET /{resource}/{id} any amount of times without the resource {id} being different at the end. You can't do the same for POST, as POST /{resource} could create a new entity with every call. A view counter also doesn't break this, as the view counter isn't the resource you're interacting with. As long as you're not modifying the resource on a `GET` call, the request is idempotent.
- kbolino 2y ago
  Strictly speaking, an inline view counter, which is incremented on each GET and included in the response, would break idempotence. Similarly, a PUT request that implicitly modifies a "last updated" field would also break idempotence. These are pretty minor violations, though, which arguably don't change any "semantics" of the response.