Hacker News Reader

Comment by 8-prime | Hacker News Reader

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.

View on HN

This is why there's another method. It's easier to communicate 'QUERY method support' rather than get-with-a-body-no-not-the-one-that-is-unspecified-it-is-accepted-with-slightly-different-semantics-now-EOF.

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

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

In my CRUD controller that I already have.

This assumes that all of the infrastructure surrounding your application also plays nicely with it and supports it, as stated in the article. That's why I expressed my interest in speed of adoption in the first place.

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

I think the article summarizes pretty well what the drawbacks of POST are: unclear idempotency (well it's actually pretty damned clear: they are not cacheable). That complicates caching logic, and that's not just for the application server itself, but any reverse proxies in front of it as well as the user agent itself.

I'm not sure QUERY is a great solution, because in the context of a web application absolutely no one enjoys using a page that does not keep its state on refresh, so that really limits where QUERY makes sense, but if you have a case that is not driven by navigation, great.

Much harder to get CDN:s/proxies/etc to cache a post request vs this new one (assuming it’s actually becomes used)

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

Not so fast, champ. It matters nothing what your library let's you run away with. What matters is that every single box in the internet between you and the origin server will tolerate, and your pet library doesn't have a say in that.

> Using POST instead comes with no drawbacks

There's a hefty share of ignorance in your comment. Between POST being classified as an unsafe method and the absence of support for cashing, there are plenty of downsides of abusing POST for query requests.

As the RFC was initially proposed by someone from Cloudflare, were you aware that not even Cloudflare support caching POST requests? Their unofficial support for caching POST requests is to create a fake GET request to serve as cache key and use that to cache the response. This is the kind of hacks everyone is forced to go through instead of using something like QUERY

Reply on news.ycombinator.com