Is it a requirement that RESTful interactions occur between physically separate clients and servers? i.e. does the interaction need to involve the network stack in some way? Is there any benefit to employing an HTTP-like “calling convention” between the various components of an application?
It seems to me that the benefits of REST, such as they are, are almost as applicable to communication between components of the same application as to communication between physically separate clients and servers, and that REST’s constraints and guiding principles can be satisfied without the network stack being involved. (I’m not suggesting that it’s a good idea for every function call to “look like HTTP”, but for certain function calls or interactions, it might make sense for the interaction to be HTTP-like.)
For example, in a web application it might be useful to access (“internal”) user information via URLs like http://api.local/user/34 and an “HTTP client” that routes and dispatches requests internally, rather than going through a standard HTTP routing and dispatch process. Instead of providing a conventional library and associated documentation, the developer of the user component would provide URL endpoints (resources), which could be manipulated with the standard HTTP verbs. Since developers are already familiar with HTTP, less documentation would be required, and there would be more consistency and uniformity across components.
(I think that thinking about REST in this way also helps clarify the difference between REST and RPC mechanisms like SOAP–there’s no reason to ever use SOAP for “internal” calls, but the understood behaviour and semantics of REST may make it useful for “internal” calls in some situations. And of course if you’re using REST for internal calls (REST Level 0?), it’s trivial to convert such interactions into external calls if the need arises.)
Using REST principles and HTTP semantics in-process definitely does make sense, but probably only if your application also eventually is a client or server communicating with HTTP.
The hard part is honoring the layered constraint of HTTP since it’s so easy to call that singleton on the other sie of the layer, since it’s just a function call away.
One benefit, however is that you can in fact move a layer from one place to another. It’s probably hard to achieve this fully, but I think it’s doable, although I’ll hazard a guess that it’s never been done.
In my own thought experiments for this all of the benefits of HTTP come into play, in ways that mere memcached or in-process caches can’t handle it. Take, for example cache validation, or conditional puts. Imagine being able to make a function call with the expressiveness of a HTTP request:
Or
and
Questions like these are so easy to do in HTTP, and we all know how to forge such complicated queries.
The same goes for HTTP responses:
Again, plain old HTTP. Imagine being able to make method calls that are that smart!
As for HATEOAS, putting some thought into encapsulating identifiers would make it possible to honor that constraint too. But my thought experiments haven’t gone very far in this direction…