Application Programming Interfaces, or APIs, act as links that allow smooth communication and interaction between various software systems. APIs are the basis for modern software, enabling anything from data sharing to the integration of fully functional services in web apps and mobile platforms. From the very beginnings of Remote Procedure Calls (RPC) to the creation of REST and beyond, this blog delves deeply into the history of APIs. Let’s explore how these technologies have influenced modern system communication.
The Early Days: Remote Procedure Calls (RPC)
- Introduce RPC as one of the earliest forms of APIs, enabling systems to communicate via procedure calls over networks.
- Highlight early use cases in distributed systems.
- Discuss the strengths of RPC: simplicity and direct communication across systems.
- Note its limitations, including tight coupling and protocol complexity.
The Shift Towards REST: A Game-Changer for Web Services
The architecture of APIs was completely transformed by REST (Representational State Transfer), especially when it came to the web. REST made use of HTTP, the same protocol that web browsers utilize, in contrast to RPC, which needed special protocols. REST was very flexible and scalable because of its tenets, which include statelessness, client-server isolation, and treating resources as identifiable entities (nouns). Its simplicity and alignment with web technologies enabled REST to rise to prominence, especially as web services and cloud computing became more widespread. REST’s flexibility to handle diverse use cases led to its widespread adoption in modern API design.
The four basic features of RESTful APIs are converted to HTTP methods and conform to the CRUD (Create, Read, Update, Delete) model:
- Create – POST: Used to create a new resource.
- Read – GET: Retrieves information about a resource.
- Update – PUT or PATCH: Modifies an existing resource.
- Delete – DELETE: Removes a resource
PostMan used for Rest api’s
https://www.postman.com/product/rest-client/
gRPC (Google Remote Procedure Call)
gRPC is a distributed system pixel streaming open-source framework which connects pixel-based systems together over HTTP/2 through data transfer, header compression, and multiplexing. Components such as Protobuf which is composed of smaller serialized and high-speed data enable faster commutation as compared to JSON. gRPC is suitable for the majority of the applications requiring microservices or real-time applications that are low on latency and high on throughput. It also provides support for a large variety of languages. The other key feature is bi-directional streaming where the server and the client send information at the same time.
eRPC (Embedded Remote Procedure Call)
eRPC is a RPC framework that is designed for application in embedded systems and other low resource IoT devices. The focus is on reducing memory and CPU usage, which is suitable for use in performance sensitive applications. eRPC uses binary serialization and exchanges messages over the systems only over UDP or TCP. eRPC does not have these structures enabling it to be designed for use in specific low latency and low bandwidth scenarios while gRPC typically is not.
Comparing RPC and REST
| Aspect | RPC (Remote Procedure Call) | REST (Representational State Transfer) |
| Architecture | Procedural, based on invoking remote functions | Resource-based, focused on interacting with resources via HTTP |
| Communication Protocol | Often uses custom protocols | Relies on standard HTTP |
| Coupling | Tight coupling between systems | Loosely coupled systems |
| State Management | Can be stateful, maintaining session between calls | Stateless, each request contains all necessary information |
| Use Cases | Preferred in environments requiring tight control | Ideal for web services and distributed applications |
| Flexibility | Limited flexibility due to custom protocols | High flexibility, easy to integrate with web technologies |
| Scalability | Limited scalability | Highly scalable due to stateless nature |
| Adoption | Less commonly used in modern web applications | Dominant model for modern web APIs |
Conclusion
From the early days of RPC to the dominance of REST, the journey of APIs has been one of continuous evolution. Each phase in this evolution reflects the growing demands of the software world, from distributed computing to the modern web. To navigate the future of software creation as developers and architects, it is important that we know this past. We can keep innovating and creating the systems that drive the digital environment of the future by keeping up with the most recent trends and best practices in API design.
