Web service differences between REST and RPC

Question

I have a web service that accepts JSON parameters and have specific URLs for methods, e.g.:

http://IP:PORT/API/getAllData?p={JSON}

This is definitely not REST as it is not stateless. It takes cookies into account and has its own session.

Is it RPC? What is the difference between RPC and REST?

Answer 1

There are bunch of good answers here. I would still refer you to this google blog as it does a really good job of discussing the differences between RPC & REST and captures something that I didn't read in any of the answers here.

I would quote a paragraph from the same link that stood out to me:

REST itself is a description of the design principles that underpin HTTP and the world-wide web. But because HTTP is the only commercially important REST API, we can mostly avoid discussing REST and just focus on HTTP. This substitution is useful because there is a lot of confusion and variability in what people think REST means in the context of APIs, but there is much greater clarity and agreement on what HTTP itself is. The HTTP model is the perfect inverse of the RPC model—in the RPC model, the addressable units are procedures, and the entities of the problem domain are hidden behind the procedures. In the HTTP model, the addressable units are the entities themselves and the behaviors of the system are hidden behind the entities as side-effects of creating, updating, or deleting them.

Answer 2

It is RPC using http. A correct implementation of REST should be different from RPC. To have a logic to process data, like a method/function, is RPC. getAllData() is an intelligent method. REST cannot have intelligence, it should be dump data that can be queried by an external intelligence.

Most implementation these days are RPC but many mistakenly call it as REST. REST with HTTP is the saviour and SOAP with XML the villain. So your confusion is justified and you are right, it is not REST.

Http protocol does not make an implementation of REST. Both REST(GET, POST, PUT, PATCH, DELETE) and RPC(GET + POST) can be developed through HTTP(eg:through a web API project in visual studio).

Fine, but what is REST then? Richardson maturity model is given below(summarized). Only level 3 is RESTful.

• Level 0: Http POST
• Level 1: each resource/entity has a URI (but still only POST)
• Level 2: Both POST and GET can be used
• Level 3(RESTful): Uses HATEOAS (hyper media links) or in other words self exploratory links

eg: level 3(HATEOAS):

1. Link states this object can be updated this way, and added this way.

2. Link states this object can only be read and this is how we do it.

   Clearly, sending data is not enough to become REST, but how to query the data, should be mentioned too. But then again, why the 4 steps? Why can't it be just Step 4 and call it REST? Richardson just gave us a step by step approach to get there, that is all.

You've built web sites that can be used by humans. But can you also build web sites that are usable by machines? That's where the future lies, and RESTful Web Services shows you how to do it.

• This book RESTful Web Services helps
• A very interesting read RPC vs REST

Answer 3

As others have said, a key difference is that REST is noun-centric and RPC is verb-centric. I just wanted to include this clear table of examples demonstrating that:

---------------------------+-------------------------------------+--------------------------
 Operation                 | RPC (operation)                     | REST (resource)
---------------------------+-------------------------------------+--------------------------
 Signup                    | POST /signup                        | POST /persons           
---------------------------+-------------------------------------+--------------------------
 Resign                    | POST /resign                        | DELETE /persons/1234    
---------------------------+-------------------------------------+--------------------------
 Read person               | GET /readPerson?personid=1234       | GET /persons/1234       
---------------------------+-------------------------------------+--------------------------
 Read person's items list  | GET /readUsersItemsList?userid=1234 | GET /persons/1234/items 
---------------------------+-------------------------------------+--------------------------
 Add item to person's list | POST /addItemToUsersItemsList       | POST /persons/1234/items
---------------------------+-------------------------------------+--------------------------
 Update item               | POST /modifyItem                    | PUT /items/456          
---------------------------+-------------------------------------+--------------------------
 Delete item               | POST /removeItem?itemId=456         | DELETE /items/456       
---------------------------+-------------------------------------+--------------------------

Notes

• As the table shows, REST tends to use URL path parameters to identify specific resources
  (e.g. GET /persons/1234), whereas RPC tends to use query parameters for function inputs
  (e.g. GET /readPerson?personid=1234).
• Not shown in the table is how a REST API would handle filtering, which would typically involve query parameters (e.g. GET /persons?height=tall).
• Also not shown is how with either system, when you do create/update operations, additional data is probably passed in via the message body (e.g. when you do POST /signup or POST /persons, you include data describing the new person).
• Of course, none of this is set in stone, but it gives you an idea of what you are likely to encounter and how you might want to organize your own API for consistency. For further discussion of REST URL design, see this question.

Answer 4

This is how I understand and use them in different use cases:

Example: Restaurant Management

use-case for REST: order management

- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123

For resource management, REST is clean. One endpoint with pre-defined actions. It can be seen a way to expose a DB (Sql or NoSql) or class instances to the world.

Implementation Example:

class order:
    on_get(self, req, resp): doThis.
    on_patch(self, req, resp): doThat.

Framework Example: Falcon for python.

use-case for RPC: operation management

- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123

For analytical, operational, non-responsive, non-representative, action-based jobs, RPC works better and it is very natural to think functional.

Implementation Example:

@route('/operation/cook/<orderId>')
def cook(orderId): doThis.

@route('/operation/serve/<orderId>')
def serve(orderId): doThat.

Framework Example: Flask for python

Answer 5

You can't make a clear separation between REST or RPC just by looking at what you posted.

One constraint of REST is that it has to be stateless. If you have a session then you have state so you can't call your service RESTful.

The fact that you have an action in your URL (i.e. getAllData) is an indication towards RPC. In REST you exchange representations and the operation you perform is dictated by the HTTP verbs. Also, in REST, Content negotiation isn't performed with a ?p={JSON} parameter.

Don't know if your service is RPC, but it is not RESTful. You can learn about the difference online, here's an article to get you started: Debunking the Myths of RPC & REST. You know better what's inside your service so compare it's functions to what RPC is and draw your own conclusions.

Answer 6

Consider the following example of HTTP APIs that model orders being placed in a restaurant.

• The RPC API thinks in terms of "verbs", exposing the restaurant functionality as function calls that accept parameters, and invokes these functions via the HTTP verb that seems most appropriate - a 'get' for a query, and so on, but the name of the verb is purely incidental and has no real bearing on the actual functionality, since you're calling a different URL each time. Return codes are hand-coded, and part of the service contract.
• The REST API, in contrast, models the various entities within the problem domain as resources, and uses HTTP verbs to represent transactions against these resources - POST to create, PUT to update, and GET to read. All of these verbs, invoked on the same URL, provide different functionality. Common HTTP return codes are used to convey status of the requests.

Placing an Order:

• RPC: http://MyRestaurant:8080/Orders/PlaceOrder (POST: {Tacos object})
• REST: http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (POST: {Tacos object})

Retrieving an Order:

• RPC: http://MyRestaurant:8080/Orders/GetOrder?OrderNumber=asdf (GET)
• REST: http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (GET)

Updating an Order:

• RPC: http://MyRestaurant:8080/Orders/UpdateOrder (PUT: {Pineapple Tacos object})
• REST: http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (PUT: {Pineapple Tacos object})

Example taken from sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc