When you're designing a system that needs to communicate across the network, you're essentially choosing between two very different ways of thinking about what you're doing. RPC and REST both solve the same fundamental problem, but they approach it from opposite angles.
RPC: thinking in function calls
RPC stands for Remote Procedure Call, and the name says it all. You're treating network calls like function calls. When you invoke a remote method, you're saying "execute this procedure on that machine and give me the result." The protocol underneath can be TCP, UDP, HTTP, or something proprietary. That flexibility is both a strength and a weakness.
RPC is synchronous by default. You send a request and wait for a response. The interface is built around methods, so you get a clear contract about what you can call and what arguments it needs. gRPC, Apache Thrift, and older systems like CORBA all work this way. RPC systems often maintain state on the server side, which makes them efficient for certain workloads but complicates scaling because you can't just spin up more servers and treat them interchangeably.
REST: thinking in resources
REST is fundamentally different. Instead of thinking about remote procedures, you think about resources. Everything is a thing you can retrieve, create, update, or delete using standard HTTP verbs. Your API isn't a menu of procedures, it's a collection of nouns accessed through GET, POST, PUT, and DELETE.
REST mandates HTTP and encourages statelessness. Each request contains everything needed to understand it. No server state, no session affinity, no complications with load balancing. You can throw more servers at the problem and they all work the same way. That makes REST naturally scalable, but it also means you lose some efficiency because you're constrained by HTTP's conventions.
The real tradeoffs
RPC is more flexible in the protocols it uses, which matters if you need custom performance optimizations. RPC also often has lower overhead for high-frequency, method-call style interactions. But this flexibility comes at a cost. RPC systems are harder to reason about at scale. They often require more infrastructure to handle state management and affinity.
REST's statelessness is its killer feature. You can cache at every layer. You can put servers anywhere. You can reason about what will happen if one server dies. The entire web infrastructure, all the proxies and CDNs and load balancers, understand HTTP. REST leverages that for free. The tradeoff is that you're constrained by HTTP's semantics. Some problems don't fit neatly into CRUD operations on resources.
Modern systems often mix both. A public API might be REST because it needs to work everywhere. Internal communication might use RPC like gRPC because you control the infrastructure and want efficiency. The choice isn't really about one being better. It's about understanding what each gives you and what it costs.