REST can be as simple as you want it to as verbose and rigid as you want it. Defining an API has certain public expectations such as request/response and basic

REST can be as simple as you want it to as verbose and rigid as you want it. Defining an API has certain public expectations such as request/response and basic HTTP status codes, but again can be easy or more detailed. There are RESTafarian and pragmatic ways to implement REST APIs. Much of the problem of any tech becomes that engineers/developers are supposed to make complex things simple but instead sometimes make simple things more complex because it seems smarter. Complexity is needed only enough to make it simple to interface with and consume. REST is an example of web services done right and more simple compared to SOAP which was supposed to be the Simple Object Access Protocol but they forgot the simple part and just kept adding layers. APIs should be easy to work with and as non changing as possible in the public signatures and routes/data/configs or else versioning should come in on major changes which should be handled wisely. Sometimes that is RESTafarian or pragmatic, sometimes more HTTPRPC, sometimes that means schemas for consumption, sometimes pretty urls, sometimes ids and name blurbs, sometimes responses wrapped in app messages/wrappers, sometimes directly on HTTP(s) response bodies, and it all depends on if it is public or private and if you control both endpoints, the clients and business needs.