API là gì? Tại sao mọi app, mọi web hiện đại đều cần
API là 'bồi bàn' của web — truyền yêu cầu giữa frontend và backend, giữa app của bạn và Stripe/Google/Zalo. Hiểu API giúp bạn ước lượng chi phí dev, chọn dịch vụ tích hợp và đọc được lỗi 401/500.
Mục lục bài viết(21)
Sơ đồ mô hình REST — các khái niệm chính (resource, representation, identifier, state) và mối quan hệ. REST là cách thiết kế API mà 90% web/app hiện nay dùng: client gửi HTTP request đến URL của resource, server trả về representation (thường là JSON). Nguồn: Wikimedia Commons (CC BY-SA 4.0).
Hiểu đơn giản nhất
API là bồi bàn trong nhà hàng. Quay lại analogy từ bài Frontend vs Backend:
- Khách (frontend) ngồi ở phòng khách, không vào bếp được.
- Bếp (backend) lo nấu món, không ra phòng khách giao tận tay.
- Bồi bàn (API) ở giữa — biết menu, nhận order từ khách, truyền vào bếp, mang món ra cho khách.
Mỗi tương tác có ý nghĩa trên web hay app — đăng nhập, xem giỏ hàng, đặt món, gửi tin nhắn — đều là một lần frontend gọi API tới backend. Mọi web/app hiện đại đều chạy trên hàng chục, hàng trăm API call mỗi phút.
API viết tắt từ Application Programming Interface — "giao diện để các phần mềm nói chuyện với nhau".
Tại sao bạn cần biết
- Hiểu chi phí phát triển. "Tích hợp thanh toán VNPay" = build API integration. "App có chat realtime" = thêm WebSocket API. Mỗi API integration thường là 3-10 ngày dev = 15-50 triệu.
- Chọn dịch vụ thay vì tự build. Cần gửi SMS? Dùng API Twilio hoặc eSMS — tiết kiệm 3 tháng tự build. Cần OCR ảnh? Dùng API Google Vision — tiết kiệm hàng triệu chi phí ML. Quy tắc: cái gì có sẵn API trưởng thành, đừng tự build.
- Đọc được lỗi dev báo cáo. "API trả 401" = lỗi xác thực, sai token. "API trả 500" = lỗi server. "API trả 429" = bạn gọi quá nhanh, bị rate-limit. Hiểu code = không bị "ru ngủ" bởi giải thích lòng vòng.
- Tránh hoá đơn cloud bất ngờ. OpenAI, Google Maps, AWS tính tiền theo lượt gọi API. Một bug làm app gọi API 1.000 lần/phút có thể tạo hoá đơn vài chục triệu trong 1 đêm.
API hoạt động thế nào — anatomy của 1 API call
Mỗi lần API "nói chuyện" gồm 2 phần: Request (order của khách) và Response (món bếp trả ra).
Request — gửi yêu cầu
Có 4 thành phần:
| Thành phần | Ví dụ | Vai trò |
|---|---|---|
| Method | GET, POST, PUT, DELETE | Loại hành động: đọc / tạo / sửa / xoá |
| URL endpoint (điểm cuối — URL của một API) | https://api.shopee.vn/products/123 | Địa chỉ tài nguyên cụ thể |
| Headers | Authorization: Bearer abc123 | Ai gọi, token (chuỗi xác thực) gì, ngôn ngữ |
| Body (chỉ POST/PUT) | { "name": "Áo thun", "price": 200000 } | Dữ liệu kèm theo |
4 method chính (gọi là HTTP verb) tương ứng 4 hành động CRUD (Create-Read-Update-Delete — 4 thao tác: tạo, đọc, sửa, xoá):
- GET — đọc dữ liệu (xem sản phẩm, xem giỏ hàng)
- POST — tạo mới (đặt đơn, đăng ký tài khoản)
- PUT / PATCH — sửa (update profile, đổi số lượng trong giỏ)
- DELETE — xoá (huỷ đơn, xoá comment)
Response — bếp trả món
Có 2 thành phần chính:
Status code (3 chữ số) cho biết kết quả:
| Code | Ý nghĩa | Khi gặp |
|---|---|---|
| 200 | OK — thành công | Request hợp lệ, có data trả về |
| 201 | Created — tạo thành công | Sau POST tạo mới |
| 400 | Bad Request | Frontend gửi data sai format |
| 401 | Unauthorized | Chưa đăng nhập hoặc token hết hạn |
| 403 | Forbidden | Đăng nhập rồi nhưng không có quyền |
| 404 | Not Found | Resource không tồn tại |
| 429 | Too Many Requests | Bị rate-limit, gọi quá nhanh |
| 500 | Internal Server Error | Backend bị lỗi |
| 503 | Service Unavailable | Server quá tải hoặc đang bảo trì |
Body thường là JSON (định dạng trao đổi data phổ biến):
{
"id": 123,
"name": "Áo thun nam",
"price": 200000,
"in_stock": true,
"reviews": {
"average": 4.5,
"count": 89
}
}JSON đọc dễ cho người (giống dictionary tiếng Việt) và máy tính.
REST — kiểu API phổ biến nhất
REST (REpresentational State Transfer) là kiểu thiết kế API mà 90% web/app dùng. Quy tắc REST:
- URL là danh từ chỉ tài nguyên —
/products/123(sản phẩm 123), không phải/getProduct?id=123 - HTTP method thể hiện hành động — GET để đọc, POST để tạo. Không nhồi
/deleteProductthành endpoint. - Stateless — mỗi request độc lập, không phụ thuộc request trước
- Trả về JSON (hoặc đôi khi XML cho hệ thống cũ)
Ví dụ REST API của một shop online:
| Endpoint | Mục đích |
|---|---|
GET /products | Danh sách sản phẩm |
GET /products/123 | Chi tiết sản phẩm 123 |
POST /products | Tạo sản phẩm mới (admin) |
PUT /products/123 | Sửa sản phẩm 123 |
DELETE /products/123 | Xoá sản phẩm 123 |
GET /orders/456/items | Items trong đơn hàng 456 |
POST /orders/456/cancel | Huỷ đơn hàng 456 |
Pattern này thống nhất khắp ngành — dev mới vào dự án REST có thể đoán được endpoint mà không cần đọc nhiều docs.
GraphQL — order theo combo
GraphQL (Facebook tạo 2012) là kiểu API khác — frontend tự chọn cần field nào, server trả đúng field đó.
REST: 3 endpoint khác nhau cho 3 trang:
GET /users/123 → name, email, avatar
GET /users/123/posts → bài đã đăng
GET /users/123/followers → người follow
GraphQL: 1 endpoint, frontend tự ghép:
{
user(id: 123) {
name
avatar
posts(limit: 5) { title }
followers(limit: 10) { name }
}
}Khi nào GraphQL thắng: mobile app cần ít data (tiết kiệm 4G), web phức tạp nhiều màn lấy data trùng nhau (Facebook, GitHub).
Khi nào REST thắng: dự án nhỏ, team mới, cần cache đơn giản, dev không có thời gian học GraphQL. 80% startup dùng REST là đúng.
API authentication — bồi bàn kiểm tra ai gọi
Bồi bàn không phục vụ vô điều kiện — cần biết khách là ai. Tương tự, API cần xác thực. 3 cách phổ biến:
1. API Key — chìa khoá đơn giản
Một chuỗi ký tự bí mật, gửi kèm mỗi request:
GET /weather?city=Hanoi&api_key=abc123xyz789
Dùng cho: public API như OpenWeatherMap, Google Maps. Dễ làm, dễ lộ.
2. Bearer Token (JWT — JSON Web Token — chuỗi xác thực có hạn) — vé vào cửa có hạn
Sau khi login thành công, server trả về token. Frontend gửi token trong header mỗi request tiếp theo:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6...
Token có hạn (thường 1-7 ngày). Hết hạn → phải login lại. Dùng cho: hầu hết web app, SaaS.
3. OAuth (đăng nhập qua bên thứ ba)
"Đăng nhập bằng Google", "Đăng nhập bằng Facebook" — bạn không trao password cho web bạn dùng, Google chỉ xác nhận và cấp token. Dùng cho: ứng dụng cần truy cập data của user ở dịch vụ khác (đọc lịch Google, gửi mail Gmail).
Trang tài liệu API của NASA — một public API miễn phí cung cấp ảnh thiên văn, dữ liệu sao Hoả và hàng chục dataset khác. Mọi public API trưởng thành đều có docs như thế này: list endpoint, mô tả input, ví dụ response. Đọc docs là bước đầu khi tích hợp bất cứ API nào. Nguồn: Wikimedia Commons (public domain).
Public API vs Private API
| Kiểu | Ai dùng được | Ví dụ |
|---|---|---|
| Public | Ai có API key | Stripe, Google Maps, OpenAI, VNPay, Zalo OA, Vietnam Weather |
| Internal/Private | Chỉ frontend của shop đó | API Shopee gọi từ app Shopee, API VietCodex gọi từ wiki.vietcodex.com |
| Partner | Đối tác đăng ký xét duyệt | API Facebook cho ad agency, API VietnamAirlines cho booking platform |
Khi build SaaS (Software as a Service — phần mềm dạng dịch vụ), bạn có thể vừa có internal API (frontend của bạn dùng) vừa expose public API (cho khách tích hợp tự động) — như Notion, Slack, Stripe đều làm.
Ví dụ thực tế: API call khi bạn login Shopee
Bạn mở app Shopee, gõ username + password, bấm "Đăng nhập". Đây là chuỗi API call thực sự xảy ra:
Bước 1: Frontend gửi POST /auth/login
POST https://api.shopee.vn/v4/auth/login
Content-Type: application/json
X-Device-Id: abc-123-xyz
{
"username": "nguyenvana",
"password": "***********",
"device_fingerprint": "..."
}
Bước 2: Backend xử lý (50-200ms)
- Tìm user trong database (SELECT FROM users WHERE username = ...)
- Hash password bạn vừa nhập, so với hash trong DB
- Match → tạo JWT token chứa user_id + role + expiry
- Log audit: ai login lúc nào, từ device nào
Bước 3: Backend trả về Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJhbGc...",
"refresh_token": "eyJhbGc...",
"expires_in": 3600,
"user": {
"id": 12345,
"name": "Nguyễn Văn A",
"avatar_url": "https://cf.shopee.vn/avatars/12345.jpg",
"loyalty_tier": "gold"
}
}
Bước 4: Frontend lưu token + gọi tiếp các API khác
App Shopee giờ có token, gọi 5-10 API tiếp theo song song để dựng màn home:
| API call | Trả về |
|---|---|
GET /home/banners | Banner ads trên trang chủ |
GET /home/categories | Danh mục đề xuất |
GET /home/flash-sale | Flash sale đang chạy |
GET /user/cart/count | Số item trong giỏ |
GET /user/notifications/unread | Số thông báo chưa đọc |
GET /home/recommendations | Sản phẩm gợi ý cá nhân hoá |
Tổng cộng: 1 login request + ~6 home API call trong khoảng 800ms. Mỗi API gọi đi gọi lại hàng tỷ lần/ngày — đó là lý do Shopee đầu tư hàng trăm triệu USD cho hạ tầng server.
Cái gì có thể sai
| Vấn đề | Code | Cách fix |
|---|---|---|
| Token hết hạn | 401 | Frontend tự refresh token hoặc bắt user login lại |
| Không có quyền | 403 | Nâng cấp tài khoản hoặc xin admin cấp role |
| Resource không tồn tại | 404 | Check URL endpoint có đúng không |
| Gọi quá nhanh | 429 | Implement exponential backoff, đợi rồi retry |
| Server lỗi | 500 | Báo backend dev, có khi do bug, có khi do DB sập |
| Quá tải | 503 | Đợi vài phút, server đang bảo trì hoặc auto-scale chưa kịp |
| Timeout (>30s) | — | API endpoint chậm, cần tối ưu DB query hoặc cache |
| CORS blocked | — | Backend chưa whitelist domain frontend, fix ở backend |
API như viên Lego — mỗi viên là một dịch vụ độc lập (thanh toán, gửi mail, lưu ảnh, AI), bạn ghép lại thành sản phẩm. Một SaaS điển hình ghép 8-15 API third-party + 1 API riêng. Càng dùng nhiều API sẵn, càng tiết kiệm thời gian build "phần đã giải xong" và dồn lực cho phần khác biệt riêng của business. Nguồn: Wikimedia Commons (CC BY-SA 3.0).
Khi nào dùng API có sẵn vs tự build
| Bạn cần | Có API sẵn? | Khuyến nghị |
|---|---|---|
| Thanh toán online | VNPay, Momo, Stripe, PayPal | Dùng sẵn, đừng tự build |
| Gửi SMS | Twilio, eSMS, ESMS Vietnam | Dùng sẵn |
| Gửi email transactional | SendGrid, Resend, Mailgun | Dùng sẵn |
| Bản đồ + geocoding | Google Maps, Mapbox | Dùng sẵn (Google Maps đắt — Mapbox rẻ hơn 5-10x) |
| Lưu ảnh + video | Cloudinary, AWS S3 + CloudFront | Dùng sẵn |
| Chat realtime | Pusher, Soketi, Sendbird, Pubnub | Dùng sẵn nếu < 100k user; tự build nếu cần custom |
| AI text generation | OpenAI, Anthropic, Gemini | Dùng sẵn |
| Search trong app | Algolia, Meilisearch, Typesense | Dùng sẵn |
| Auth + user management | Supabase Auth, Clerk, Auth0 | Dùng sẵn nếu chưa có hệ thống user phức tạp |
| Business logic riêng của bạn | — | Bắt buộc tự build (đây là phần "khác biệt" của sản phẩm) |
Quy tắc: đừng tự build cái đã commodity hoá (thanh toán, SMS, email). Dồn nguồn lực vào API nội bộ thể hiện giá trị riêng của business.
Tóm tắt 1 dòng
API = bồi bàn truyền lệnh giữa các phần mềm. Mỗi tương tác trên web/app là 1 API call. REST là kiểu phổ biến nhất, JSON là format chuẩn, status code 200/401/500 nói cho bạn biết kết quả. Đừng tự build cái đã có API sẵn — dùng Stripe/Twilio/OpenAI tiết kiệm hàng tháng dev.
Đọc tiếp
- Webhook là gì — cách Casso, Stripe, Zalo "gõ cửa" web của bạn — API "ngược chiều": server gọi bạn khi có sự kiện
- Cookies, Session, Token — 3 cách web "nhớ" bạn đã đăng nhập — JWT Token được API dùng để xác thực
- Frontend vs Backend khác nhau ở đâu — bồi bàn (API) ở giữa hai phía
- Database là gì? So sánh dễ hiểu với Excel — nơi bếp lấy nguyên liệu
- Web hoạt động thế nào — hành trình 200ms — API call là bước 4 trong 5 bước