Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The HTTP Query Method

ietf.org

Post reply on HN
Print view View original

41–50 of 136 posts

Re: The HTTP Query Method

#41

Post by venturecruelty »

thayne wrote: post #30
gbear605 wrote: post #25

At this point I’m infamous in my company for complaining about how something should have been done with a QUERY verb but it hasn’t been approved yet. The cases tend to look like this: - An endpoint was implemented as a GET endpoint, since it’s for getting data, with the search terms in the query parameters. The search term got too long, breaking a critical behavior in production environments. - An endpoint was implem…

Also cases where a GET makes more sense, but there is concern about sensitive data in query parameters getting exposed in logs, so POST is used instead.

You can always configure your HTTP logger to not log query parameters.

Re: The HTTP Query Method

#42

Post by [deleted] »

happytoexplain wrote: post #7
Veserv wrote: post #6

Earlier quoted context omitted.

The problem is that they are not enforced. You can already have GET requests that modify state even though they are not supposed to. What you are actually doing when making a specific kind of request is assuming the actual properties match the documented properties and acting accordingly. A QUERY seems to be no more than a POST that documents it is idempotent. Furthermore, you should only QUERY a resource that has ad…

I'm confused - wouldn't idempotent POST be PUT? Isn't the proposed QUERY for fetching semantics?

[deleted]

Re: The HTTP Query Method

#43

Post by tough »

clickety_clack wrote: post #32

It’s rare that I have a project that justifies the full DDD treatment, but one of the great ideas from it that stuck with me was command/query separation, where you separate out queries, which can be mangled agglomerations of objects for reporting and lists, from commands, which drive your business logic. I love the idea of a separate verb. It always felt like get is just not quite enough.

CQRS

Re: The HTTP Query Method

#44

Post by LudwigNagasena »

bruce511 wrote: post #37
resonious wrote: post #26

Earlier quoted context omitted.

Very timely as I just recently ended up with a URL query string so big that CloudFront rejected the request before it even hit my server.. Ended up switching that endpoint to POST. Would've liked QUERY for that!

I have come across systems that use GET but with a payload like POST. This allows the GET to bypass the 4k URL limit. It's not a common pattern, and QUERY is a nice way to differentiate it (and, I suspect will be more compatible with Middleware). I have a suspicion that quite a few servers support this pattern (as does my own) but not many programmers are aware of it, so it's very infrequently used.

Sending a GET request with a body is just asking for all sorts of weird caching and processing issues.

Re: The HTTP Query Method

#45

Post by notatoad »

Veserv wrote: post #6
platzhirsch wrote: post #3

Earlier quoted context omitted.

I might be misunderstanding something, but it seems the issue isn't really about whether GET can technically carry a body. The deeper concern is that HTTP methods have specific meanings, and mixing those signals can causes confusion and it's nice to have this semantic separation.

The problem is that they are not enforced. You can already have GET requests that modify state even though they are not supposed to. What you are actually doing when making a specific kind of request is assuming the actual properties match the documented properties and acting accordingly. A QUERY seems to be no more than a POST that documents it is idempotent. Furthermore, you should only QUERY a resource that has ad…

HTTP semantics aren’t hard enforced but that only means something if you always control the client, server, and all the middle layers like proxies or CDNs that your traffic flows over.

Your GET request can modify state. But if your request exceeds a browser’s timeout threshold, the browser will retry it. And then you get to spend a few days debugging why a certain notification is always getting sent three times (ask me how I know this)

Similarly, you can put a body on your GET request in curl. But a browser can’t. And if you need to move your server behind cloudflare one day, that body is gonna get dropped.

Re: The HTTP Query Method

#46

Post by nhumrich »

8cvor6j844qw_d6 wrote: post #29

For the experienced devs. May I ask why would one use POST for everything? I encountered a codebase with only POST for all operations, given my lack of knowledge in this area, I am not sure why one would choose POST only over the standard set of GET, PUT, POST, DELETE, etc.

I prefer POST for everything. The main reason why is because HTTP verbs don't match cleanly to every operation. And it leads to a lot of bike shedding around the exceptions. POST for everything, on the other hand, forces you to put the "method" in the request outside of HTTP semantics, which allows you to "just use" whatever verb makes sense rather than trying to map it to the limited ones available.

Re: The HTTP Query Method

#47

Post by LudwigNagasena »

8cvor6j844qw_d6 wrote: post #29

For the experienced devs. May I ask why would one use POST for everything? I encountered a codebase with only POST for all operations, given my lack of knowledge in this area, I am not sure why one would choose POST only over the standard set of GET, PUT, POST, DELETE, etc.

Consistency, simplicity, RPC semantics.

Re: The HTTP Query Method

#48

Post by dragonwriter »

happytoexplain wrote: post #7
Veserv wrote: post #6

Earlier quoted context omitted.

The problem is that they are not enforced. You can already have GET requests that modify state even though they are not supposed to. What you are actually doing when making a specific kind of request is assuming the actual properties match the documented properties and acting accordingly. A QUERY seems to be no more than a POST that documents it is idempotent. Furthermore, you should only QUERY a resource that has ad…

I'm confused - wouldn't idempotent POST be PUT? Isn't the proposed QUERY for fetching semantics?

Essentially correct, QUERY is safe, like GET, not merely idempotent, like PUT. Safety implies idempotence, but not vice versa.

Re: The HTTP Query Method

#49

Post by ghxst »

venturecruelty wrote: post #41
thayne wrote: post #30

Earlier quoted context omitted.

Also cases where a GET makes more sense, but there is concern about sensitive data in query parameters getting exposed in logs, so POST is used instead.

You can always configure your HTTP logger to not log query parameters.

From a security perspective it is best to assume everything in a GET query is public, it's not always your server logs that you have to worry about, it could also be logs on the clients system (as an example).

Re: The HTTP Query Method

#50

Post by RedShift1 »

8cvor6j844qw_d6 wrote: post #29

For the experienced devs. May I ask why would one use POST for everything? I encountered a codebase with only POST for all operations, given my lack of knowledge in this area, I am not sure why one would choose POST only over the standard set of GET, PUT, POST, DELETE, etc.

The default for GraphQL queries is POST so maybe they were using that.
Post reply on HN