Web service differences between REST and RPC

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.


As others have said, a key difference is that REST URLs are noun-centric and RPC URLs are 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.

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

Tags:

Web Services

Rest

Rpc

Recent Posts