I never understood why people love REST. Just use some kind of JSON-RPC, or something like that. In my experience most of so-called "REST" interfaces are just poorly written RPC. Some people even think that REST means HTTP + JSON. It's extremely rare to encounter a true REST interface with e.g. HATEOAS, proper caching, etc. And if many developers can't utilize technology, probably technology is not good enough to be commonly used. Web Services with their WSDL were the best thing. They were too complex, they use XML which is apparently out of fashion today, but the idea was solid, we just need something simpler but with good enough tooling.
I disagree that most apps are CRUD. To the contrary, most apps starting out as naive CRUD have complex implicit constraints related to eg. in what state you can modify resources in a particular way.
Even for CRUD apps with simple master/detail data relationships it doesn't make sense to tie your domain design to network requests.
If you are talking to devices that you can't even access/control, REST is a better way of interacting with the sensors. RPC is out of the question because it tights implementation with the API. However if you talk to a client that you can control, it's up to you, if you want to use RPC then it's fine.
HTTP-JSON—RPC can do this, though. You don’t need the weird hypermedia or pseudo-OO ideas that are usually implied by “REST”; you just need to POST when you need to POST, GET when you need to GET, and set your headers properly.
Most of the benefit of REST over SOAP was the fact that it used HTTP correctly instead of implementing a redundant protocol on top of it. Having machine-readable API contracts is still extremely valuable; we just found better ways of doing that.
Right. HTTP (i.e. REST sans hypermedia) gets you interoperability.
It doesn't get you the "flexibility" of hypermedia/HATEOS, but it depends on your application if you need that. Most projects don't call for 15+ year APIs.
