3 ms·

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 y

by koolala 4mo ago

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?

dreambigwrkhard 4mo ago
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 4mo ago
  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.
  - topham 4mo ago
    Fixing GET would be easier. And yes,it would be fixing a flawed interpretation of what should be implemented.you are, by definition GETting something. Tools dropping body from GET by default are violating the spec today. Rules configured to drop it are just that, temporarily configured constraints readily modified. Adding QUERY will make it unpredictable in effectively the same manner as GET/body. It'll take even longer to resolve it though.
    - Yokohiii 4mo ago
      > Fixing GET would be easier. I disagree. I think the adoption (or dismissal) of QUERY will show. First thing that comes to mind is that the idempotency of GET resources are easy to handle. URL's have a fixed size, they can be efficiently hashed, cached and are unambiguous about how they serve this purpose. It is unclear how the ecosystem will deal with the QUERY requirements. It's easy for apps, but browsers, http caches and servers will take some time to figure out solutions. Fixing GET would have the same amount of uncertainty in addition to the need to keep current expectations valid. It's not easier, it's harder.
      - topham 4mo ago
        Browsers won't. No, really, they simply won't implement it.
        Yokohiii 4mo ago
        Okay, great.
        koolala 4mo ago
        Did they say why? I kinda thought that was the main point.
  - dreambigwrkhard 4mo ago
    that's a legit use case. thanks for the info!
miggol 4mo ago
Considering the guideline that QUERY should be idempotent and cacheable, file querying requests come to mind. Reverse image search, for example.
CommonGuy 4mo ago
GraphQL implementations could switch to this
pmontra 4mo ago
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.
victorbjorklund 4mo ago
Graphql?

by koolala 4mo ago

dreambigwrkhard 4mo ago

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 4mo ago
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.
- topham 4mo ago
  Fixing GET would be easier. And yes,it would be fixing a flawed interpretation of what should be implemented.you are, by definition GETting something. Tools dropping body from GET by default are violating the spec today. Rules configured to drop it are just that, temporarily configured constraints readily modified. Adding QUERY will make it unpredictable in effectively the same manner as GET/body. It'll take even longer to resolve it though.
  - Yokohiii 4mo ago
    > Fixing GET would be easier. I disagree. I think the adoption (or dismissal) of QUERY will show. First thing that comes to mind is that the idempotency of GET resources are easy to handle. URL's have a fixed size, they can be efficiently hashed, cached and are unambiguous about how they serve this purpose. It is unclear how the ecosystem will deal with the QUERY requirements. It's easy for apps, but browsers, http caches and servers will take some time to figure out solutions. Fixing GET would have the same amount of uncertainty in addition to the need to keep current expectations valid. It's not easier, it's harder.
    - topham 4mo ago
      Browsers won't. No, really, they simply won't implement it.
      - Yokohiii 4mo ago
        Okay, great.
      - koolala 4mo ago
        Did they say why? I kinda thought that was the main point.
- dreambigwrkhard 4mo ago
  that's a legit use case. thanks for the info!

miggol 4mo ago

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

CommonGuy 4mo ago

GraphQL implementations could switch to this

pmontra 4mo ago

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.

victorbjorklund 4mo ago

Graphql?