It's not about the "end user" developer of the server, it's about the middleware and the clients. A browser (for example) will happily retry a GET request that times out, but will not automatically retry a POST request that does the same. Will that break a badly behaved web API? Yes. But that's like saying that "calling conventions are a useless spandrel because the consuming code can ignore the convention and just read from arbitrary memory".

I agree.

I can understand the annoyance for there being so many verbs, but at the very least, there must be two: One that is guaranteed to be idempotent, and one that isn't.

Someone I know was trying to make a message board that was compatible with every browser. EVERY browser. Including Mosaic and Netscape 1.0. Which meant that everything was done using GET requests, including posting messages.

He changed his tune when some spidering engine found his site and issued tons of GET requests that ended up flooding the board with comments and posts that looked like web search queries.

I find that hilarious because that used to be such a well understood phenomenon that I can't believe no one told him about it.

OTOH, sometimes the best teacher is experience.

That's actually a good example, because if the standard specified that POST must be idempotent, and that a POST without a uuid is invalid, we might have something here.

Instead there's a workaround for a serious problem, and any client (browser being by no means the only client) which doesn't respect the convention can emit identical POSTs, with no way of knowing if that was intended.

The standard says "POST means NOT-IDEMPOTENT" and "clients MUST not re-issue a non-idempotent requests" and the client behavior naturally falls out of those two constraints.

The standard being completely backward and impossible to enforce is a problem!

standards are agreements, they've never been there with the expectation of enforcement.

Unenforceable and unenforced are very different things.

Unless you've got state actors behind it, it's unenforceable, full stop.

We saw this when MS would regularly ignore HTML standards.

POST is intentionally not idempotent. If you want impotence, that's what PUT and DELETE are for. Sadly, browser support for those two methods is somewhat lacking. You can't specify that a form send a PUT request, for example, only GET or POST.

You're looking for PUT.

Browsers behave differently based on the HTTP method, though. For example, POST requests are confirmed when trying to refresh, they are not cached, and a whole bunch of restrictions on XHR/fetch.

That's a fair criticism. On the other hand, I do find it useful to be able to construct an API where `PUT /object/1` will create an object, and `DELETE /object/1` will destroy it. It helps me keep things a bit more organized that way, but it wouldn't be hard to add the verb to the end of the URL instead.

I would probably be in favor of some more strict guards around specific verbs, but I don't really know how that would be implemented given that the behavior is always controlled by the developer at the end of the day.

Web frameworks adhering to these conventions is probably a good thing, though, and in my somewhat limited experience, that seems to generally be the case (though they often still let the developer override the behavior).

But there are many guarantees browsers impose. The verb is incredibly important.

Http status codes barely do anything to begin with nowadays. I was bombarded with them in college, and if you look at any webapp, it only ever responds 200, 302 or 500.

Redirects are done in js, 404s are just normal pages, if that, and 401s are just not a thing on the public web anymore.

I regularly see 401s and 403s on public APIs when interacting with them.

301s can be somewhat handy in certain circumstances too.

> Redirects are done in js

Redirects definitely happen in more places than you think/see, mostly because almost all tooling handle redirects transparently to the user, so you don't really notice it.

Doing redirects in JS is a huge waste of resources as well, as you'll need to load a full page with it's body (meaning the browser will parse and execute it) while having a 301 + Location header means the browser can redirect quicker without executing more stuff.

I definitely use a bunch more than just those three, maybe as many as a dozen at various points. Probably another dozen occasionally leak through as problems from infrastructure we use. I could probably name several codes that I can't see much point in, but I'm sure people would respond why I'm wrong.

Not quite useless. POST tells the server to check for a body which I think is a reasonable indication of intent. But otherwise, yes, it’s all arbitrary and just vague hints to the server program as to what you might possibly be thinking of doing…

But then GET as well as everything else can have a body, so most servers would check anyway.

GET isn't really supposed to have a body:

"An HTTP GET request includes request header fields and no payload body and is therefore transmitted as a single HEADERS frame, followed by zero or more CONTINUATION frames containing the serialized block of request header fields."

https://www.rfc-editor.org/rfc/rfc7540#section-8.1.3 (HTTP/2.0)

"A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request."

https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1 (HTTP/1.1)

I've never used one or spec'd one, I consider it unsafe.

This is, of course, what the specs say, and they don't even really agree; I am well aware of the non-trivial daylight between "what the specs say" and "what happens in the real world". I point this out not as a spec compliance maniac but as something people ought to know... it's not a great plan to expect GETs to be able to have bodies, just as I would not suggest sending a 404 response code that also has the "real data" in it for whatever reason. You're just asking for trouble, even if it might sometimes work.

> just as I would not suggest sending a 404 response code that also has the "real data" in it for whatever reason.

Do you mean to suggest that you advocate for an everything-is-200-OK design and the client should be checking for an error object there?

"Don't do something really stupid."

"Do you mean to suggest that people should do this other stupid thing then?"

Come on.

There's no reason for you to hold that opinion so strongly.

There's nothing inherently wrong with having a 200 for everything with a standard body structure, and there's nothing wrong with having a GET request with a body.

Where things go off the rails is strictly adhering to a specific thing without understanding the advantages and disadvantages of other approaches.

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.

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.

RFC 7231 has been obsoleted by RFC 9110 since June; and interestingly enough it says absolutely nothing explicit about whether body in a GET request is allowed or not.

Well by that notion, all command-line executables should be stripped of their names and referred to by UUID, and any text-to-UUID mapping be the sole responsibility of the user.

It's my understanding that a lot of early design decision like HTTP verbs happened due to the much wider spread of proxies.