What it means for an API to be RESTful

This is exactly the kind of pointless discussion around rest apis

> I do still have an aesthetic appreciation for "true REST", but in practice I find the fact that nobody uses it to be mainly useful in ending bikeshedding discussions. Once you understand your API isn't RESTful to begin with, there's no longer any point in arguing if 411 or 412 is the more RESTful status code to use when a user attempts to order a product without specifying a quantity.

I think I have a fundamental objection to the idea that Fielding and Fielding alone got to decide what REST is. While there hasn't been any kind of formal counterproposal, in some sense REST is what we make of it. Re: http 400 codes, I think many of us really liked the general principle of "use http semantics!" and applied that to error codes as well. That's agreeing with the principle and extending it in new ways that we like and are "truer" to the principle, even if it wasn't intended.

In my mind this is sort of analogous to talking about the relationship between linux and unix. Linux is clearly not a genetic or copyright unix, but I've seen it said before that linux is the culmination of unix principles, in some cases extended beyond what was originally envisioned in ways that are innovative and genuine improvements (io_uring perhaps?).

The REST we have today - http semantics, specific error codes, etc - may be significantly different from what Fielding may have wanted, but IMO it implements the parts that really distinguish it from the RPC world of API architecture, and I think we're generally happy with that.

The word comment can be both a verb and a noun though. Are we pedantic enough yet? (:

> REST seems to bring out people who like to define specs and correct others on following the spec or not. There are many other things in tech like this.

Yes, and this blog post is exactly yet another example. Some of the blogger's points are blatant violations of REST, such as the comments on URIs and api versioning. Yet, the blogger elevates their own personal misconceptions to the status of one true RESTful way.

Ultimately it's all mostly irrelevant. All it matters is that the contract is specified and preserved and clients can consume services through a specific interface. Furthermore the pervasive use of openapi specs already crystalize the RPC approach to interfaces.

REST is an inherently human technology, almost superfluous for API(emphasis on Programming Interface) usage. I guess it does not strictly have to be, especially with our modern LLM's But REST can best be summed up as "ship the human interface required to handle a state with every state". For a strictly programming interface, this interface coupled with the state is inefficient and mostly pointless(the application already knows how to handle the state, it does not have to figure it out) and is better served by a more focused mechanical transfer.

With how narrow this scope ends up being I can understand how most of the tech industry collectively had what appears to be a collective brain fart when Fielding said "hey this web thing is doing something really novel in the field of application design, lets talk about it" and went "herp derp, REST == HTTP, sounds good to me". I mean I understand it, but still find it funny.