RPC vs REST vs gRPC: Understanding API Communication

API design often starts with a deceptively simple question:

How should one system communicate with another?

The answer could involve REST, RPC, gRPC, messaging, or other communication models.

REST and RPC are sometimes treated as competing technologies. gRPC is then added to the discussion as if it were simply another version of REST.

That mental model creates confusion.

A better way to understand them is to look at the problem each communication model was designed to solve.

RPC focuses on remote operations.

REST focuses on resources and their representations.

gRPC provides a modern, contract-driven RPC framework that is particularly useful for service-to-service communication.

Understanding these differences also makes another REST concept easier to understand:

statelessness.

What Is RPC?

RPC stands for Remote Procedure Call.

The basic idea is simple:

Make communication with a remote system feel somewhat like calling a function.

Imagine an Order Service needs to reserve inventory.

An RPC-style interface could conceptually expose:

reserveInventory(productId, quantity)

The caller thinks primarily about the operation it wants another service to perform.

The fact that the operation happens across a network is handled by the RPC mechanism.

Why was RPC invented?

RPC is not a microservices invention.

The concept dates back to distributed computing research in the late 1970s, including work by Bruce Jay Nelson.

The fundamental problem was already present:

How can software communicate with a process running on another machine without forcing every application developer to manually handle all the details of network communication?

RPC provided an abstraction around that problem.

RPC’s Mental Model

The easiest way to think about RPC is:

Client → Remote operation → Response

For example:

Order Service
      |
      | reserveInventory()
      ↓
Inventory Service
      |
      ↓
Reservation result

This model can be natural for internal services where the caller and provider are both controlled by the same organization.

It is especially useful when service contracts, efficient communication and operation-oriented interfaces are important.

What Is REST?

REST stands for:

Representational State Transfer.

REST is an architectural style introduced by Roy Fielding in his doctoral dissertation.

One important part of REST is that resources are represented and manipulated using standardized mechanisms such as HTTP.

For example:

POST /payments

could represent creating a payment resource or initiating a payment-related operation, depending on the API design.

A REST API commonly revolves around concepts such as:

Resources
HTTP methods
Representations
Status codes
Stateless interactions
Uniform interfaces

The key mental model is different from RPC.

RPC

Do this operation.

REST

Interact with this resource.

In real-world APIs, the distinction can become blurry, but the architectural ideas are different.

RPC vs REST

Consider a payment system.

An RPC-oriented API might expose something conceptually like:

authorizePayment()

A REST-oriented API might expose:

POST /payments

Both can solve a similar business problem.

But they communicate the problem differently.

CharacteristicRPCRESTPrimary modelOperationsResourcesTypical interactionCall a procedureManipulate a resourceCommon useInternal servicesPublic APIs and integrationsMain strengthDirect operation-oriented communicationInteroperability through HTTPContract styleOften strongly definedCommonly HTTP/resource based

This does not mean REST is only for public APIs or RPC is only for internal systems.

These are common patterns, not absolute rules.

Why Some REST APIs Look Like RPC

Consider endpoints such as:

/createOrder
/approveInvoice
/cancelPayment

They use HTTP.

But conceptually, they are heavily operation-oriented.

That does not automatically make them wrong.

It simply raises an architectural question:

Are we actually modeling resources, or are we exposing commands through HTTP?

This distinction is useful because API design should be driven by the domain and communication requirements—not by simply putting HTTP in front of every operation.

What Does Stateless Mean in REST?

This is one of the concepts that frequently causes confusion.

Imagine a shopping application running ten backend containers.

A user applies a discount coupon.

The request reaches:

Container A

Suppose the application stores important session information only in the memory of Container A.

Later, the user proceeds to payment.

The next request may reach:

Container B

Container B does not have the state that Container A kept in its local memory.

This creates a scalability problem.

The Better Architecture

If the application needs to preserve the coupon state across requests, that state can be stored in an appropriate shared and durable system.

