<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1063935717132479&amp;ev=PageView&amp;noscript=1 https://www.facebook.com/tr?id=1063935717132479&amp;ev=PageView&amp;noscript=1 "> The RPC Concept

The RPC Concept

RPC, Remote Procedure Call, means calling a function on another machine as if it were local. Where REST thinks in nouns (manipulate resources with HTTP verbs: POST /books, DELETE /books/42), RPC thinks in verbs: you call actions directly: CreateBook(), CheckoutBook(42). Both can accomplish the same work; the difference is the mental model and the interface contract. 

REST (resource-oriented)          RPC (action-oriented)
GET    /books    → list books     ListBooks()           → list books
POST   /books    → add a book     CreateBook(title)     → add a book
PUT    /books/1  → update book    UpdateBook(id, title) → update a book
???              → check out?      CheckoutBook(id)      → just say what should happen
feels like a local call your code CheckoutBook(42) client stub Protobuf bytes over HTTP/2 server stub CheckoutBook() runs on the server serialize args → send → deserialize → execute → return the reply
You call CheckoutBook(42) like an ordinary function. The generated stubs serialize the arguments to Protobuf, send them over HTTP/2, and deserialize the reply, so the network round trip stays hidden.

That last row is the tell: actions that don't map cleanly onto create/read/update/delete feel forced in REST (POST /books/1/checkout?) and natural in RPC. The next two lessons cover gRPC, Google's RPC implementation, and Protobuf, the schema and serialization format underneath it.