REST vs RPC

REST
REST stands for Representational State Transfer.

Consider the case that you are maintaining a blog and posts on the server. Now lets understand REST.

The fundamental philosophy behind REST is that clients should communicate with servers through stateless connections, where:

• Long term state is kept on the server side by maintaining a set of identifiable resources ( posts and comments in our blog case)
• The client can access these resources (perform CRUD operations on them) through a highly limited but uniform interface (a set of URLs in our blog case).
• Computation proceeds by identifying the resource and the CRUD operation you’d like to perform on it.

RPC
 A REST-based web application can be contrasted to a RPC-based web application.

• In RPC-based applications, clients send requests to servers, asking them to execute a specified procedure (available on the server) using the supplied parameters. The server must advertise the services it offers. SOAP is a protocol, developed by Microsoft, that supports this approach.
• REST assumes a simple set of verbs (controller actions/methods) that can operate over a rich set of nouns (resources).
• RPC allows for arbitrary complexity on the server side. The constraints imposed by REST can lead to web applications that easier-to-write and maintain. Rather than implementing remotely accessible services, a simple interface for performing CRUD operations on resources is provided.

More REST vs RPC

Fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients:

• Clients are required to know procedure names;
• Procedure parameters order, types and count matters. It's not that easy to change procedure signatures(number of arguments, order of arguments, argument types etc...) on server side without breaking client implementations;
• RPC style doesn't expose anything but procedure endpoints + procedure arguments. It's impossible for client to determine what can be done next.

On the other hand in REST style it's very easy to guide clients by including control information in representations(HTTP headers + representation). For example:

• It's possible(and actually mandatory) to embed links annotated with link relation types which convey meanings of these URIs;
• Client implementations do not need to depend on particular procedure names and arguments, instead clients depend on message formats. This creates possibility to use already implemented libraries for particular media formats(e.g. Atom, HTML, Collection+JSON, HAL etc...)
• It's possible to easily change URIs without breaking clients as far as they only depend on registered(or domain specific) link relations;
• It's possible to embed form like structures in representations giving clients possibility to expose these descriptions as UI capabilities if end user is human;
• Support for caching is additional advantage;
• Standardized status codes;

There are much more differences and advantages on the REST side.

References

• http://stackoverflow.com/questions/15056878/rest-vs-json-rpc