Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?).

share|improve this question
Related - – Shauna Apr 22 '13 at 18:04

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.

share|improve this answer
Protocol buffers are thrift seem something really interesting to look deeper into, thank you :) – Pijusn Apr 22 '13 at 18:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.