REST v.s. JSON-RPC in Mobile App

First, HTTP-REST is a "representational state transfer" architecture. This implies a lot of interesting things:

• Your API will be stateless and therefore much easier to design (it's really easy to forget a transition in a complex automaton), and to integrate with independent software parts.
• You will be lead to design read methods as safe ones, which will be easy to cache, and to integrate.
• You will be lead to design write methods as idempotent ones, which will deal much better with timeouts.

Second, HTTP-REST is fully compliant with HTTP (see "safe" and "idempotent" in the previous part), therefore you will be able to reuse HTTP libraries (existing for every existing language) and HTTP reverse proxies, which will give you the ability to implement advanced features (cache, authentication, compression, redirection, rewriting, logging, etc.) with zero line of code.

Fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients:

• Clients are required to know procedure names;
• Procedure parameters order, types and count matters. It's not that easy to change procedure signatures(number of arguments, order of arguments, argument types etc...) on server side without breaking client implementations;
• RPC style doesn't expose anything but procedure endpoints + procedure arguments. It's impossible for client to determine what can be done next.
• etc...

On the other hand in REST style it's very easy to guide clients by including control information in representations(HTTP headers + representation). For example:

• It's possible(and actually mandatory) to embed links annotated with link relation types which convey meanings of these URIs;
• Client implementations do not need to depend on particular procedure names and arguments, instead clients depend on message formats. This creates possibility to use already implemented libraries for particular media formats(e.g. Atom, HTML, Collection+JSON, HAL etc...)
• It's possible to easily change URIs without breaking clients as far as they only depend on registered(or domain specific) link relations;
• It's possible to embed form like structures in representations giving clients possibility to expose these descriptions as UI capabilities if end user is human;
• Support for caching is additional advantage;
• Standardised status codes;
• etc...

Reference:

http://stackoverflow.com/questions/15056878/rest-vs-json-rpc