Post-REST
REST for the control plane works because there are few enough "resources" that you can have a URI for each and CRUD works.  Much more importantly, the pressure to have complex multi-resource transactions is low because the control plane tends to have simple schemas and there is no need to do complex multi-resource transactions with any kind of atomicity.The data plane is not at all like that.  There can be many many resources, and very complex transactions.PostgREST, a REST interface to PostgreSQL, shows you can have REST for the data plane, but it achieves that by forcing one to have simple transactions with any and all complexity wrapped into PG functions so that the REST interface can remain simple.The place where REST falls down, really, is transactions.  For simple enough schemas and transactions involving only one relation, it's easy enough to have URIs for resources and collections.  But for anything much more complex than that REST simply fails.  Instead one ends up writing an end-point that accepts POSTs whose request bodies encode complex transactions, and this ends up resembling SOAP (basically RPC over HTTP) rather than REST.Imagine an HTTP/1.1 verb named TRANSACT whose body consists of a concatenation of the requests that you really want to do, and with a header controlling / reflecting transaction control options (e.g., atomicity).  If HTTP had such a thing, then it would be a lot easier to build a proper RESTful interface to the data plane.  But HTTP has no such thing, and probably never will.Incidentally, it's useful to consider how NFSv3 had RPCs for every little thing, while NFSv4 has only one RPC (COMPOUND) that is... a lot like the TRANSACT I imagine above -- it's just not that crazy a thing to imagine.  The transaction complexity problem in HTTP is not unique to HTTP!