Yes I’d rather have a self defined standard that accurately covers the scope of an application and it’s use cases than stretch an old standard design for basic hierarchical text docs to work for a modern application.
And what’s inherently new in modern applications? We’re transferring state and operating on resources just like we used to do. Most web apps are variations of CRUD.
Yes most things are crud if you zoom out enough that doesn’t mean REST is just fine. The scope is larger now, the states are more complex and interrelated, relationships are more complex, data privacy laws can affect the physical implementation. REST also has a lot of baggage that leads to excessive bike shedding, or refusal to allow useful endpoints that aren’t sufficiently restful. Proponents also tend to be more concerned with the purity of the api than the usability and effectiveness of it
refusal to allow useful endpoints that aren’t sufficiently restful
And there are good reasons for that, GraphQL-like endpoints seem great to use, but are often a bad idea. The more freedom is given through an API, the less guarantees one can deliver. Security, scalability, and maintainability all become more difficult for APIs with endpoints that attempt to do several things at once.
But most importantly, REST doesn’t tell you exactly how to build your endpoints, as long as they’re stateless, cacheable, and refer to system resources with enough context to allow their direct manipulation.
These are good principles for older and modern web apps, that hasn’t changed. In fact, one can argue that the larger and more complex the system the more important it is to simplify its endpoints. And you can build pretty complex systems while following these criteria.
Yes I’d rather have a self defined standard that accurately covers the scope of an application and it’s use cases than stretch an old standard design for basic hierarchical text docs to work for a modern application.
And what’s inherently new in modern applications? We’re transferring state and operating on resources just like we used to do. Most web apps are variations of CRUD.
Yes most things are crud if you zoom out enough that doesn’t mean REST is just fine. The scope is larger now, the states are more complex and interrelated, relationships are more complex, data privacy laws can affect the physical implementation. REST also has a lot of baggage that leads to excessive bike shedding, or refusal to allow useful endpoints that aren’t sufficiently restful. Proponents also tend to be more concerned with the purity of the api than the usability and effectiveness of it
And there are good reasons for that, GraphQL-like endpoints seem great to use, but are often a bad idea. The more freedom is given through an API, the less guarantees one can deliver. Security, scalability, and maintainability all become more difficult for APIs with endpoints that attempt to do several things at once.
But most importantly, REST doesn’t tell you exactly how to build your endpoints, as long as they’re stateless, cacheable, and refer to system resources with enough context to allow their direct manipulation.
These are good principles for older and modern web apps, that hasn’t changed. In fact, one can argue that the larger and more complex the system the more important it is to simplify its endpoints. And you can build pretty complex systems while following these criteria.