I struggle to believe that any API in history has been improved by the developer more faithfully following REST’s strictures. The closest we’ve come to actually decoupled, self describing APIs is MCP, and that required inventing actual AIs to understand them.
The most successful API in history – the World-Wide Web – uses REST principles. That’s where REST came from. It was somebody who was involved in the creation of the early web who looked at it and wrote down a description of what properties of the web made it so successful.
REST on the WWW only works because humans read and interpret the results. Arguably, that’s not an API (Application Programming Interface) but a UI (User Interface).
I have yet to see an API that was improved by following strict REST principles. If REST describes the web (a UI, not an API), and it’s the only useful example of REST, is REST really meaningful?
> REST on the WWW only works because humans read and interpret the results.
This is very obviously not true. Take search engine crawlers, for example. There isn’t a human operator of GoogleBot deciding which links to follow on a case-by-case basis.
> I have yet to see an API that was improved by following strict REST principles.
I see them all the time. It’s ridiculous how many instances of custom logic in APIs can be replaced with “just follow the link we give you”.
This is, almost canonically, the subject of Joel Spolsky's architecture astronauts essay.
It’s not. It’s pretty much the opposite. This is what he’s talking about:
> our clever thinker invents a new, higher, broader abstraction
> When you go too far up, abstraction-wise, you run out of oxygen.
> They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.
REST is the opposite. REST is “We did this. It worked great! This is why.” And web developers around the world are using this every single day in practical projects without even realising it. The average web developer uses REST, including HATEOAS, all the time, and it works great for them. It’s just when they set out to do it on purpose, they often get distracted by some weird fake definition of REST that is completely different.
That's absolutely not what the essay is about. It's about the misassignment of credit for the success of a technology by people who think the minutiae of the clever implementation was important.
I think you bring up an interesting tangential point that I might agree with--that the people doing the misalignment are how architecture astronauts remain employed.
But the core of Joel Spolsky's three posts on Architecture Astronauts is his expression of frustration at engineers who don't focus on delivering product value. These "Architecture Astronauts" are building layer on layer of abstraction so high that what results is a "worldchanging" yet extremely convoluted system that no real product would use.
A couple choice quotes from https://www.joelonsoftware.com/2008/05/01/architecture-astro...:
> "What is it going to take for you to get the message that customers don’t want the things that architecture astronauts just love to build."
> "this so called synchronization problem is just not an actual problem, it’s a fun programming exercise that you’re doing because it’s just hard enough to be interesting but not so hard that you can’t figure it out."
[dead]