Remote Procedure Call (RPC) Essentials

Overview

Remote Procedure Call (RPC) is an interprocess communication protocol designed to facilitate interaction within distributed systems. It acts as a mechanism for back-end services to execute code on a remote server as simply as calling a local function. While RPC is favored for its high performance and action-oriented design in internal or complex workflows, it contrasts with RESTful APIs, which are resource-oriented and leverage standard HTTP semantics for scalability and public exposure.

Core Concepts and Benefits

• Definition: RPC stands for Remote Procedure Call. It is a protocol widely used in distributed systems to enable interprocess communication.

• Primary Benefit: Back-end services utilize RPC because it provides a simple abstraction, allowing developers to call remote code as if it were a local function. This approach generally offers high performance for internal service communication.

Comparison: RPC vs. RESTful API

Feature	RPC	RESTful API
Design Philosophy	Action-oriented (What you want to do)	Resource-oriented (What you’re operating on)
HTTP Methods	Typically uses POST for all operations	Uses GET, POST, PUT, DELETE, PATCH with specific meanings
Request Example	POST /api with {method: "getUser", params: {id: 123}}	GET /users/123
Function Call Style	Calls remote functions directly	Interacts with resources via HTTP verbs
URL Structure	Action-based (/api, /rpc)	Resource-based (/users, /posts, /comments)
HTTP Semantics	Ignores HTTP semantics; everything is POST	Leverages HTTP semantics fully
Caching	Difficult to cache (POST requests not cached by default)	Easy to cache (GET requests naturally cacheable)
Statefulness	Can maintain state between calls	Explicitly stateless (each request is independent)
Idempotency	Not necessarily idempotent	GET/PUT/DELETE are idempotent by design
Learning Curve	Easier for those familiar with function calls	Requires understanding REST principles
Documentation	Requires detailed documentation of methods	Self-documenting through URL structure
Data Format	JSON-RPC, XML-RPC, etc.	Typically JSON, but flexible
Error Handling	Custom error handling per method	Standard HTTP status codes (200, 404, 500, etc.)
Use Case	Action-focused (sendEmail, processPayment)	CRUD operations on resources
Scalability	Can be less efficient with stateful interactions	Highly scalable due to stateless nature
Browser-Friendly	Not ideal for browser testing	Easy to test in browser address bar
API Gateway Compatibility	More challenging to implement gateway patterns	Naturally suited for API gateways and proxies
Versioning	Via method names or parameters	Via URL paths or headers
Real-time Communication	Can be bidirectional but complex	Typically request-response only

The distinction between RPC and RESTful APIs lies in their design philosophies, usage of HTTP, and operational behaviors.

• Design Philosophy:

  • RPC: Action-oriented, focusing on “what you want to do” (e.g., processPayment).

  • REST: Resource-oriented, focusing on “what you are operating on” (e.g., accessing /users).

• HTTP Methods and Semantics:

  • RPC: Typically uses the POST method for all operations and ignores standard HTTP semantics.

  • REST: Fully leverages HTTP semantics, using specific verbs like GET, POST, PUT, DELETE, and PATCH with standard status codes (200, 404, 500).

• Structure and Documentation:

  • RPC: Uses action-based URL structures (e.g., /api, /rpc) and calls remote functions directly. It requires detailed documentation for methods and custom error handling.

  • REST: Uses resource-based URLs (e.g., /users, /posts) which are often self-documenting. It is browser-friendly and easily tested via the address bar.

• Performance and State:

  • RPC: Can maintain state between calls but is difficult to cache because POST requests are not cached by default. It may be less efficient regarding scalability for stateful interactions.

  • REST: Explicitly stateless, making it highly scalable and easy to cache (particularly GET requests).

Strategic Use Cases

RPC is specifically recommended for scenarios where actions and complex logic take precedence over resource management.

• Action-Heavy Operations: Ideal for functions that perform specific tasks rather than simple data manipulation. For example, a processPayment method with parameters for user ID, amount, and currency is clearer in RPC than trying to fit it into a RESTful resource creation model.

• Complex Workflows: Suited for services offering diverse utilities, such as a document conversion service. Operations like convertPdfToWord, extractTextFromPdf, and mergePdfs are intuitive as function calls but cumbersome to map to RESTful endpoints.

• Internal and Batch Operations: RPC is the preferred choice for internal service-to-service communication and allows for efficient batch operations, such as deleting multiple users in a single request.

Recommendations

• Public APIs: Use REST when building public APIs or when there are clear resources to expose to external users.

• Internal Services: Use RPC (or modern alternatives like gRPC) for internal systems and workflows that are heavy on actions and processing.