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

11–20 of 136 posts

Re: The HTTP Query Method

#11

Post by johncolanduoni »

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?

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.

Re: The HTTP Query Method

#12

Post by arp242 »

newscracker wrote: post #8

A couple of quick observations and comments after skimming through this (some of these are mentioned or hinted at in the RFC). With HTTPS used almost everywhere, using this QUERY method (when standardized) could prevent bookmarking specific “GET” URLs if the developers thoughtlessly replace GET everywhere with QUERY. One of the advantages of GET is the direct visibility, which makes modifications simple and easy for…

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 (if desired).

Completely worth bringing up and thinking about, but unless I'm missing something I don't think a QUERY verb will change all that much here?

Re: The HTTP Query Method

#14

Post by pcthrowaway »

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?

I think the idea is that POST creates a record (and in theory fails if that record already exists). I guess the commenter above is saying that if you inverted that (fail when the record doesn't exist, return the record if it does) it would be similar to QUERY? Not sure if I agree with that, but PUT's return semantics are a bit vague.. it often returns partial or combined records, or just a 200 OK (with or without a response body), or 204 No Content for unchanged records (with or without a response body)

It's clear what POST returns, so... perhaps QUERY is more similar to it in that sense?

Re: The HTTP Query Method

#15

Post by johncolanduoni »

fijiaarone wrote: post #4

We already have POST, PUT, and PATCH that do the exact same thing. Why not have another version of GET that looks the same as POST and is subject to personal interpretation. FYI: QUERY is for GET requests where the query string make the URL too long. It does this by sending a body like POST. In the past, POST meant you were sending a body, and GET meant you received a body. And the people got religious about a pseudo…

Apart from the sectarian conflicts about what REST means, having a HTTP method that proxies can cache like a GET but allows bodies is pretty useful from a purely practical standpoint. You can do this with POST, but it requires proxy-specific configuration.

Re: The HTTP Query Method

#16

Post by johncolanduoni »

pcthrowaway wrote: post #14
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?

I think the idea is that POST creates a record (and in theory fails if that record already exists). I guess the commenter above is saying that if you inverted that (fail when the record doesn't exist, return the record if it does) it would be similar to QUERY? Not sure if I agree with that, but PUT's return semantics are a bit vague.. it often returns partial or combined records, or just a 200 OK (with or without a r…

Whatever the original intent was, POST definitely does not return a new record consistently in most actual APIs. It's frequently used for actions that don't conceptually create anything at all.

Re: The HTTP Query Method

#17

Post by gridlocdev »

I can’t wait for QUERY to become an official RFC.

It's felt quite awkward to tiptoe around the existing spec when building features that retrieve data; we've had to either use POST to keep sensitive filter criteria out of http logs or just create a usually massive URL-encoded query string.

Re: The HTTP Query Method

#18

Post by cortesoft »

platzhirsch wrote: post #3
chronicler wrote: post #2

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

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.

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.

Re: The HTTP Query Method

#20

Post by cortesoft »

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…

It would be pretty impossible to actually ‘enforce’ that GETs don’t modify state. I am not sure if I would call the lack of enforcement a problem when it is more a simple fact about distributed systems; no specification can enforce what a service does outside of the what is returned in a response.
Post reply on HN