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


2 Answers 2


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.

  • Protocol buffers are thrift seem something really interesting to look deeper into, thank you :)
    – Pijusn
    Apr 22, 2013 at 18:13

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


  • 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.
  • 1
    Please don't associate REST with the old-style SOAP/CORBA/RMI.... Did you mean rpc instead of REST? Sep 13, 2016 at 11:06
  • @EsbenSkovPedersen I also think that he means RPC there. Sep 13, 2016 at 11:49
  • Yes, sorry! I updated my answer! Sep 14, 2016 at 8:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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