Hacker News new | ask | show | jobs
by cortesoft 195 days ago
If you look at the summary table, the only difference between a GET and a QUERY is that the query can have a body. Other than that, they have the exact same characteristics and purpose, so there isn’t really a need to semantically separate them.
1 comments
locknitpicker 195 days ago
> If you look at the summary table, the only difference between a GET and a QUERY is that the query can have a body. Other than that, they have the exact same characteristics and purpose, so there isn’t really a need to semantically separate them.

This is outright false. RFC9110, which clarifies semantics of things like GET requests, is clear on how GET requests should not have request bodies because it both poses security issues and breaks how the web works.

Just because your homemade HTTP API expects a GET request packs a request body, that does not mean any of the servers it hits between your client and your server will. Think about proxies, API gateways, load balancers, firewalls, etc. Some cloud providers outright strip request bodies from requests.

The internet should not break just because someone didn't bothered to learn how HTTP works. The wise course of action is to create a new method with specific semantics that are clear and actionable without breaking the world.

link
cortesoft 195 days ago
I think you are confusing what I am saying. I am saying the rest of the semantics are the same, other than the body. If we are creating a new HTTP spec, we could give GET and QUERY be the same because they serve the same semantic purpose.

Obviously you can’t just start putting bodies in GET requests, because it breaks the current spec.

link
locknitpicker 194 days ago
> I think you are confusing what I am saying. I am saying the rest of the semantics are the same, other than the body.

This is fundamentally wrong. The semantics are not the same, regardless of whether there's even a request body or not. The semantics are completely different. One is safe and idempotent, whereas the other is neither safe nor idempotent. The presence of a body doesn't even register as a factor.

> If we are creating a new HTTP spec

Also wrong. It's all about specifying another HTTP verb. HTTP is already specified to support other verbs.

> we could give GET and QUERY be the same because they serve the same semantic purpose.

QUERY is a GET that is designed to pass query parameters in request bodies, which GET explicitly does not support. They are separate operations which just so happen to be both safe and idempotent.

link