API – Application Programming Interface – is a set of definitions and protocols that allow software applications to communicate and interact with each other. Just as users interact with applications through a User Interface (UI), applications also need a specialized interface to interact with one another, and that interface is called an API.
1. What Is an API?
Application Programming Interface (API) is a collection of definitions and communication protocols that enable software applications to interact and exchange data with each other. Through APIs, applications communicate using the Request–Response model, following predefined rules and protocols.
Example: Suppose your company is building a store management system composed of multiple services such as User Management, Order Management, and Payment Processing. When a customer makes a payment, the Payment Service must communicate with the Order Service to update the order status (success or failure). In other words, the Payment Service calls the API of the Order Service to update the order status.
2. How Does an API Work?
API architecture is commonly described using the client–server model. The application that sends a request is called the client, while the application that sends the response is the server.
For example, in a weather application, the meteorological agency’s database acts as the server, while the mobile app functions as the client. APIs operate in different ways depending on when and why they are created, but all are based on structured communication between client and server.
3. Popular API Protocols
API technologies continuously evolve. It is normal for some protocols to become trends for a period of time and later fade away. Below are some of the most popular API protocols used today.
3.1 REST – Representational State Transfer
REST (Representational State Transfer) is an architectural style that defines standards for communication between web-based systems. Systems that follow REST principles are often referred to as RESTful APIs.
REST is built on six core principles:
Client–Server: REST separates the client and server responsibilities. The client sends requests, while the server processes them and returns responses. This separation allows independent development of each component.
Stateless: Each request from the client must contain all necessary information for processing. The server does not store client state between requests, improving scalability and maintainability.
Cacheable: Server responses can be marked as cacheable, allowing clients or intermediaries to cache responses, reducing server load and improving performance.
Uniform Interface: REST uses a standardized interface to interact with resources, typically using HTTP methods such as GET, POST, PUT, DELETE, and URIs to identify resources.
Layered System: REST allows system architecture to be composed of layers, where each layer performs a specific function without knowledge of other layers, enhancing scalability and flexibility.
Code on Demand: REST optionally allows servers to send executable code (such as JavaScript) to clients, enabling functionality to be loaded on demand.
Common RESTful API examples:
- GET /customers – Retrieve a list of customers
- GET /customers/{id} – Retrieve details of a specific customer
- POST /customers – Create a new customer
- PUT /customers/{id} – Update an existing customer
- DELETE /customers/{id} – Delete a customer by ID
3.2 Webhook
A Webhook is a mechanism that allows an application to send real-time data to another application when a specific event occurs. Instead of the client repeatedly polling the server to check for updates, the server automatically sends data to a predefined callback URL when the event happens.
3.3 GraphQL
GraphQL is not a programming language but a query language for APIs. It defines how clients can request data through queries, modify data using mutations, and receive real-time updates via subscriptions.
Key principles of GraphQL include:
Hierarchical: Queries reflect hierarchical relationships, such as users having posts and posts having comments.
View-centric: The client specifies exactly what data it needs, rather than the server deciding what to return.
Strongly Typed: Every field and object has a clearly defined data type, helping catch errors early.
Client-driven: Clients fully control which fields they request, unlike REST where the server determines response structure.
Introspective: GraphQL supports schema introspection, allowing clients to explore available types, fields, and relationships automatically.
Version-free: GraphQL eliminates the need for multiple API versions, as clients can request only the data they need without breaking backward compatibility.
3.4 gRPC
Like other RPC protocols, gRPC (gRPC Remote Procedure Calls) allows a client to invoke methods on a remote server as if they were local functions.
gRPC introduces client stubs and server implementations and is widely used in microservice architectures due to its performance and flexibility.
gRPC supports four communication patterns:
Unary: Traditional request–response model. The client sends one request and receives one response.
Server Streaming: The server sends a stream of responses to the client after receiving a single request, suitable for real-time or large data streams.
Client Streaming: The client sends a stream of requests to the server and receives a single response.
Bidirectional Streaming: Both client and server send streams of data asynchronously, allowing real-time, two-way communication.
Tiếng Việt