REST and RPC (2020)

Estimated reading time: 2 minutes.

REST and RPC are cornerstones of modern networked development and are two ways to approach the same problem: I have a client, I have a server, and I want to make them talk to each other to coordinate and synchronize.

RPC is the simplest option. It is simply calling a method on the server and allowing it to mutate state. REST is a set of constraints implemented on top of that.

RPC is the most ‘natural’ model for most developers. If something needs to change, you simply call a method and it's transparently routed to the server where processing happens. It doesn't make you think about the fact you're working over a network. REST is more difficult to use but confers benefits—it creates a limited vocabulary for what you can ask the server to do. E.g., when applied to HTTP:

  • GET: Read
  • PUT: Replace
  • POST: Create
  • DELETE: Remove

RPC is extremely flexible, but generally poorly discoverable. Given an RPC endpoint, you will not be able to accomplish much without documentation on what methods are available and the proper order to call them in. It can also lead to a very tight integration between software architecture and network protocol.

REST, with its limited vocabulary, is relatively straightforward. There are no complicated flows—you're simply passing objects back and forth. You GET a copy of an object, you mutate it, you PUT and replace the copy on the server. The vocabulary is fixed and known. This simplicity and lack of state confers a lot of advantages particularly allowing the server to be scaled out and requests to be proxied and cached more easily. For that reason REST is generally considered superior for most applications.

Both methods have their applications. For example, imagine a FPS with a client/server model.

In RPC, the client may tell the server ‘move(forward, ONE_STEP)’. With REST, this would be more naturally implemented as ‘get the position; position.y += UNITS_PER_STEP; replace the position with the updated state’.

The RPC method means that the server must maintain the full game state in order to properly execute requests. You could not load balance these requests across multiple servers without great complexity. This provides greater context to the request and naturally leads to performing the processing on the server such that the server can perform validation and ensure that the move is valid.

The REST method means the server does not require any game state in order to execute the client's request. However, this does not naturally lend itself to anything but trusting the client. The client could simply override its position with arbitrary coordinates and replace the state on the server allowing it to teleport.

Put another way, REST is for transmitting objects and RPC is for transmitting actions. RPC thinks in terms of verbs while REST thinks in terms of data models. The two aren't mutually exclusive, but try not to mix them unless you have a good grasp on why you're doing so.

Further Reading

This article discusses these two approaches in the context of building HTTP APIs, because that is how they are most commonly used.