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.

▲

PunchyHamster 3 hours ago | parent | next [-]

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

	▲	victorbjorklund 6 minutes ago \| parent \| next [-]
		Much harder to get CDN:s/proxies/etc to cache a post request vs this new one (assuming it’s actually becomes used)
	▲	rezonant 2 hours ago \| parent \| prev [-]
		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.

▲

hparadiz 4 hours ago | parent | prev [-]

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

▲

echoangle 3 hours ago | parent [-]

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

	▲	hparadiz 3 hours ago \| parent [-]
		In my CRUD controller that I already have.