For example:

User
  |
  ↓
Load Balancer
  |
  +------→ Container A
  |
  +------→ Container B
  |
  +------→ Container C
              |
              ↓
         Shared State Store

Now it doesn’t matter which container receives the next request.

The application can retrieve the required state from the shared system.

This is an important reason stateless service design works well with horizontal scaling.

An Important Clarification About REST Statelessness

There is a subtle but important distinction.

REST statelessness does not mean:

The REST API transfers state from the database.

And REST does not require every application to use a database.

Statelessness means that the server does not rely on previously stored client-specific session context to understand a new request.

Each request should contain the information necessary for the server to process it.

Persistent application state can still exist.

For example:

Client
   |
   | Request + required context
   ↓
Service
   |
   ↓
Database / Shared State

The service can retrieve persistent information when needed.

The important point is that the service instance itself should not need to remember the client’s previous interaction in its own local memory.

What Is gRPC?

Now we arrive at gRPC.

The easiest way to understand gRPC is:

gRPC is a modern RPC framework designed for efficient communication between services.

The underlying RPC idea is much older.

gRPC modernized that model for contemporary distributed systems.

Google open-sourced gRPC in 2015.

It became particularly relevant as service-oriented and microservice architectures grew.

Important gRPC Characteristics

HTTP/2

gRPC commonly uses HTTP/2 for transport.

This provides capabilities useful for efficient communication between services.

Protocol Buffers

gRPC commonly uses Protocol Buffers, or protobuf, for serialization.

Instead of sending arbitrary JSON structures, services can define structured messages.

For example:

message ReserveInventoryRequest {
    product_id
    quantity
}

The exact schema depends on the application, but the important idea is that the contract is explicitly defined.

Strong Service Contracts

gRPC services are commonly described through .proto files.

That provides a clear definition of:

Services
Methods
Requests
Responses
Message structures

Code Generation

Tools can generate client and server code from the service definition.

This reduces repetitive implementation work and helps keep the client and server aligned with the contract.

How RPC Evolved Into gRPC

A simplified timeline looks like this:

Late 1970s
    ↓
RPC concept
    ↓
Remote procedures abstract network communication
    ↓
Distributed systems evolve
    ↓
Service-oriented architectures
    ↓
Microservices
    ↓
Need for efficient, strongly typed service communication
    ↓
gRPC

The important insight is:

gRPC did not invent RPC.

It brought the RPC model into a modern ecosystem with mechanisms designed for contemporary distributed applications.

REST vs gRPC: When Should You Use Which?

There is no universal winner.

The better question is:

What does this communication boundary require?

REST can be a good fit when:

External clients need to consume the API.
Interoperability is important.
HTTP semantics are useful.
Ease of adoption matters.
The API represents resources naturally.

For example:

Mobile App
     ↓
REST API
     ↓
Backend

gRPC can be a good fit when:

Services communicate internally.
Strong contracts are valuable.
Efficient serialization matters.
Generated clients are useful.
Performance requirements justify the additional complexity.

For example:

Order Service
      |
      | gRPC
      ↓
Inventory Service
      |
      | gRPC
      ↓
Pricing Service

Again, these are common architectural patterns, not hard rules.

A system can use both.

One Architecture Can Use REST and gRPC Together

A practical architecture could look like:

Web / Mobile Client
        |
        | REST / HTTP
        ↓
   API Layer
        |
        | gRPC
        ↓
+----------------------+
| Internal Services    |
|                      |
| Order                |
| Inventory            |
| Payment              |
| Pricing              |
+----------------------+
        |
        ↓
 Databases / Messaging

Why would this make sense?

The external boundary may prioritize interoperability and accessibility.

The internal boundary may prioritize efficient, strongly contracted communication.

Different boundaries can have different requirements.

Common Engineering Mistakes

1. Choosing technology before understanding the problem

A team may choose gRPC simply because it is popular.

