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 GET and POST verbs are used, where GET is for retrieving data and POST is for any operation that modifies data.

From what I understand, REST differs from the above method in that the user authentication information is sent with every request and the PUT and DELETE verbs are used as well.

My question is, what benefits does a REST web service have over the RPC-like method, if the end point is only meant to be a user's browser? I can understand how REST is beneficial when the client is unknown, but when I'm only using jQuery ajax calls, are the benefits still worth it over an RPC-like method?

Answer 1

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 2

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)