REST vs RPC: Two Ways to Think About API Design
You’re designing an API for a new service. Should you model it around resources with HTTP verbs, or expose procedures that clients call directly? This isn’t just a protocol choice—it’s a fundamental decision about how you think about your system’s interface.
REST vs RPC API design represents two distinct mindsets, not just two technologies. Understanding when each approach shines (and when to combine them) will save you from architectural headaches down the road.
Key Takeaways
- REST focuses on resources (nouns) with standard HTTP verbs, while RPC focuses on actions (procedures) called with arguments
- REST aligns naturally with HTTP caching and existing web infrastructure, while RPC excels at type safety and streaming
- Most production systems use both: REST for public APIs and RPC for internal service-to-service communication
- The choice depends on your constraints: who consumes the API, caching needs, streaming requirements, and whether operations are resource-based or procedural
The Core Mindset Difference
REST thinks in resources. You have nouns (users, orders, products) and a fixed set of verbs (GET, PUT, DELETE). The URL identifies what you’re operating on, and the HTTP method says how.
RPC thinks in actions. You have procedures (createUser, processPayment, generateReport) that you call with arguments. The focus is on what you want done, not what you’re operating on.
Neither is inherently better. They solve different problems well.
// REST: resource-oriented
GET /users/123
PUT /users/123 { "name": "Alice" }
// RPC: action-oriented
POST /rpc/getUser { "id": 123 }
POST /rpc/updateUserName { "id": 123, "name": "Alice" }Common Misconceptions Worth Clearing Up
REST isn’t “just JSON CRUD.” True REST includes constraints like statelessness, cacheability, and layered systems. Most “REST APIs” are actually HTTP APIs with resource-oriented URLs—which is fine, but it’s not the same thing.
RPC isn’t outdated. Modern implementations like gRPC and Connect power critical infrastructure at Google, Netflix, and countless startups. gRPC runs over HTTP/2 and HTTP/3, with standard routing support in Kubernetes Gateway API.
HTTP APIs vs RPC isn’t binary. Many production systems use REST at the edge (public APIs, browser clients) and RPC internally (service-to-service communication). This hybrid pattern is increasingly common.
Practical Trade-offs That Actually Matter
Caching and HTTP Tooling
REST’s resource model aligns naturally with HTTP caching. A GET /products/123 response can be cached by CDNs, browsers, and proxies without any special configuration.
RPC typically uses POST for everything, which HTTP infrastructure treats as uncacheable by default. You can make RPC cacheable, but it requires explicit design work.
Type Safety and Code Generation
Modern RPC frameworks like gRPC (with Protocol Buffers) and Connect provide strong typing and automatic client generation. You define your service once, then generate clients for TypeScript, Go, Python, and more.
REST has OpenAPI (now at version 3.2, with 3.1 introducing full JSON Schema alignment), which offers similar code generation. But the typing often feels bolted on rather than native.
Discover how at OpenReplay.com.
Streaming and Real-time Data
gRPC supports bidirectional streaming natively. REST requires workarounds—Server-Sent Events, WebSockets, or long-polling.
For browser clients, RPC typically works through gRPC-Web, Connect’s HTTP-friendly protocol, or JSON transcoding. These add complexity but enable streaming patterns that pure REST can’t match.
Error Handling
REST APIs increasingly adopt RFC 9457 (Problem Details) for standardized error responses. RPC frameworks have their own error models—gRPC’s status codes, for instance.
Both work. The key is consistency within your system.
When to Choose What
Lean toward REST when:
- Building public APIs consumed by unknown clients
- Caching is critical to performance
- You want maximum compatibility with existing HTTP tooling
- Your operations map cleanly to CRUD on resources
Lean toward RPC when:
- Building internal service-to-service APIs
- You need streaming or bidirectional communication
- Strong typing and code generation are priorities
- Your operations are genuinely procedural (“reboot server,” “run analysis”)
Use both when:
- You have public-facing APIs (REST) and internal microservices (RPC)
- Different parts of your system have different requirements
The Hybrid Reality
Most modern API architecture patterns don’t pick one approach exclusively. A typical setup might expose a REST API through an API gateway for external consumers while using gRPC between internal services for performance and type safety.
This isn’t a compromise—it’s using the right tool for each context.
Conclusion
Start with your constraints. Who consumes this API? What operations does it need to support? How important is caching? Do you need streaming?
REST vs RPC isn’t about which is “better.” It’s about which mindset—resources or procedures—better matches your problem. Often, the answer is both.
FAQs
Yes, and many production systems do exactly this. A common pattern exposes REST APIs through an API gateway for external consumers while using gRPC for internal service-to-service communication. This approach leverages REST's compatibility with web infrastructure and RPC's performance and type safety where each matters most.
gRPC typically offers better performance due to Protocol Buffers' binary serialization and HTTP/2's multiplexing. However, the difference may be negligible for many applications. REST with JSON is often fast enough, and its caching advantages can outweigh raw speed differences. Choose based on your actual performance requirements rather than theoretical benchmarks.
Both approaches support standard authentication methods. REST typically uses HTTP headers like Authorization with Bearer tokens or API keys. gRPC also uses metadata headers for tokens. The authentication logic remains similar, but gRPC's interceptors provide a clean way to handle auth across all procedures, while REST often uses middleware at the HTTP layer.
You have several options. Create action-oriented endpoints like POST /orders/123/cancel, use custom HTTP methods, or accept that some operations are better modeled as RPC calls. Many APIs use REST for most operations but add RPC-style endpoints for complex procedures. Purity matters less than clarity and usability for your consumers.
Truly understand users experience
See every user interaction, feel every frustration and track all hesitations with OpenReplay — the open-source digital experience platform. It can be self-hosted in minutes, giving you complete control over your customer data. . Check our GitHub repo and join the thousands of developers in our community..
