REST isn't a protocol, it's an argument for an approach to systems architecture that minimizes coupling between components while maximizing client reuse.
I've designed and operated several REST-inspired systems over the years, and let me warn you: it's no walk in the park. Engineers that want to "get it done now" must be convinced not to huck everything up to the server as a POST. Founders have to see the business case for every new system. Other departments may have to relearn tools for interoperating with the systems. It's a whole big deal. You can't deploy a RESTful solution and avoid dealing with people.
For your effort, you'll receive a system with well-factored bounded contexts whose self-descriptive interfaces interoperate with standardized tooling and monitoring systems. Projects can be factored into tasks along clear domains and often incrementally delivered into production. Life-sucking productivity projects like the secret admin website can be pushed off indefinitely. Problems will be simple to isolate and reproduce. You'll have the flexibility to rush out brand new client experiences on tight deadlines.
Notice how none of the problems or benefits really involve a particular technology tool or framework or language?
In my opinion, ignorance of the significant cultural factors required for a successful deployment of a RESTful system is the reason why articles continue to be published about how it's vague or difficult or whatever.
There are lots and lots of open source web applications out there. I like to read code to see how things are being done. Can you point to any web application out there, with source code available to read, that is built in the way that you are describing?
I've designed and operated several REST-inspired systems over the years, and let me warn you: it's no walk in the park. Engineers that want to "get it done now" must be convinced not to huck everything up to the server as a POST. Founders have to see the business case for every new system. Other departments may have to relearn tools for interoperating with the systems. It's a whole big deal. You can't deploy a RESTful solution and avoid dealing with people.
For your effort, you'll receive a system with well-factored bounded contexts whose self-descriptive interfaces interoperate with standardized tooling and monitoring systems. Projects can be factored into tasks along clear domains and often incrementally delivered into production. Life-sucking productivity projects like the secret admin website can be pushed off indefinitely. Problems will be simple to isolate and reproduce. You'll have the flexibility to rush out brand new client experiences on tight deadlines.
Notice how none of the problems or benefits really involve a particular technology tool or framework or language?
In my opinion, ignorance of the significant cultural factors required for a successful deployment of a RESTful system is the reason why articles continue to be published about how it's vague or difficult or whatever.