REST vs RPC, and why REST wins in mobile apps (with Hypermedia)
I have built APIs only for mobile clients (Android and iOS), and they were REST. Not until I had to call APIs in XML-RPC, did I truly understand how REST distinguishes. So here is my brief post about the differences between REST and RPC, and why (I think) REST defeats RPC in mobile apps.
REST and RPC
They are both HTTP protocols, a spec that servers and clients conform to in communication.
According to Roy Fielding’s dissertation, REST is an architectural style to guide the design and development of the architecture for the modern Web. RPC is another set of rules for disparate operating systems in different environments to communicate with each other.
Major Differences between REST and RPC
Let’s take an example of an API to call when a user 12 wants to block a user 39 .
In REST API, the request will be:
In (JSON-)RPC, the request will be:
I’d like to put it this way: they are both languages for communication, and a language has some grammatical rules to keep. REST focuses on nouns, while RPC focuses on verbs.
The URI in REST API talks in nouns. It focuses where the data lies (data representation), and reveals the data modeling. A user data model will have a related model called blockedUser , and there we will put the block relationship.
RPC stresses an action. It calls a server to BlockUser . The subject and object will be delivered in the body, and the URL tells the verb.
Challenges in building APIs of mobile applications
- Response time
30 years ago, researchers proved that within 1 second, users will feel that their thought process is interrupted [Miller 1968; Card et al. 1991]. Considering how impatient we became, the industry standard (2 ms to 1s) does not sound harsh at all. To give some buffer for clients to process the API response, API response time should be shorter than the threshold.
2. API Compatibility
We commit every day. Source code changes, data structure changes, infrastructure changes, and API changes in the end. We can update the web clients as soon as we deploy, but we cannot force users to update their mobile apps. The backend of mobile apps should serve multiple versions at the same time.
Why REST wins in mobile applications
- Lighter payload
As the URI in RPC API simply describes the action, the data representation goes into the body. It reduces the network cost, enabling faster communication between server and client. Considering one page in the client side may trigger multiple requests at once, the response time plays a significant role in user experience.
2. API compatibility thanks to hypermedia
Even though the payload is heavier in RPC, it excels in that the client does not have to know the data modeling in the server. Moreover, the changes in the data modeling and URI can break the API compatibility. That’s where you start to put some ugly tag like v2.
There’s a solution. Hypermedia, a fundamental component in REST API, can show allowed actions (verbs!). The links in the response tells the client to call /users/12/blockedUsers to do block . If the data modeling or URI changes, the response will return the updated endpoint.
Response time and API compatibility were the biggest headaches as a backend developer. I had to spend weeks and months to decrease the response time by a few milliseconds. When there was no other way to support users who never update the app and use the old API, I couldn’t help but put the v5 into the new URIs. I never questioned why the REST API became the go-to architectural style, but now I see why.
