40

I'm building my own Ajax website, and I'm contemplating between REST and RPC.

If my server supported Servlets I'd just install persevere and end the problem, but my server doesn't support Servlets.

RPC is simpler to code (IMO) and can be written in PHP easily. All I need is a database query executer. I'm using the Dojo Toolkit and JSON.

Why should I choose REST over RPC or RPC over REST?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
the_drow
  • 18,571
  • 25
  • 126
  • 193

3 Answers3

55

The best way to understand it is to read Roy T. Fielding's dissertation on it, or relevant articles on his blog where he discusses the differences between pure REST and simply RPC architectures.

Another thing to note is that the Wikipedia article on REST is in dismal condition and Fielding himself, the 'inventor' of REST, suggests that the article is inaccurate.

The biggest thing people miss with REST is discoverability - resources should include URIs for other related resources inside their hypertext, instead of relying on URI naming conventions, which are out-of-band and non-standardized.

A big problem with popular RPC implementations like SOAP or XML-RPC is that they use HTTP underneath their own proprietary architecture, rather than taking advantage of all the different properties of HTTP like PUT, GET, DELETE etc. So this doesn't fit the traditional web stack as well - a cache server in the middle doesn't work, for example, without knowing about the meaning of the contents of the RPC call.

This is an incomplete introduction to REST and RPC but I think I've highlighted some of the important points that are often missed. Be careful, since there is a LOT of wrong information out there on REST.

That said, REST is not for everything. It's an architecture, so it's rather flexible how you can implement it. But if it doesn't make sense to access things primarily as resources, then REST may not fit, or it may only fit for parts of your application, which is fine.

Tyson
  • 1,685
  • 15
  • 36
aehlke
  • 15,225
  • 5
  • 36
  • 45
  • Hypermedia controller as significantly helped the discoverability of rest services. – Amir Jul 28 '11 at 22:44
  • 6
    Want to point out that what you call "a big problem with popular RPC" can also be a big advantage, depending on what your goals are. If you rely on HTTP's action verbs, you are now tied to HTTP. In many system architectures, it may be desirable to make RPC calls over a variety of different transport mechanisms (HTTP, sockets, message queues, etc). Often our choice of HTTP has more to do with its ubiquity than it actually being the ideal transport protocol (see the myriad of browser solutions to tunnel things through HTTP, e.g. BOSH). There are just a lot of trade-offs to consider. – DougW Nov 15 '12 at 22:03
  • @DougW, absolutely true. There are ways to use REST without HTTP but I don't know about a protocol-agnostic REST. – aehlke Nov 16 '12 at 00:08
  • 3
    REST vs RPC is actually a false dichotomy, what people usually mean when they ask this question is whether to expose services in a RESTful way using vanilla HTTP or whether to use RPC to build a more customized interface. I've seen this question come up often; you may find this post helpful: http://www.etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/. – Tyson Dec 04 '12 at 22:47
29

Uhm ... to put it simple, both are very abstract models ... so abstract, they naturally occur everywhere...

REST is the idea of having resources addressed with a global identifier (the URI in the case of HTTP) that are accessed in a CRUD way (using POST, GET, PUT and DELETE in the case of HTTP ... well, at least that's the idea)...

RPC is the idea where you call a procedure on a different machine, passing in some parameters, and taking a return value...

There is a nice short comparison on Wikipedia

Persevere creates a service, that allows both (in a very elegant way, admittedly) ... it is RESTful (although it does not only use HTTP-features to achieve this) and exposes an RPC interface...

In the end, you should look at what your application needs to do ... as most people, you'll probably wind up with an RPC API (be it based on XML or JSON or whatever), that includes a transport layer for a partially RESTful subsystem ... this is, because having RESTfulnes, means flexibility ... if the client can more or less freely traverse the data on the server (through a set of simple CRUD methods), it does not depend on a limited (problem-specific) set of methods exposed through the API, and you can shift logic clientwards...

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
back2dos
  • 15,588
  • 34
  • 50
  • 27
    REST has nothing to do with CRUD. – aehlke Jul 20 '09 at 19:20
  • 10
    One may be forgiven for thinking of REST in terms of CRUD. It's a common misunderstanding. Here's the explanation: "... by shedding the CRUD (Create, Retrieve, Update, Delete) mapping from GPPD (GET, POST, PUT, DELETE) you can use REST the way it was supposed to be used. There is nothing wrong with using a POST to delete, update or create resources, as long as you are POSTing to the proper resource." - from http://blog.jonnay.net/archives/642-REST-!-CRUD!.html – Wayne Bloss Aug 18 '10 at 18:39
  • Your link contains misunderstandings of REST, unfortunately, which mars its message. If you wanted to delete resources, you wouldn't specify IDs - you would specify URIs of resources to be deleted. – aehlke Sep 21 '10 at 11:38
  • 39
    CRUD maps directly to REST and there are real-world implementations of this. See CouchDB. It not a misunderstanding to say that REST is CRUD because REST basically is the CRUD of the web. The fact that REST is also _much more_ than CRUD is irrelevant. It's like saying that an astronaut is not a person because he's an astronaut. – Wayne Bloss Apr 09 '11 at 06:35
  • 5
    @wizlb, I'm confused, is it finally a misunderstanding or is it not? – Saeb Amini Oct 31 '12 at 13:57
  • 4
    If you are doing REST right, everything will "seem" like CRUD because you are essentially CRUDing states. – thomas-peter Sep 03 '13 at 17:02
6

There are three different styles of services:

  • RPC API - the client sends a procedure and parameters to service and the service is responsible for the executing of the command and returning a result.
  • Message API (Document API) - the client sends DOMs (elements), which normally are more complex structures than RPC API calls, because they tend to do not imply operations directly.
  • Resource API - is used for accessing resources (database tuples, files, images and etc.). In general it should also provide good Media Type Negotiation.

SOAP and REST are compilation of standards from W3C, and the main difference is that SOAP uses HTTP, SMTP and etc. as transport protocols and REST uses it as application protocol, AKA it should support (GET, PUT, PUSH, DELETE, and POST). SOAP also implies using XML and REST could use any data type (JSON, XML, HTTP, etc.). Furthermore, one of the main advantages of SOAP is the Service Descriptor (WSDL file), which gives the possibility of auto-generation of Service Connector (proxy) to the client.

There is not a silver bullet; the type and architecture of a web service are dependent on the actual client and technology requirements.

For a general idea on the subject, see one of the Martin Fowler signature books - Service Design Patterns

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Kalina Todorova
  • 69
  • 1
  • 3
  • You can document REST services using WSDL 2.0 or WADL http://rest.elkstein.org/2008/02/documenting-rest-services-wsdl-and-wadl.html – icc97 Nov 13 '15 at 11:22