DEFINITION of REST and RPC
REST stands for representational state transfer described by Roy Fielding. REST is all about a client-server relationship, where server-side data are made available through representations of data in simple formats, often JSON and XML. These representations for resources, or collections of resources, which are then potentially modifiable, with actions and relationships being made discoverable via a method known as hypermedia. Hypermedia is fundamental to REST, and is essentially just the concept of providing links to other resources.
Principle of REST:
Client–server – By separating the user interface concerns from the data storage concerns
Stateless – Each request from client to server must contain all of the information necessary to understand the request
Cacheable
Uniform interface - REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
Layered system - constraining component behavior such that each component cannot “see” beyond the immediate layer with which they are interacting.
The “RPC” part stands for “remote procedure call,” and it’s essentially the same as calling a function in JavaScript, PHP, Python and so on, taking a method name and arguments. RPC is a request–response protocol. An RPC is initiated by the client, which sends a request message to a known remote server to execute a specified procedure with supplied parameters. The remote server sends a response to the client, and the application continues its process
Before REST became popular, most APIs were built using an XML-RPC or SOAP now the most popular RPC-call is JSON-RPC
Comparison
| RPC | REST |
|---|---|
| terms of "verbs" | using "noun" naming models the various entities within the problem domain as resources |
| Most use only GET and POST, with GET being used to fetch information and POST being used for everything else | using many differences methods: POST to create, PUT to update, DELETE to remove, and GET to read, and many more methods for providing semantic meaning for specific actions |
| RPC-based APIs are great for actions | REST-based APIs are great for modeling domain |
| RPC-based APIs system will be designed as action-oriented | REST APIs system will be designed as resource-oriented |
Sample RPC-based API:
/*Send a message*/
POST /sendUserMessage HTTP/1.1
Host: api.example.com
{"userId": 501, "message": "Hello!"}
/*Delete something*/
POST /deleteMessage HTTP/1.1
Host: api.example.com
{"messageId": "message_id_in_database", "userId": "501"}
/*Get user status*/
GET /getUserStatus?userId=501 HTTP/1.1
Host: api.example.com
Sample REST-based API:
/*Send a message*/
POST /users/501/messages HTTP/1.1
Host: api.example.com
{"message": "Hello!"}
/*Delete something*/
DELETE /users/501/messages HTTP/1.1
Host: api.example.com
{"messageId": "message_id_in_database"}
/*Get user status*/
GET /users/501/status HTTP/1.1
Host: api.example.com