RPC or REST; Which one is best suited for your Web API ?

When we design an api for our software components, then a couple of confusing terms are just at the front of us.
Let's first cope with the conceptual confusion about the terms in this question.

What is an API ?

API is the acronym for the Application Programming Interface.

  • It is a group of methods 
  • that is exported by a provider software components/modules 
  • and is supplied to its consumer software components/modules
  • and the messages(XML, JSON, etc.) of these method calls are transported accross the client and server sides.


In the context of web, an API is refered as a group of methods that is
  • the web protocol HTTP is used for the communication 
  • by transferring the messages, 
  • generally of the form; XML or JSON format.
Okay then, if a consumer is using an API; then
  • it is communicating via a service provider
  • with dependency to a contract defined by the API
  • over some communication protocols such as HTTP
  • and exchanging the messages in a structured formats such as XML, JSON etc.

RPC or RPC style ?

The big confusion is about the term RPC. 
Is the context of the term RPC used is of the distributed communication protocol or about the api design ?
This is the key question that i think, makes the confusion about the term.

RPC Protocol

  • RPC stands for Remote Procedure Call.
  • Simply meaning that, making a call in your local host and having that call execute a service/procedure on a remote host.
The idea is simple but different implementations of RPC is out there to mention about:
  • Implementation over seperate interface definition using messaging protocols such as SOAP, thrift etc.
    • With that kind of RPC implementation, client and server can communicate over an agreed messaging protocol such as SOAP 
    • even if they are different technology stack such as one is Java and other is .net.
  • A more technology-dependent implementation of RPC is Java RMI. 
    • It is a tighter coupled implementation in which both client and server sides must be implemented with Java.
RPC is said to be protocol-agnostic, meaning that; RPC implementations can run with different networking protocols
  • XML-RPC and SOAP-RPC, in which messages are serialized/deserialized as using XML, nominally make requests using HTTP POST.
  • Other implementations can use of different networking protocols such as TCP
A key challenge when using RPC is the binary stub generation which leads to tightly coupled client and server deployments.

Okay, now we have a general idea about the RPC protocol, then what is RPC-style ?
Let's firstly inspect the REST side.

Why is the REST architecture style needed ?

RPC is a remote procedure call technique that can run over any communication protocol. However, any of the rpc-based distributed communication techniques like CORBA, DCOM, RMI have some drawbacks in communication since of the concerns;
  • lack of standardized messaging template (mostly a binary messaging protocol is used)
  • lack of standardized application layer protocol
  • tightly coupling between client and server
  • difficulty for designing in case of client and server sides are of different programming models.

And here comes; the Simple Object Access Protocol, SOAP

In that part of the game, SOAP has come to play, as a successor of XML-RPC, with using a standardized XML-based messaging template driven by Microsoft with the benefits:
  • standardized XML-based messaging template
  • communcation-protocol agnostic, mostly HTTP; but HTTP, SMTP, TCP, UDP or JMS can be used.
  • implementable easily by any programming languages
SOAP is well-suited and mostly used for implementing service oriented architectures(SOA) and still has the place of in the game.
However it has some drawbacks;
  • requires overmuch bandwith since of its generality and XML markups
  • altough its name begins with SIMPLE, in reality it's a bit complicated.
And so, the distributed computing ecosystem heads for an alternative player, which leads us to REST.
REST has come to play with using HTTP as a communication protocol which is the standardized application-layer protocol for webservers and nominally JSON or less of XML as the messaging template.


  • REST stands for Representational State Transfer.
  • RESTful means; an architecture that satisfies the constraints of REST architecture style.
  • HTTP is the de facto communication protocol when working REST since;
  • the key idea on REST is manipulating resources identified by URIs with CRUD operations 
  • that semantically projects to standard HTTP verbs; GET, POST, PUT, DELETE
  • and that makes us name it simply; CRUD over HTTP.
As it seems, REST is much like a specialized version of RPC protocol as such;
  • It is a way of calling a remote execution as in RPC
  • It uses nominally HTTP(altough it does not define a communication protocol); while RPC is protocol-agnostic
  • The procedures that REST will execute are certain which are CRUD operations that semantically span HTTP verbs.

Then here comes a brain burner;

If REST is of CRUD based architecture design, then how can it fit for domain driven design concept ?

To be continued..





Dependency Injection In Java and CDI


Spring Components & Auto Scanning & Configuration