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

51–60 of 136 posts

Re: The HTTP Query Method

#51

Post by gaigalas »

nhumrich wrote: post #46
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.

GET: I want to see stuff.

POST: I want to change stuff.

I don't know how this style cannot match cleanly any architecture.

It's not supposed to be a map to CRUD, it's a bunch of building blocks for manipulating state over a network.

Re: The HTTP Query Method

#52

Post by simonkagedal »

dragonwriter wrote: post #48
happytoexplain wrote: post #7

Earlier quoted context omitted.

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.

Does “safe” here mean just “non-mutating”?

Re: The HTTP Query Method

#53

Post by dragonwriter »

simonkagedal wrote: post #52
dragonwriter wrote: post #48

Earlier quoted context omitted.

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

Does “safe” here mean just “non-mutating”?

No, it doesn't just mean that (it does mean non-mutating from the point of view of the client and in regard to the target resource, but the essential meaning involves more than that and it is more subtle than simply “non-mutating”.)

The specific definition is in the HTTP spec, and I don't think I can describe it more concisely without losing important information necessary for really understanding it.

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

Re: The HTTP Query Method

#54

Post by zvrba »

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.

Because with POST you have a RPC (remote procedure call) with arbitrary semantics and HTTPS is just a convenient transport.

That's also why I only use a couple of status codes: Ok, Created, NoContent, BadRequest, Forbidden, Unauthorized an InternalServerError (the latter two generated automatically by the framework).

GET, PUT, DELTE, etc. seem to be tailored towards entities, but as soon as the endpoint is not an "entity", the semantics get vague and break down.

Re: The HTTP Query Method

#55

Post by badbotty »

flakes wrote: post #36
arp242 wrote: post #12

Earlier quoted context omitted.

The situations where I've wished for GET to be able to have a (typically JSON) body were all in situations where the request isn't "user visible" in the first place. That is: API calls, SPA apps, ajax requests, that sort of thing. Not something people are really supposed to bookmark or call directly. If today you're doing some JS-fu to make an ajax GET request then you already need to do something to have permalinks…

> 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 attem…

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.

Re: The HTTP Query Method

#56

Post by dragonwriter »

johncolanduoni wrote: post #11
happytoexplain wrote: post #7

Earlier quoted context omitted.

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

For some reason the RFC focuses on idempotency, but then says it's explicitly intended for enabling caching semantics. Caching a query that mutates visible state doesn't really make sense, and like you point out if you just want idempotent modifications PUT already has the relevant semantics. I guess we haven't learned our lesson from making the original HTTP semantics super squishy.

> For some reason the RFC focuses on idempotency,

It focuses on a bit more on safety, which is why every mention of it the proposed method having the "idempotent" property is immediately preceded (in most cases in the same sentence) by description of it having the "safe" property.

Re: The HTTP Query Method

#57

Post by 8organicbits »

andyferris wrote: post #28

Does anyone know what blocks something like this being accepted? I’ve had my eye on this for ages and have had to work around its lack multiple times, so just curious what the hold up could be.

You can check the mailing list for the current discussion.

https://lists.w3.org/Archives/Public/ietf-http-wg/

There's also some tracking on GitHub.

https://github.com/httpwg/http-extensions/issues?q=label%3Aq...

Re: The HTTP Query Method

#58

Post by slim »

I anticipate this will be used by UI frameworks to transmit a very long list of item ids selected by the user using check boxes. Which will cause suffering to the backend devs dealing with relational databases

Re: The HTTP Query Method

#59

Post by bhawks »

chronicler wrote: post #2

Making GET requests have bodies as the norm would also handle this

That ship sailed decades ago. Too much software and middleware expects GET to not have a body and who knows how itll break when you start sending one. Obviously you can do it today and it might work and then randomly break when the code between client and server changes.

Adding a new http method is the only way to support something like this safely. If something in between doesn't know what to do with QUERY it can just respond with a 501.

Fun fact - GET and HEAD are the only required methods one needs to implement to be an http server. It is a pretty low bar :)

Re: The HTTP Query Method

#60

Post by Zambyte »

gaigalas wrote: post #51
nhumrich wrote: post #46

Earlier quoted context omitted.

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.

GET: I want to see stuff. POST: I want to change stuff. I don't know how this style cannot match cleanly any architecture. It's not supposed to be a map to CRUD, it's a bunch of building blocks for manipulating state over a network.

What if the stuff you want to see can't be encoded in a URL?
Post reply on HN