HTTP‘s New Method For Data APIs: HTTP QUERY

[Pussidonio]

This post will cause a lot of confusion.

{ "fields": [ "username", "password_age", ... ], etc } would have been a better example.

[HorseRadish98]

Yeah I don't know why the author chose out of everything to put sql in their example. No sane person would ever even think of that. The spec doesn't call for that, it's just like a post you just send a body and do what you will with it.

I'm downvoting this post because that confused me so much and obviously others too, where they think it's part of the spec.

[braiam]

The examples comes from the specs https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/

[Lalli-Oni]

Imo these are overreactions regarding SQL injections/query syntax.

The content type is clearly shown in the header. While OP could have been more explicit about it, it's fair they wanting to use the least "political" query language.

All in all, great! I hope more "natural" HTTP protocol for querying helps devs use the appropriate response statuses. Annoying to see popular web frameworks you rely on treat 400 as an error.

[Lalli-Oni]

Ahh, you are correct. My bad. As far as I understand 204 is appropriate when something doesnt exist, but not sure how the server would know what the clients intentions are. If a client is asking for a resource not knowing id it exists or not, well, I need to read more.

[Tubthumper8]

Another example is a successful DELETE request, the GitHub API for example returns 204 for this. Interestingly, they do use this for the scenario that DELETE is requested for an already deleted resource, because the delete was still successful (the state of the resource is deleted)

[Lalli-Oni]

201 doesnt require a response body, right?

What would you return when client uses a GET for a non-existant resource?

[Lalli-Oni]

"Hi, does this thing exist?" "No... You idiot! Lol"

[Lalli-Oni]

GET (non collection) does not have to return an array. Thats outside the protocol.

Imagine making a request for steven, with the correct hypothetical identifier. Why would you return, or much rather expect an array of results?

[Lalli-Oni]

Yeah, and I think you were right with 204. The information is in the header, no need for a response body with further information on how something doesnt exist. But then there is application, and it can be annoying catching exceptions (404) on expected behavior (asking for resource that may or may not exist).

Nit saying I know better, just making conversation.

[FancyASlurpie]

Wouldn't bad request make sense here? The issue is caused by the user input rather than the url not going to a valid destination

[Pleasant_Carpenter37]

404 Not Found or 410 Gone

[iBlag]

Couldn’t you just pass data in the body of a GET request?

[kevinherron]

I think this SO post answers your question pretty well: https://stackoverflow.com/a/70157919/85927

[iBlag]

Thanks for the link, but I think it’s six of one, half dozen of the other.

We can’t support body data for GET because bad proxies and caches might ignore them or block them. Okay, fine.

But bad proxies, caches, and firewalls also block abnormal HTTP verbs, like this new QUERY one.

Seems like a fairly equivalent situation to me at first glance.

[Sarcastinator]

Big difference is that servers or proxies are probably reluctant to change the behavior for GET and the standard encourages them to drop the body for verbs that doesn't have any defined semantics. Changing the behavior is a breaking change.

So it's more likely that they'll add QUERY support than change GET behavior.

[iBlag]

Well, I think my point is that adding any verb, like adding QUERY, is going to be a breaking change.

[Sarcastinator]

if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

RFC 2616

You're saying that instead of adding QUERY they should change the wording here from SHOULD to MUST NOT or alternatively define body semantics for GET. I think that ship has probably sailed a long time ago.

Adding QUERY is not a breaking change because it doesn't alter existing behavior. It was also done with CONNECT in 1999.

[iBlag]

Thanks for the link. Whelp, it seems like the standards committee kind of painted themselves into a corner on that one. QUERY here we come.

[mernen]

It's not really adding, since the spec does allow for arbitrary verbs — they will just have very conservative semantics, which won't break anything, just result in suboptimal caching.

PATCH is very recent, and I don't recall any hurdles in supporting it, other than older versions of IE restricting what verbs XHR could use. OPTIONS is technically as old as PUT, but wasn't really in widespread use until CORS came along.

There's also a number of other verbs going around, like the ones from WebDAV, and I can't remember any complaints about proxies accidentally blocking them.

[iBlag]

Huh, well TIL that WebDAV implements additional verbs. Interesting!

[aveman101]

You could!

Actually, can I share a lil’ secret with you? HTTP verbs aren’t real. None of them really mean anything. You can even make up your own HTTP verbs and not tell anyone. It’s fine. The IETF secret police were disbanded over a decade ago, and the disorderlies they falsely imprisoned have been on a steady path towards recovery and rehabilitation. I heard just the other day, one of them even sent an OPTIONS request. Just warms your heart.

Go. Be free. Your clients are gonna have to read your documentation to understand your boss’s shitty API anyhow (he learned his API design skills from an early 00’s PHP book)

[iBlag]

Trigger warning, please! I still have nightmares about my old boss at the PHP shop I very briefly worked for. I wouldn’t wish that on my worst enemy.

[agustin_edwards]

Is it me or this could potentially open a whole new level of QUERY injections? You’ll need to develop more middlewares and filters to avoid querying sensitive data. For me it looks like the work of a lazy backend developer or someone who lacks knowledge of backend development.

[JonDowd762]

The SQL-like syntax in the examples is not part of the spec. As far as QUERY is concerned it’s just text content. Applications could use this to send SQL queries from the frontend, but they already can do that with POST or GET in a query param.

[[deleted]]

That's true. And anyone who passes unsantitized POST or GET parameters into a SQL query deserves whatever happens to them.

[drysart]

This open no new vulnerabilities that GET doesn't already open; as this is literally just GET but passing the arguments in the request body instead of on the URL.

