REST vs RPC for mobile development

Question

As many know, mobile development is skyrocketing these days and, I believe, it affects what we code. To be specific, I am interested in developing web services for a mobile application.

I see two possible architectures - RPC and REST. I have developed both, REST and RPC services and what I have observed is that RPC services are way easier to code, especially in languages like PHP. The problem with it seems to be scalability - server-side can easily turn into a mess when many procedures are present.

REST, on the other hand seems to be a lot more structured, server-side becomes relatively easy to maintain but it has a potential to break data into multiple resources which is bad for mobile applications (for multiple reasons).

From what I have experienced, RPC seems a bit better in most cases:

• Both, client- and server- sides, are concerned to minimize number of procedures available and calls made.
• Following architectural rules does not counter with optimizations otherwise possible.

I don't really expect someone to explain me what REST and RPC are, the web is full of that. I want people who has experience developing mobile apps express their opinions about using these two architectures on the server-side. Tips are also welcomed (who doesn't love tips, huh?).

Answer 1

There's little difference, RPC tends to be more binary-protocols than REST, but that doesn't have to be the case. Also RPC tends to be implemented as a single procedure point per call, but again that doesn't have to be - you can implement a single RPC procedure that takes a REST-style verb as the first argument. RPC sometimes has a semi/stateful approach, but again that doesn't have to be the case if you pass in a 'cookie' with each call.

Nowadays it all comes down to development support, and there are more REST APIs for web-based languages, and so people use REST. If you're taking a more user-centric view of development, then you'd probably be better off with a RPC mechanism instead, taking advantage of the flexibility to provide a more compressed binary protocol, then implement it how you like - single procedure that routes to a routine based on an id or 'verb' and is full stateless by passing an id. All of this can be implemented to look very REST-like but with significantly lower overhead.

There are several RPC systems, try protocol buffers or thrift for your mobile app.

Answer 2

You might want to have a look at this article by Netflix about their API redesign: http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html

TL;DR:

• REST in general causes chatty APIs: if an operation needs to manipulate multiple resources, you will need multiple calls (ie. slow!)
• One API doesn't map well to different consumers, which is why Netflix is shifting some of the client code over to the server: each consumer can provide its own adapter / orchestration layer on the server to optimize API access to the different consumers.

Personal note:

• Please don't associate RPC with the old-style SOAP/CORBA/RMI enterprise bloated protocols. For example JSON-RPC is a very simple, elegant and nimble protocol for doing RPC which you should definitely consider.
• REST is perfect for CRUD API's. However, if your API is very action-oriented, you might find it awkward to map this onto REST verbs / endpoints.