What differentiates a REST web service from a RPC-like one?

Question

I have a web application that uses AJAX to grab JSON data from the server. It requires that the user first log in with their browser so that a cookie can be set. Only the

Answer 1

REST is best described to work with the resources, where as RPC is more about the actions.

REST: stands for Representational State Transfer. It is a simple way to organize interactions between independent systems. RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

RPC: RPC is basically used to communicate across the different modules to serve user requests. e.g. In openstack like how nova, glance and neutron work together when booting a virtual machine.

REST/RPC:

As a programming approach, REST is a lightweight alternative to Web Services and RPC. Much like Web Services, a REST service is:

1. Platform-independent (you don't care if the server is Unix, the client is a Mac, or anything else),
2. Language-independent (C# can talk to Java, etc.),
3. Standards-based (runs on top of HTTP), and
4. Can easily be used in the presence of firewalls.

Answer 2

hate to break it to you all. RPC is making a local call, that abstracts the underlaying remote behaviour. and guess what? doing REST is the same thing. the argument about REST is about resources is incorrect, you actually directly invoke actions.

I claim REST over HTTP with jsons are a form of RPC.

other popular RPC may include SOAP for example

Answer 3

You are correct about REST being less coupled to the calling object - if you are comparing to a SOAP web service that requires a WSDL file to be called from the server, than yes, REST web services are less coupled (ie require no knowledge of the web service prior to calling it). And most of the time a token needs to be passed along with request for a given 'representation'.

I don't think there is a huge benefit by using REST from ajax, in fact, depending on the API you are dealing with, you may require a token which is passed in as URI parameter (querystring parameter) while using a SOAP based web service, this is not necessary. It is actually quite easy to combine SOAP web services with ajax calls, pass your data in JSON format and deserialize the JSON into an object on the server side. And to top it off, jQuery makes all of this super-easy.

Answer 4

One of the big differences between REST and RPC is that REST is all about resources, and RPC is more about actions. For example, with a truly RESTful service you would never call something like http://domain.com/service/User/jason/add or http://domain.com/service/User/addUser?username=jason. With RESTful service you only ever reference the resource in the URL and then you define what to do with that resource using HTTP verbs and the body of the request. So a GET request to http:/domain.com/service/jason should return information about the resource (the jason user). You could get more specific and say http://domain.com/service/user/jason but the result should be the same. If you were adding a user named jason you would use the exact same URL http://domain.com/service/user/jason but you would use the PUT verb and the body of the request would contain additional data. To delete the jason resource you would, again, use the exact same URL (http://domain.com/service/user/jason) and use the DELETE verb. To update you would use the POST verb.

REST is great for public-facing APIs that you intend for other developers to use. They can be made to be very standard so that they don't require a ton of preexisting knowledge about the service to use. No WSDL calls, etc. Because of the statelessness it can also makes them more stable during partial network failures.

From what you are describing, I do not think you need a truly RESTful service. But you might want to consider, going forward, if you would ever need a more standard API. I made a REST service for a project that I only use for internal use, but that is because I intended to access that service from, potentially, dozens of other service, and in the future possibly from other developers. So even though at first I was only using it for a couple projects, the ultimate goal required a more standard interface.

Answer 5

Think of it this way -- is it the function that matters, or the information that's being acted on?

When you're dealing with REST, you're deaing with a state of information -- you look to see what the current information is (GET), or you change that specific document (POST, DELETE), or you create a new document (PUT).

With RPC, it's about the procedures / function / methods / operations ... whatever you call them in your language. The information is just something that gets operated on or returned from a service ... but it might be one of many. We might be searching, and returning a list of items. Or we might be negotiating something where we need some interaction back and forth. (REST's negotiation for the most part is handled through HTTP, so you have to do things with Accept and Accept-Language header) But it's the operation that's more important.

Then there's the third type, which is document/literal SOAP ... where it's the message that's important, and you have to guess what the function being called is based on the message. If you're just dealing with CRUD operations, this is probably okay. The advantages over REST in this case is that you can still have a WSDL, so you know in advance what the necessary elements are to send, and what to expect in return.

They all work ... it's mostly about how you think about the problem, and how easy it is to convert from what you already have to expose it as an API. If you're starting from the ground up, you can likely do whatever you want. I personally like SOAP (either document/lit or RPC) in that I can give a WSDL file that someone can use to bootstrap their client. I've had cases where people were doing serious queries within a couple of hours. (explaining some of the abstract subtleties of the API, such as the difference between sending an empty string vs. a null took some time, but I would've had the same issues w/ REST)