Is RESTful interaction between physically separate clients and servers required? that is, the interaction needs to somehow connect the network stack? Is there any use to using an HTTP-like “calling convention” between the various components of the application?
It seems to me that the advantages of REST, such as they are, are almost applicable for communication between components of the same application, as well as for communication between physically separate clients and servers, and that REST restrictions and guidelines can be satisfied without the involvement of the network stack. (I do not suggest that a good function for each function call look like HTTP, but for certain function calls or interactions it might make sense that the interaction is HTTP-like.)
For example, in a web application, it may be useful to access ("internal") user information through URLs, such as the http://api.local/user/34"HTTP client", which routes and sends requests internally, instead of going through standard HTTP routing and sending process. Instead of providing a regular library and related documentation, a custom component developer would provide URL endpoints (resources) that could be manipulated with standard HTTP verbs. Since developers are already familiar with HTTP, less documentation will be required and there will be more consistency and uniformity between the components.
(I think that thinking of REST in this way also helps to clarify the difference between REST and RPC mechanisms, such as SOAP - there is no reason to ever use SOAP for "internal" calls, but the understandable behavior and semantics of REST can be useful for "internal" calls in some situations. And, of course, if you use REST for internal calls (REST Level 0?), it is trivial to convert such interactions into external calls if the need arises.)
source
share