Hello,
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?
Thanks a lot,
Omer.
uhm ... to put it simple, both are very abstract models ... so abstract, they naturally occur everewhere ...
REST is the idea of some resources addressed with a global identifier (the URI in the case of HTTP) 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 it the idea, that you call a procedure on a different machine, passing in some parameters, and taking a return value ...
there is a nice short comparison on the wiki
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 and RPC interface ...
in the end, you should look at what your app 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 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 ...
REST is actually a subset of RPC. 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 RPC is that it uses HTTP just like a proxy service for its 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.