SPAs breaks this principle by making webpages into fully fledged apps who do their own state tracking and navigation. This was never the intention of REST. The idea was to make the webpages themselves linkable RESTful substates of the application, and having the browser do the rest.
From the SPA angle, RPC might look like a good solution. But RPC in itself doesn't solve any problems except literal remoting.
A RESTful API makes states linkable and removes ordering dependences from the API.
Look at web frameworks which tried to make web sessions stateful. They are dealing with all the pains that REST solves.
Yeah so REST doesn't support what people are doing or what people want. So let's not use it if we want to succeed.
The web was designed to avoid it for multiple very good reasons. In fact, the success of the web has partially been attributed to those very design decisions, so it might make sense to pay attention to them.
Their position seems to be that REST standard methods as much as possible (even when technically delivering an RPC API) and fall back to custom methods when it makes sense to do so.
Not sure where you get that from. A truly RESTful API describes resources and their state changes via media types and URLs and the use of a limited number of verbs for transferring those state changes over the API.
People like to map REST to CRUD because GET looks like a SELECT, POST looks like an INSERT, PUT looks like an UPDATE and DELETE looks like a DELETE.
But there's nothing set in stone about those mappings.
An API can represent their resources however they like and use the appropriate links to URLs to represent the state changes. What the underlying persistent storage is (if any) is irrelevant.
> But there's nothing set in stone about those mappings.
People use those mapping because that's what is actually happening further down the stack, when you call your RDBMS in the end.
If I do a GET, I know that I can do it again without affecting the resource. I'll GET the current state of the resource identified by the URL.
The RFCs define those verbs and their operation. I can rely on that spec for the way they operate.
Verbs are also not idempotent for the most part, whereas it's relatively easy to ensure that the non-idempotent HTTP verbs (POST, PUT/PATCH, ignoring DELETE) can be made "repeatable" with use of etags or other unique identification.
Which is often what you want - a lot of things in the real world are more easily understood through verbs than nouns, which is what the essay is all about.
REST says that everything has to be an entity, which is why so many "REST" APIs end up just exposing their database as CRUD rather than offering a vocabulary that actually makes sense for the domain. When nouns are the only important things in your domain then it works. When verbs are important in your domain it doesn't.
> it's relatively easy to ensure that the non-idempotent HTTP verbs (POST, PUT/PATCH, ignoring DELETE) can be made "repeatable" with use of etags or other unique identification.
Most "REST" APIs "in the wild" don't actually do that (or, worse, do it incorrectly), so I'd question the idea that it's actually easy in practice.
RESTful or FIOH seems only appropriate if you design a public API. If your API isn't public, you don't need it to be RESTful. If you just need microservice communication, you don't even REST nor HTTP.
We shouldn't try to deform the whole logic and actual needs to fit a few HTTP verbs.
Doing that will make REST zealots judge you for heresy.
Yeah but why are people REST zealots I don't understand. Why are developers allowed to have "strong opinions" that align with goals of people outside of the organisation, that conflict with the organisations goal, isn't that misconduct