[P5fRxh5kUvp2th]

The point is that they're ALL unsafe.

The angst around GET verbs is that someone could really be doing an update if it has a body. Well guess what, someone can be doing an update based purely off the query string too.

This angst around GET bodies is rules lawering AT BEST. It's the type of distinction that has no real merit and I consider it an absolutely short-sighted decision by the OpenAPI Spec to insist that GET has no body (they've recently changed this, but I can't believe it was ever a thing. Finally some common sense).

---

TO BE VERY CLEAR:

Back in the day you would hear stories of companies getting entire sets of data wiped out from a search engine bot that was happily following GET requests that would delete data.

There is absolutely nothing in a GET request that guarantees anything except what the developer decides to guarantee. That a developer SHOULD choose that a GET request be idempotent is still a choice regardless of the existence of a body or not.

[jerf]

I agree with you for the most part. Like I said, I consider it too dangerous to use, not that it's somehow impossible. But the reason I consider it too dangerous isn't that it's a Violation of the Holy Spec... everything and everyone violates the spec, to a first approximation. The problem is that all the libraries in the world and middleboxes and everything else violate the spec in different ways, and allow/enable/afford their own set of violations that do not match.

If you spec an HTTP API as having a GET with a body ("because otherwise the query string will be too long" or something), I can virtually guarantee you that as soon as it is even slightly popular you're going to get "But I'm using this library over here in some language you've barely heard of and its author thinks GET can't have a body so it won't send it to you, plz hlp".

I wouldn't consider it safe to deliberately use in an API. Similarly, I once accidentally sent a real reply as a 404 response (just a plain ol' bug), and while I did of course fix it quickly in my API, the user on the other end didn't have a good option for just ignoring it and moving on in the meantime. Their HTTP library got really feisty about using the body of a 404 ... I think it was something like, you could read it as a bag of bytes but all the clever "let's automatically JSONify this" and stuff functionality in their framework wouldn't fire on a 404. This is why I mentioned that one. It is a bad idea to treat the content of a 404 response as anything other than an advisory response to a human, and even that has some funny characteristics based on browser screwiness over the years.

There's definitely violations of the spec safer to specify, and violations less safe to specify; they're not all created equal.