REST vs GraphQL vs RPC: When Each One Fits

The problem

API discussions turn into dogma very easily.

One side says REST is the serious standard. Another says GraphQL solves everything. Another treats RPC as if it were forbidden in a well-designed system.

In the end, a lot of decisions come from team hype, not from the real shape of the problem.

The result is usually predictable:

• GraphQL where nobody needed flexible reads
• forced REST for something that is not really a resource
• public RPC without enough thought about compatibility and observability

Mental model

These three styles are not doing the same job all the time.

Think about them like this:

• REST organizes the API around resources and state
• GraphQL organizes reads around what the client wants to assemble
• RPC organizes the interface around actions and commands

None of them is automatically better.

Each one optimizes a different conversation.

Breaking the problem down

Before choosing, answer four questions:

1. Who consumes this API?
2. What dominates this boundary: resource, aggregated read, or command?
3. Where is the real pain: overfetch, evolution, standardization, latency, simplicity?
4. How will this interface be observed, versioned, and maintained?

When REST usually makes sense

REST works well when:

• you have clear resources such as users, orders, products
• the interface needs to be predictable for many clients
• HTTP cache, method semantics, and ecosystem matter
• the API may be used by partners or the public

REST usually shines because of operational simplicity.

You look at route, method, status code, and headers, and the conversation stays understandable.

When GraphQL usually makes sense

GraphQL makes more sense when:

• many different screens assemble data from several places
• the frontend suffers from overfetch and underfetch
• you want the client to choose the read shape
• the domain fits a navigable data graph

But GraphQL is not free.

It brings schema cost, resolver cost, more careful authorization, depth control, less obvious caching, and risk of expensive queries.

When RPC usually makes sense

RPC is very good when:

• the operation is clearly an action, not a resource
• the boundary is internal between services or backend to backend
• you want a direct typed contract
• the operation name communicates better than a generic resource

Natural examples:

• reserveInventory
• calculateShipping
• issueRefund
• generateInvoice

Forcing that into a fake REST resource often makes the interface less clear.

Simple example

Imagine an ecommerce system with three different boundaries.

1. Public API for partners

Partners need to list products, fetch orders, and update inventory.

Here, REST is often a good fit:

• familiar semantics
• easy documentation
• broad client compatibility
• caching and status codes help a lot

2. The product web app and mobile app

One product page needs:

• item information
• stock
• promotional price
• recommendations
• reviews

Another screen needs a different composition.

Here, GraphQL may make sense because it reduces the pain of assembling many different read shapes for UI.

3. Internal communication between services

The order service needs to ask the inventory service to:

reserveInventory

That is an action with very clear semantics.

RPC fits better than trying to hide that intent behind an artificial resource.

Notice the conclusion:

the same system may use more than one style with no contradiction at all

Common mistakes

• Choosing GraphQL because it looks more advanced.
• Treating RPC as architectural error even when the operation is clearly a command.
• Forcing everything into REST and ending up with strange routes for actions.
• Forgetting that a public API carries a higher compatibility and documentation cost.
• Assuming one style needs to dominate 100 percent of the system.

How a senior thinks about it

Someone with more experience rarely asks “which style is best?”

They ask something else:

“Which format makes this boundary clearer, easier to evolve, and cheaper to operate?”

That change in question already improves the decision a lot.

Because it moves the conversation away from personal taste and toward contract, consumer, maintenance, and risk.

What the interviewer wants to see

In interviews, the evaluator usually wants to know whether you can choose by context.

It signals maturity when you:

• explain what each style optimizes
• connect the choice to the type of consumer
• talk about operational trade-offs, not only ergonomics
• admit mixed approaches when the boundary changes

A strong answer often sounds like this:

“If I have clear resources and many clients, REST helps. If the main problem is flexible reads for UI, GraphQL may be worth it. If the boundary is internal and dominated by commands, RPC is usually the more honest interface.”

A good API does not choose fashion. It chooses the right boundary for the right problem.