squirrelworks
The "Action" Focus: RPC is designed to execute a specific function on a remote server as if it were local. It focuses on actions (verbs) rather than resources (nouns).
In an RPC model, the client sends a request to a server to execute a procedure using specific parameters. The server processes the call and sends the result back. It is tightly coupled, meaning the client and server must share the same interface definition. This makes it incredibly fast and efficient for internal microservices, but often brittle for public-facing web APIs where the client might change independently of the server.
While early RPC used XML (XML-RPC), modern high-performance systems use gRPC. Developed by Google, gRPC uses Protocol Buffers (Protobuf) for serialization, making it significantly smaller and faster than JSON-based alternatives. This is why you see RPC used in low-latency environments like high-frequency trading or complex backend service meshes.
REST is not a protocol, but an architectural style. It treats everything as a unique resource identified by a URL. Instead of calling getUserData(), you perform a GET request on the /users/123 resource.
In REST, every request from a client must contain all the information necessary for the server to understand and process it. The server doesn't "remember" previous requests. This makes REST APIs incredibly easy to scale, as any server in a cluster can handle any incoming request.
REST relies on standard HTTP methods: GET (Read), POST (Create), PUT (Update), and DELETE. This standardization allows browsers, caches, and proxies to understand the intent of a request without knowing anything about the specific data being transferred.
The fundamental difference between these two styles lies in how "tightly" the client and server are bound together.
Choosing between REST and RPC depends entirely on the use case—external web consumption vs. internal high-speed communication.
| Feature / Aspect | REST | RPC (gRPC/JSON-RPC) |
|---|---|---|
| Primary Focus | Resources (Nouns/URI) | Actions (Verbs/Functions) |
| Coupling | Loose (Independent Evolution) | Tight (Shared Interface) |
| Data Format | JSON, XML, HTML, Plaintext | Protobuf, JSON, XML |
| HTTP Methods | Strict use of GET, POST, etc. | Usually just POST |
| Caching | Native Browser/Proxy Caching | Difficult / Implementation-heavy |
| Discoverability | Self-describing (Links) | Pre-defined (Contract-based) |
| Scalability | High (Stateless) | Variable (Connection-oriented) |
| Performance | Standard (Text-based overhead) | High (Binary/Compressed) |
| Error Handling | HTTP Status Codes (404, 500) | Custom Error Codes in Payload |
| Best Use Case | Public Web APIs / Mobile Apps | Internal Microservices / IoT |
In a robust Squirrelworks environment, these architectures often coexist. We might use a RESTful API to serve data to a Vue.js or jQuery frontend (as seen in the JS Course modules), while using an RPC-style mechanism for high-speed background tasks like database cleanup or log rotation.
Understanding the "Nouns vs. Verbs" distinction allows us to design more resilient systems. By choosing REST for public interfaces, we ensure that our web pages can scale and remain compatible across different browsers. Conversely, by understanding RPC, we gain insight into how legacy systems like MAPI functioned and how modern microservices communicate with maximum efficiency.