Another team may use REST everywhere because it is familiar.

Neither approach automatically produces good architecture.

Start with the requirements.

2. Assuming gRPC is always faster and therefore always better

Performance is only one architectural concern.

A technology also has costs around:

Tooling
Debugging
Operational complexity
Client compatibility
Developer familiarity
Infrastructure requirements

The fastest communication mechanism is not automatically the best choice for every system.

3. Treating HTTP + JSON as automatically RESTful

An API can use HTTP and JSON while still being strongly operation-oriented.

The underlying architectural design matters.

4. Storing important session state only inside one container

This creates problems when requests can move between instances.

If state must survive across requests, place it in an appropriate shared system rather than depending on the memory of one backend instance.

A Simple Decision Framework

Before selecting REST, RPC or gRPC, ask five questions.

1. Who is calling?

Is it:

A browser?
A mobile application?
A partner?
Another internal service?

2. What are you modeling?

Is the interaction primarily:

Resource-oriented?
Operation-oriented?

3. How important is interoperability?

External consumers often benefit from familiar HTTP-based interfaces.

4. How important are strong contracts and efficient service communication?

For controlled internal environments, gRPC can be a strong option.

5. Where does application state live?

Ask:

Can any service instance handle the next request?

If the answer is no because critical client state exists only in one instance’s memory, the architecture deserves another look.

The Bigger System Design Lesson

RPC, REST and gRPC may look like API technology choices.

But underneath them is a larger system-design question:

How do we design boundaries between distributed components?

Those boundaries determine:

How services communicate
How state is managed
How systems scale
How contracts evolve
How clients integrate
How failures are handled

The protocol is only one piece of the architecture.

Good engineers don’t ask:

“Which technology is the best?”

They ask:

“Which communication model best fits this boundary?”

Key Takeaways

RPC

Think:

Remote operation

It is useful when the interaction naturally looks like calling a service operation.

REST

Think:

Resources + HTTP semantics + stateless interactions

It is widely useful for APIs where interoperability and web conventions matter.

gRPC

Think:

Modern, contract-driven RPC

It is particularly useful for many internal service-to-service scenarios.

REST Statelessness

Think:

Don’t make a service instance depend on remembering a client’s previous request.

Shared persistent state can live outside the individual service instance when the application needs it.

Final Thought

There is no universal answer to:

REST or gRPC?

The better answer starts with the boundary.

Who is communicating?

What are they communicating?

What state must survive?

How strongly should the contract be defined?

How important are interoperability, performance and simplicity?

Once those questions are clear, the technology choice becomes much easier.

Architecture should follow the problem—not the trend.

What would you choose for a new internal microservice architecture today: REST or gRPC?

RPC vs REST vs gRPC: Understanding API Communication and REST Statelessness

RPC vs REST vs gRPC: Understanding API Communication

What Is RPC?

Why was RPC invented?

RPC’s Mental Model

What Is REST?

RPC

REST

RPC vs REST

Why Some REST APIs Look Like RPC

What Does Stateless Mean in REST?

The Better Architecture

An Important Clarification About REST Statelessness

What Is gRPC?

Important gRPC Characteristics

HTTP/2

Protocol Buffers

Strong Service Contracts

Code Generation

How RPC Evolved Into gRPC

REST vs gRPC: When Should You Use Which?

REST can be a good fit when:

gRPC can be a good fit when:

One Architecture Can Use REST and gRPC Together

Common Engineering Mistakes

1. Choosing technology before understanding the problem

2. Assuming gRPC is always faster and therefore always better

3. Treating HTTP + JSON as automatically RESTful

4. Storing important session state only inside one container

A Simple Decision Framework

1. Who is calling?

2. What are you modeling?

3. How important is interoperability?

4. How important are strong contracts and efficient service communication?

5. Where does application state live?

The Bigger System Design Lesson

Key Takeaways

RPC

REST

gRPC

REST Statelessness

Final Thought

You might like