I wish people would stop saying "REST" when they mean "HTTP server that maps HTTP verbs to CRUD operations and uses JSON for input/output".
You can't "kill REST".
It is a set of architectural elements and constraints that apply to a distributed cross-organizational anarchic client-server messaging system like the web. It is how you design something like HTTP.
REST does not automatically mean CRUD verbs, not does it mean JSON, nor does it even necessarily mean using HTTP as your messaging mechanism.
You can have a REST-adhering system that runs on HTTP, MQTT, or smoke signals. You can describe interactions in JSON, GraphQL, or protobuf.
Looking at it through that lens, it really matters more whether you're able to categorize a client's requests as cacheable, destructive, and/or idempotent and send back a response that represents an atomic state with hyperlinks to other valid states, so that the whole system can be scaled by infrastructure that's oblivious to the application-specific meaning of a particular message.
Many so-called "REST APIs" do not meet that criteria. Not even close. They implement a thin veneer on top of DB operations, maybe with some validation if you're lucky. It's then up to the client to have intimate understanding of valid state transitions and the characteristics of each specific request.
Moreover.... Most systems that claim to be "RESTful" shouldn't even strive to follow REST! The architectural constraints just don't make sense for (or are fundamentally incompatible with) the problem they're trying to solve.
I think where we screwed up with SPAs, as an industry, is that we took inspiration from the document-based web instead of from realtime video games.
Imagine trying to represent Counterstrike as a series of hyperlinks. I mean, you certainly could -- Twitch Plays Pokemon is something akin to that. But it's not a practical implementation for that system.
The real problem here is that even when devs understand REST deeper than "JSON CRUD over HTTP", they get the order of operations wrong. They think "Well, HTTP is the most readily-available mechanism I have in this component... and REST seems like a natural fit for HTTP..." instead of "Is REST the right set of constraints for this component? If not, can I find a mechanism other than HTTP, that makes more sense for the right set of constraints?"
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I wish people would stop saying "REST" when they mean "HTTP server that maps HTTP verbs to CRUD operations and uses JSON for input/output".
You can't "kill REST".
It is a set of architectural elements and constraints that apply to a distributed cross-organizational anarchic client-server messaging system like the web. It is how you design something like HTTP.
REST does not automatically mean CRUD verbs, not does it mean JSON, nor does it even necessarily mean using HTTP as your messaging mechanism.
You can have a REST-adhering system that runs on HTTP, MQTT, or smoke signals. You can describe interactions in JSON, GraphQL, or protobuf.
Looking at it through that lens, it really matters more whether you're able to categorize a client's requests as cacheable, destructive, and/or idempotent and send back a response that represents an atomic state with hyperlinks to other valid states, so that the whole system can be scaled by infrastructure that's oblivious to the application-specific meaning of a particular message.
Many so-called "REST APIs" do not meet that criteria. Not even close. They implement a thin veneer on top of DB operations, maybe with some validation if you're lucky. It's then up to the client to have intimate understanding of valid state transitions and the characteristics of each specific request.
Moreover.... Most systems that claim to be "RESTful" shouldn't even strive to follow REST! The architectural constraints just don't make sense for (or are fundamentally incompatible with) the problem they're trying to solve.
I think where we screwed up with SPAs, as an industry, is that we took inspiration from the document-based web instead of from realtime video games.
Imagine trying to represent Counterstrike as a series of hyperlinks. I mean, you certainly could -- Twitch Plays Pokemon is something akin to that. But it's not a practical implementation for that system.
The real problem here is that even when devs understand REST deeper than "JSON CRUD over HTTP", they get the order of operations wrong. They think "Well, HTTP is the most readily-available mechanism I have in this component... and REST seems like a natural fit for HTTP..." instead of "Is REST the right set of constraints for this component? If not, can I find a mechanism other than HTTP, that makes more sense for the right set of constraints?"