Have you considered the merits and applicability of RESTful web apps? Here are a few notes I’ve made.<\/p>\n
There was quite a [discussion about RPC, REST, and message queuing](http:\/\/steve.vinoski.net\/blog\/2008\/07\/13\/protocol-buffers-leaky-rpc) — they are not the same thing. Each one is needed in a different scenario. All are used in building distributed systems.<\/p>\n
Wikipedia’s [explanation of REST](http:\/\/en.wikipedia.org\/wiki\/Representational_State_Transfer) is quite informative, especially their [examples](http:\/\/en.wikipedia.org\/wiki\/Representational_State_Transfer#Example) of RPC versus REST.<\/p>\n
The poster “soabloke” says RPC “Promotes tightly coupled systems which are difficult to
\nscale and maintain. Other abstractions have been more successful in building
\ndistributed systems. One such abstraction is message queueing where systems
\ncommunicate with each other by passing messages through a distributed queue.
\nREST is another completely different abstraction based around the concept of a
\n‘Resource’. Message queuing can be used to simulate RPC-type calls
\n(request\/reply) and REST might commonly use a request\/reply protocol (HTTP) but
\nthey are fundamentally different from RPC as most people conceive it. ”<\/p>\n
The [REST FAQ](http:\/\/rest.blueoxen.net\/cgi-bin\/wiki.pl?RestFaq) says, “Most applications that self-identify as using “RPC” do not conform to the REST. In particular,
\nmost use a single URL to represent the end-point (dispatch point) instead of using a multitude of
\nURLs representing every interesting data object. Then they hide their data objects behind method
\ncalls and parameters, making them unavailable to applications built of the Web. REST-based
\nservices give addresses to every useful data object and use the resources themselves as the
\ntargets for method calls (typically using HTTP methods)… REST is incompatible with
\n‘end-point’ RPC. Either you address data objects (REST) or you don’t.”<\/p>\n
RPC: Remote Procedure Call assumes that people agree on what kinds of procedures they would like
\nto do. RPC is about algorithms, code, etc. that operate on data, rather than about the data
\nitself. Usually fast. Usually binary encoded. Okay for software designed and consumed by a
\nsingle vendor.<\/p>\n
REST: All data is addressed using URLs, and is encoded using a standard MIME type. Data that is
\nmade up of other data would simply have URLs pointing to the other data. Assumes that people
\nwon’t agree on what they want to do with data, so they let people get the data, and act on it
\nindependently, without agreeing on procedures.<\/p>\n","protected":false},"excerpt":{"rendered":"
Have you considered the merits and applicability of RESTful web apps? Here are a few notes I’ve made. There was quite a [discussion about RPC, REST, and message queuing](http:\/\/steve.vinoski.net\/blog\/2008\/07\/13\/protocol-buffers-leaky-rpc) — they are not the same thing. Each one is needed in a different scenario. All are used in building distributed systems. Wikipedia’s [explanation of REST](http:\/\/en.wikipedia.org\/wiki\/Representational_State_Transfer) … <\/p>\n