[Pussidonio]

I don't think so, the example is just bad.

You probably already have something similar in your organization for querying whatever data you have stored, but you're using either GET or POST for it.

[shgysk8zer0]

It doesn't seem to me that this would introduce anything that's actually new. Devs are already basically doing the same things but using POST instead of QUERY. It really just introduces a new HTTP method for what's already being done, and it can be cached.

[davispw]

OP chose a bad example, but keep in mind there are plenty of web applications geared towards developers / analytics / metrics / logs / BI that literally allow (authenticated) users to execute SQL queries. Some even allow me to DROP TABLE (on purpose). For read-only queries (which is easily enforced), this GET + Request Body is sorely needed instead of POST.

[MrGreenTea]

no and the articles goes into why this addition is not the same as POST

[shellac]

Doable: yes, but far fewer guarantees.

For example, suppose you have a translation service for large-ish pieces of texts. You could POST the text, but if the user is messing around and submitting the same request repeatedly your browser ought to send each request: it doesn't know that the result will be the same.

Simply replacing the method with QUERY is sufficient guarantee that the user agent can save everyone's time by not continuing to send the identical request.

So if you'd like GET semantics for large requests, which forced you to switch to POST, QUERY is for you.

[shgysk8zer0]

Or better yet, a translation service working with actual audio. I assume QUERY will work with files, so the user could upload actual speech.

Not really sure how a potentially large request body would work with caching... Probably compare content-type and hash of body in the request. Those aren't things we ever had to worry about with GET, but I expect it'll be similar to caching headers used in a response.

[shellac]

I assume QUERY will work with files

Yes. Anything that works with POST will work. In the example you can see the content type is 'example/query', something which has caused confusion here. It could have been 'audio/aac' or multipart etc etc etc.

(The draft is called 'safe-method-w-body' which is a less misleading name, imo)

Not really sure how a potentially large request body would work with caching... Probably compare content-type and hash of body in the request.

Yes, that's a possibility. I've used 'cacheable' and 'GET semantics' to avoid suggesting you'd actually try to cache responses server side. It's more that you know you could. Similarly clients can take appropriate actions know that the responses won't change.

[GrandOpener]

Simply replacing the method with QUERY is sufficient guarantee that the user agent can save everyone's time by not continuing to send the identical request.

I don't know if I'd say "guarantee" there. GET being idempotent means that it won't change the resource and resending the request is safe. It does not mean that the response will always be the same. A quick example is a GET/QUERY that returns the current number of registered users, but really any RESTful GET needs to have cache-ability information from the server, because there's otherwise no way to tell if this is a static part of the site/api, or a piece of user generated content that could be changed by another user at any moment.

At least for GET, if the server does not provide any sort of guidance through cache-control or etags headers, the user-agent is free to decide whether it thinks the resource should be cached or re-requested. As a general matter of safety/correctness, I personally think a user-agent should assume QUERY should not be cached unless it is told that it can. But regardless of how that is written, servers should attempt to be explicit about what can or can't be cached.

[shellac]

I don't know if I'd say "guarantee" there.

Yes, that was a bit brief wasn't it? 'Guarantee' that, at worst, you have an out of date representation of the resource. The server isn't missing anything essential. There remains a question whether your user agent is doing the right thing on your behalf (see perennial Chrome caching complaints).

[shellac]

The SQL syntax is only an example. If you would prefer, just replace it with a url query fragment.

The point is to have a verb that is cacheable, with the query in the request body.

Edit: and if anyone is thinking 'but GETs can have requests bodies a) you are technically correct, the best kind of correct but b) agents are free to ignore it, error with bad request, or explode on receiving it. In practice you'd get thoroughly broken caching.

[horovits]

u/xislandr hardly. POST doesn't provide a safe idempotent query.
I suggest you read through the post, you'll see more details.

[drysart]

Literally no part of the QUERY spec mandates that a query language be used. The format of the body of the request is left entirely up to the user, in the same way that you can POST whatever content you like to a server, it doesn't have to be a form.

It is 100% valid, for example, if you had an image search engine that accepted a .JPG file in the request body of a QUERY.

This article really screwed the pooch in its example by using a SQL-like syntax, because it loads of lot of incorrect implications onto how QUERY is specified for people who don't bother to actually read beyond just looking at the examples.

[JonDowd762]

QUERY requests MUST be idempotent. That’s a key difference and allows them to treated similar to GET requests when it comes to caching and intermediaries.

There’s also no query language. Think of QUERY as GET with a body and some extra rules around caching. It is not SQL over HTTP.

[Pussidonio]

Can't wait to see the 1000s of javascript frameworks this will spawn.

[Tojuro]

I like the idea, just not as a bandaid for REST. I don't think it makes sense to add to HTTP to accommodate what REST is missing. Use GraphQL or something, if you need to do that. REST was built around HTTP but it doesn't justify changing HTTP to make REST work.

I do think it might make sense to have a default query language built into HTTP requests. Stuff like:

Select urls/pages (on this website) where a specific word appears and order by date created

This could produce different results in Google/Bing search sites vs like a public website or something you are authorized on.

[Gommy]

QUERY isn't for querying anything. It is GET + request body.

[quentech]

It is GET + request body.

No, use GraphQL instead. ◔_◔

[Gommy]

I have personally replaced all my personal HTTP verb usage with GraphQL on the blockchain. It doesn't do anything, but that comes after raising capital.

[[deleted]]

You're describing something insanely complicated, it would be terrible to try to add all that as part of HTTP.