Accepted answer
Score: 56

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

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

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

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

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

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

Score: 29

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

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

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

There is a nice short comparison on Wikipedia

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

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

Score: 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 14 and REST are compilation of standards from 13 W3C, and the main difference is that SOAP uses 12 HTTP, SMTP and etc. as transport protocols 11 and REST uses it as application protocol, AKA 10 it should support (GET, PUT, PUSH, DELETE, and 9 POST). SOAP also implies using XML and REST 8 could use any data type (JSON, XML, HTTP, etc.). Furthermore, one 7 of the main advantages of SOAP is the Service 6 Descriptor (WSDL file), which gives the 5 possibility of auto-generation of Service 4 Connector (proxy) to the client.

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

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

More Related questions