9

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

Pijusn
  • 987
  • 1
  • 10
  • 16

2 Answers2

6

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.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • Protocol buffers are thrift seem something really interesting to look deeper into, thank you :) – Pijusn Apr 22 '13 at 18:13
5

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.
Dieter Van de Walle
  • 51
  • 1
  • 3