
Các Kiểu Kiến Trúc API Phổ Biến Nhất Hiện Nay

Tác giả: Phi Long
Cập nhật lần cuối: 06/03/2025
API là gì?
API (Application Programming Interface) là giao diện lập trình ứng dụng, cung cấp một tập hợp các quy tắc và phương thức giúp các phần mềm hoặc dịch vụ khác nhau có thể giao tiếp với nhau
API hoạt động như cầu nối giữa các hệ thống, cho phép chúng trao dổi dữ liệu và thực hiện các chức năng mà không cần hiểu rõ cách hệ thống nội bộ hoạt động

1️⃣ SOAP (Simple Object Access Protocol)
SOAP là một giao thức nhắn tin dựa trên XML để trao đổi dữ liệu giữa các hệ thống trong môi trường phân tán. SOAP hoạt động chủ yếu qua HTTP, nhưng cũng có thể sử dụng SMTP, TCP hoặc
2️⃣ RESTfull API (Representational State Transfer)
🔹Mô tả: Là một kiến trúc API phổ biến nhất, dựa trên giao thức HTTP và sử dụng các phương thức GET, POST, PUT, DELETE
🔹 Ưu điểm:
✔ Dễ hiểu, dễ sử dụng và phổ biến rộng
✔ Tương thích tốt với WEB, hoạt động dựa trên HTTP
✔ Có thể caching giúp giảm tải hệ thống
🔹 Nhược điểm:
❌ Không phù hợp với ứng dụng Real-time
❌ Gửi dữ liệu dư thừa (Over-fetching) hoặc thiếu dữ liệu cần thiết (Under-fetching)
Nhược điểm của REST nằm ở việc endpoint có cấu trúc cố định, không thể tùy chỉnh dữ liệu cần lấy, dẫn đến over-fetching (lấy dư dữ liệu) hoặc under-fetching (lấy thiếu dữ liệu).
Over-fetching (Lấy dư dữ liệu)
🛑 Vấn đề: API trả về nhiều dữ liệu hơn mức cần thiết, gây lãng phí băng thông và làm chậm ứng dụng.
📌 Ví dụ:
Bạn có một API lấy thông tin user:
GET /users/123
Trả về:
{
"id": 123,
"name": "Phi Long",
"email": "long@example.com",
"address": {
"street": "123 Lê Văn Sỹ",
"city": "HCM"
},
"created_at": "2024-02-19T10:00:00Z",
"updated_at": "2024-02-19T12:00:00Z"
}
🎯 Nhưng giả sử client chỉ cần name và email, thì dữ liệu address, created_at, updated_at là dư thừa → Over-fetching.
🔥 Hệ quả:
Under-fetching (Lấy thiếu dữ liệu)
🛑 Vấn đề: API không cung cấp đủ dữ liệu trong một lần gọi, buộc client phải gọi thêm nhiều request khác.
📌 Ví dụ:
Bạn có API lấy thông tin bài viết:
GET /posts/1
Trả về:
{
"id": 1,
"title": "REST API có nhược điểm gì?",
"author_id": 123
}
Nhưng client cũng cần thông tin author (tên, email). Do API /posts/1 chỉ trả về author_id, client phải gọi thêm:
GET /users/123
🔥 Hệ quả:
👉 Nếu REST API không được thiết kế tốt, nó có thể gây tốn tài nguyên và giảm hiệu suất, đặc biệt với mobile và frontend. 🚀
Giải pháp:
1️⃣ Dùng Query Parameters để Tối Ưu Over-fetching
Cho phép client yêu cầu chỉ những fields cần thiết bằng query params.
Ví dụ
Thay vì trả về tất cả thông tin user, API cho phép client chỉ lấy name và email:
GET /users/123?fields=name,email
📌 Response:
{
"name": "Phi Long",
"email": "long@example.com"
}
✅ Lợi ích:
📌 Triển khai:
Nếu dùng Node.js + Express, có thể xử lý như sau:
app.get('/users/:id', async (req, res) => {
const { id } = req.params;
const fields = req.query.fields ? req.query.fields.split(',') : ['*'];
const user = await db('users').select(fields).where({ id }).first();
res.json(user);
});
3️⃣ GraphQL
Mô tả: Cho phép client yêu cầu chính xác dữ liệu cần, thay vì nhận toàn bộ dữ liệu như REST.
🔹Ưu điểm:
✔ Giải quyết vấn đề Over-fetching & Under-fetching.
✔ Giao tiếp nhanh, giảm số lượng request.
✔ Hỗ trợ strongly-typed API, dễ dàng phát triển.
🔹 Nhược điểm:
❌ Phức tạp hơn REST.
❌ Cần server đặc thù để xử lý query.
🔹Ứng dụng: API cho web, mobile app, ứng dụng có dữ liệu phức tạp.
🔹Ví dụ: Facebook, GitHub GraphQL API.
4️⃣ gRPC (Google Remote Procedure Call)
🔹 Mô tả: Dựa trên giao thức HTTP/2, sử dụng Protocol Buffers (protobuf) thay vì JSON.
🔹 Ưu điểm:
✔ Tốc độ cao, hiệu suất tối ưu hơn REST và GraphQL.
✔ Hỗ trợ streaming, phù hợp với ứng dụng real-time.
✔ Tích hợp dễ dàng với nhiều ngôn ngữ lập trình.
🔹 Nhược điểm:
❌ Phức tạp hơn REST và GraphQL.
❌ Không dễ debug bằng trình duyệt (vì không sử dụng JSON).
🔹 Ứng dụng: Microservices, hệ thống real-time, IoT.
🔹 Ví dụ: Kubernetes, gRPC API của Google Cloud.
5️⃣ WebSockets API
🔹 Mô tả: Giao tiếp 2 chiều giữa Client và Server qua kết nối TCP, phù hợp với ứng dụng real-time
🔹 Ưu điểm:
✔ Kết nối lâu dài, giảm độ trễ
✔ Phù hợp với chat, game, streaming dữ liệu
🔹 Nhược điểm:
❌ Không phù hợp với ứng dụng CRUD thông thường
❌ Cần cơ chế quản lý kết nối phức tạp
6️⃣Server-Sent Events (SSE)
🔹 Mô tả: Cung cấp real-time một chiều từ server đến client, dựa trên HTTP
🔹 Ưu điểm:
✔ Nhẹ hơn Websocket
✔ Dễ triển khai với API REST
🔹 Nhược điểm:
❌ Chỉ hỗ trợ truyền dữ liệu từ server - client
❌ Không tối ưu với lượng dữ liệu lớn
Nên chọn kiến trúc nào?
API Type | Khi nào nên dùng? |
REST | Ứng dụng web thông thường, backend cho mobile. |
GraphQL | Khi cần linh hoạt dữ liệu, giảm số lượng request. |
gRPC | Khi hiệu suất là ưu tiên hàng đầu (microservices, hệ thống lớn). |
WebSockets | Khi cần real-time (chat, game, stock market). |
SSE | Khi cần cập nhật dữ liệu liên tục từ server mà không cần phản hồi từ client. |
Bình luận(0)
Hãy là người đầu tiên bình luận!