The new HTTP QUERY method explained

CCommonGuy about 3 hours ago 32 commentsRead Article on kreya.app

⚡ Community Insights

Discussion Sentiment

63% Positive

Analyzed from 574 words in the discussion.

Discussion (32 Comments)Read Original on HackerNews

Rapzid•6 minutes ago

Body is already optional with GET. Proxies aren't supposed to touch it or assign meaning to it; it's between the client and the end server.

A whole new method whose semantics don't really fit with the others is.. An odd way forward.

tosti•about 1 hour ago

> using HTTP GET with a request body is a bad idea, as for example users behind a corporate firewall or a different browser may be unable to use your website.

So is using QUERY requests for quite some time from now.

jy14898•29 minutes ago

405 Method Not Allowed is trivial to fall back to POST. How do you know the GET request behaved incorrectly?

tosti•12 minutes ago

That's assuming the corporate proxy is well-behaved.

jbverschoor•about 1 hour ago

Yeah, query seems just GET with a body. No difference in protocol nor behavior

ComodoHacker•20 minutes ago

Except compatibility. If you're using classic GET and it's enough for you, you aren't affected.

waweic•34 minutes ago

I wonder what the drawbacks of standardizing a GET body would have been. CoAP already has it (which creates friction in building CoAP<->HTTP proxies).

All in all, I dislike the overall focus on the HTTP method when designing "RESTful" interfaces. If all we're building is, effectively, an RPC, why would the cacheability meta-information be the first thing we specify?

ktpsns•about 2 hours ago

HTTP QUERY was discussed many times in the past here:

https://news.ycombinator.com/item?id=48568502 (4d ago, 173 comments)

https://news.ycombinator.com/item?id=29794838 (4y ago, 125 comments)

doctor_phil•about 1 hour ago

Nice, not having bodies on GET has been a pet peeve of mine for a long time. It would be nice to allow bodies on DELETE as well, but that is less of a problem in most cases.

nokeya•about 1 hour ago

If it needs so much explanation and discussion, maybe it is not a great idea after all?

reddalo•37 minutes ago

The article describes the current situation first. The whole explanation is quite simple: QUERY requests are the same as GET, but they have a body.

someguynamedq•33 minutes ago

So just add an optional body to get

8-prime•about 1 hour ago

It's interesting to see additions to HTTP methods as it much feels like the existing ones are set in stone. At least for the time that I have been a developer. I'm curious to see how fast the adoption/support for HTTP QUERY will be. I've had my fair share of situations where I wished for something like HTTP QUERY.

hparadiz•about 1 hour ago

I can implement it in about 10 minutes. Not even kidding.

echoangle•34 minutes ago

In what role? As a user writing client code or when implementing the caching middleware or the Webserver?

hparadiz•28 minutes ago

In my CRUD controller that I already have.

PunchyHamster•about 1 hour ago

zero. Many libs will/can just request method as a string so you can start coding now

> I've had my fair share of situations where I wished for something like HTTP QUERY.

Using POST instead comes with no drawbacks

grugdev42•27 minutes ago

We should have just added optional body support for GET requests.

So much simpler...

ComodoHacker•19 minutes ago

More complex actually

koolala•about 1 hour ago

What do you think people will make the Query request body? Most everything will use this for JSON but it could be anything so what other interesting things do you think will go in there? Query 1 + 1 and get 2?

miggol•24 minutes ago

Considering the guideline that QUERY should be idempotent and cacheable, file querying requests come to mind. Reverse image search, for example.

dreambigwrkhard•about 1 hour ago

I'm curious too. Unless the developer is really passionate about this I don't think a dev will risk (potential) compatibility issues or unexpected footguns to use this when the workarounds do seem to work quite well already. I just dont see the benefit but maybe it's because I am just not aware of a real world use case; happy to be corrected.

unilynx•about 1 hour ago

Elastic/Opensearch uses GET requests with a body for search, which is complicated or forbidden (not exactly sure) with the HTTP spec. Not all HTTP clients are willing to submit a body with a GET.

So opensearch also allows you to POST search requests, but those are uncacheable

QUERY would fit here perfectly - it's probably trivial for opensearch to add but it will take some time for clients to catch up.

hparadiz•about 2 hours ago

This feels like someone coming up with XML when JSON already exists.

flanked-evergl•about 2 hours ago

No, it does not feel like that.

hparadiz•about 1 hour ago

My framework is already two decade old prior art and you still haven't actually convinced me that this RFC solves a problem.

rmunn•about 1 hour ago

1. Sometimes you need a request body. 2. POST cannot be guaranteed to be safe if re-sent. 3. This is GET with a request body, guaranteed* to be safe if re-sent.

* With the caveat that it's only guaranteed if the server is following the RFC correctly.