The Dojo Toolkit 1.1 (currently at RC2 stage) has introduced an improved RPC system that provides support for multiple forms of RPC like JSON-RPC and raw POST requests. The new RPC system also supports REST. Understanding the relationship between RPC and REST can help you to fully utilize this new system.

Often Representational State Transfer (REST) style architecture is pitted against Remote Procedure Call (RPC) style architecture. These contrasts may be beneficial for understanding the conceptual motivations and benefits of these two architectures. However, by understanding their relationship, RPC and REST style interaction can both be leveraged harmoniously. By utilizing the right combination of RPC and REST in the appropriate situations you can maximize application manageability, scalability, and efficiency. The relationship can be defined quite easily.

REST is simply a small set of RPC definitions with well-defined conventions and behavior that solve a large class of problems in a highly scalable and well understood manner. An RPC itself, with no further definition, does not make any implications about the effect of the call. An RPC may or may not have side effects, and the nature of side effects are defined by the call itself. On the other hand, REST uses a set of RPCs with defined side effects. REST is based on the concept of resources. One can think of RPCs as any verbs, and REST is a defined set of verbs that operate in regards to resources. Each resource has an associate resource locator string that is associated with the resource. Let’s look at the various REST verbs and how they interact with resources and resource locators. While REST is an architectural style that can be applied in various environments, we will consider HTTP REST since it is overwhelming the most popular and widely implemented form of REST.

rest-rpc.gif
Venn Diagram of RPC and REST
  • GET – A GET is a RPC that returns the content of resource based on a resource locator string. In HTTP, a URL is used to retrieve a resource. A GET is defined to be a safe and idempotent action. This means that the GET does have any side effects, and multiple requests should all have the result as a single request. Because of these agreements on the behavior of GET, caching can be leveraged, which can vastly improve performance. It is important to note that because these methods can be observed at every layer, caching can be utilized at every level. Caching can be used in the server, on the client, and in between with proxy servers, which can facilitate highly parallel and scalable architecture. This may not appear to be an RPC in many cases, since it is often used to simply retrieve the contents of a file from the web server. However, the GET request does still invoke code, even though it may only be the Apache web server code that executes to return the contents of the file.
  • POST – The POST method can generally be viewed as the wildcard verb with no attached definition. While the HTTP specification does make some suggestions about the use of POST (like appending or annotating), POST essentially is the catch all verb for all other RPCs that don’t follow the rules for the other predefined REST verbs. POST actions may have side effects, and may not be idempotent. This means that the HTTP can still be used for the full domain of RPCs without restrictions. Of course POST actions don’t benefit from the meaning and performance enhancements that can be derived from the other verbs.
  • PUT – The PUT method is intended to send the content to be used as replacement for the resource associated with the supplied URI. This method provides a means for a client to alter data from a resource and send a request for the alteration of the resource such that it is not necessary for the client to re-retrieve the resource afterwards to determine the effect. In a generic RPC, a client sends a message to a server, but generally must examine the response of the request, or request any resources that may have been altered, in order to determine the effects of the request. With a PUT, there is an agreement that the client knows the effect of the request, and may continue with its internal knowledge of the resource change unless an error response is received indicating otherwise. A PUT verb is also idempotent. A PUT request can be issued multiple times without any different effect than a single request. Therefore it is not necessary to take any efforts to ensure that the request is only sent once.
  • DELETE – This method is used to delete a resource. This is similar to a PUT method in that the client has an expectation of the side effect of the action. This method is also idempotent. However, the DELETE method is less useful than other methods, since removing resources is generally not desirable on the web, because it results in broken links.

Because of the remarkable ubiquity of the HTTP protocol, these REST methods also provide a very broadly understood semantics for the communication of data access and manipulation. Because of this widely understood vocabulary, REST is increasingly being utilized by data servers like CouchDB, SimpleDB, and Persevere. One shouldn’t feel that they need to base their entire project on a single architectural style. One can always utilize generic RPC commands with POST commands for full flexibility, and one can utilize more specific REST commands like GET, PUT, and DELETE for their more specific and well-defined meaning and the resultant performance benefits. By understanding the RPC and REST capabilities of HTTP, one can combine these two different approaches for optimal efficiency in application development. With the Dojo Toolkit 1.1′s improved RPC services based on SMD definitions, the Dojo Toolkit is now built to handle RPC and REST services so you can leverage both of these mechanisms.