What differentiates a REST web service from a RPC-like one?
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
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.