Search⌘ K
Home
Courses
Grokking the Fundamentals of System Design

API Architectural Styles: REST, GraphQL, RPC

Learn the differences between key API architectural styles, REST, GraphQL, and RPC, and how to choose the right one for your system’s needs.

We'll cover the following...

In any complex application, from a ride-sharing service tracking vehicles to a streaming platform suggesting our next show, countless independent services must communicate seamlessly.

The effectiveness of this communication has a direct impact on system performance, scalability, and maintainability. Choosing the right approach for these services to communicate with each other is one of the most critical decisions in building robust distributed systems.

This decision, API architectural styles, is a frequent topic in System Design interviews, where understanding the trade-offs is key. This lesson explores three dominant API architectural styles: REST, GraphQL, and gRPC. Let’s start by understanding what an architectural style means.

What is an architectural style?

An architectural style defines standardized rules and protocols for designing APIs, ensuring efficiency and consistency throughout the development process. Like communication patterns, these styles provide a structured approach, impacting the entire development life cycle.

When determining an architectural style, we must evaluate the characteristics that suit our design problem. Each style essentially serves as a template with constraints, so we must determine which one suits our requirements.

Let’s take a look at some of the properties we may wish to integrate:

Characteristic

Description

Performance

An API style that performs well and does not become a bottleneck with a large influx of requests.

Scalability

An API style to be easily scalable, such as adding more features and capacity to the back-end servers.

Ease of development

Ease for developers often means opting for a simple and familiar style when implementing a solution.

Portability

The ability to move an API architecture style from one software environment to another.

Software maintenance support

There is ample support offered by the API providers.

Moreover, choosing the right style depends on factors like API consumers, business needs, and functionality, as switching later can be complex. Before examining these modern APIs, it’s essential to understand the foundational communication protocol they evolved from, namely Remote Procedure Calls (RPC).

The RPC and evolution to modern APIs

The earliest challenge in distributed computing was making network communication feel simple.

Developers needed a way to execute code on a remote server as easily as calling a function locally. This led to the creation of the Remote Procedure Call (RPC)A protocol that allows a program on one computer to execute a procedure or subroutine on another computer without the programmer needing to code the details for the remote interaction.. An RPC call works by abstracting the network layer. The client application makes what appears to be a normal function call.

This call is intercepted by a stub, which is a piece of code that acts as a local proxy for the remote service.

Under the hood, the client-side stub serializesThe process of converting data in memory (like a user profile) into a standardized format (such as bytes, JSON, or XML) so it can be stored, sent over a network, and later reconstructed through deserialization. the function parameters into a message and sends it across the network. A server-side stub receives this message, deserializesThe process of converting serialized data (such as bytes, JSON, or XML received over a network) back into an in-memory object that the program can use. it, and calls the actual function on the server. The result is then sent back to the client in the same way. ...