API là gì? REST API, các loại API và cách bảo mật

Mục lục

1. API là gì?
2. API dùng để làm gì?
3. API hoạt động như thế nào?
4. Thành phần của một lời gọi API gồm những gì?
5. REST API là gì?
6. Có những loại API nào?
7. Doanh nghiệp dùng API vào những việc gì?
8. Làm sao bảo mật API?
9. Quản lý API: gateway, tài liệu và phiên bản
10. Kinh tế API (API economy) và chi phí dùng API
11. Doanh nghiệp nên bắt đầu với API như thế nào?
12. Câu hỏi thường gặp

API là gì?

API là viết tắt của Application Programming Interface, dịch là giao diện lập trình ứng dụng. Đó là một “bản hợp đồng” quy định phần mềm A được hỏi phần mềm B những gì, hỏi theo cách nào và sẽ nhận lại câu trả lời ra sao.

Hãy hình dung quầy giao dịch ở ngân hàng. Bạn không được vào kho tiền hay mở máy chủ của ngân hàng. Bạn điền phiếu theo mẫu, đưa qua quầy, nhân viên xử lý rồi trả kết quả. Quầy giao dịch chính là API: nó che phần bên trong, chỉ mở ra những việc được phép, theo một mẫu cố định.

Chữ “giao diện” ở đây không phải màn hình bạn nhìn thấy. Giao diện người dùng (UI) dành cho con người bấm và đọc. API là giao diện dành cho phần mềm “nói chuyện” với phần mềm.

Ba ví dụ đời thường bạn đang dùng API mỗi ngày

• Tra cứu thời tiết: ứng dụng thời tiết trên điện thoại không tự đo nhiệt độ. Nó gửi yêu cầu tới API của một nhà cung cấp dữ liệu khí tượng, nhận về nhiệt độ, độ ẩm, khả năng mưa rồi vẽ lên màn hình.
• Đăng nhập bằng Google: khi bạn bấm nút này trên một trang web, trang đó không hề thấy mật khẩu Google của bạn. Nó chuyển bạn sang Google, bạn đồng ý chia sẻ tên và email, rồi trang web dùng API của Google để lấy đúng những thông tin đã được cho phép. Cơ chế phía sau là OAuth 2.0, giải thích ở phần bảo mật.
• Thanh toán bằng mã QR (ví dụ minh hoạ): bạn quét mã ở quầy thu ngân, ứng dụng ngân hàng gọi API để tạo lệnh chuyển tiền. Khi tiền về, hệ thống ngân hàng hoặc trung gian thanh toán gọi ngược API của cửa hàng để báo “đã thanh toán”, máy bán hàng tự in hoá đơn. Không ai phải nhìn sao kê để đối chiếu thủ công.

API dùng để làm gì?

Nói gọn, API giúp phần mềm dùng lại năng lực của nhau thay vì tự làm lại từ đầu. Với doanh nghiệp, điều đó mang lại 5 lợi ích cụ thể:

1. Không phải “phát minh lại bánh xe”. Cần bản đồ, gửi tin nhắn OTP, xác thực danh tính hay nhận thanh toán, bạn gọi API của đơn vị chuyên làm việc đó.
2. Kết nối các hệ thống rời rạc. Đơn hàng từ website tự chảy vào phần mềm kho, kế toán, chăm sóc khách hàng. Không còn cảnh xuất Excel rồi nhập lại.
3. Dữ liệu cập nhật gần như tức thời. Tồn kho, giá, trạng thái giao hàng được đồng bộ ngay khi có thay đổi.
4. Tự động hoá quy trình. Một sự kiện ở hệ thống này kích hoạt hành động ở hệ thống khác, không cần người làm trung gian.
5. Mở kênh kinh doanh mới. Doanh nghiệp có thể mở API cho đối tác dùng sản phẩm của mình, thậm chí bán chính API như một dịch vụ.

API cũng là nền móng của điện toán đám mây: mọi thao tác tạo máy chủ, lưu trữ, cấu hình mạng trên nền tảng cloud thực chất đều là lời gọi API, kể cả khi bạn bấm trên giao diện web.

API hoạt động như thế nào?

Hầu hết API trên web hiện nay chạy theo mô hình máy khách – máy chủ (client – server) và dùng giao thức HTTP, giống cách trình duyệt tải một trang web. Một lượt trao đổi gồm hai chiều: yêu cầu (request) đi và phản hồi (response) về.

Trình tự cụ thể của một lời gọi:

1. Client tạo yêu cầu: chọn địa chỉ, phương thức, gắn khoá truy cập và dữ liệu cần gửi.
2. Yêu cầu đi qua Internet, thường được mã hoá bằng HTTPS (TLS).
3. Máy chủ (hoặc cổng API đứng trước nó) xác thực: bạn là ai, có quyền làm việc này không, có vượt hạn mức không.
4. Máy chủ xử lý: đọc cơ sở dữ liệu, tính toán, có khi gọi tiếp API của hệ thống khác.
5. Máy chủ trả phản hồi: mã trạng thái cho biết thành công hay lỗi, kèm dữ liệu, phổ biến nhất ở định dạng JSON.

Thành phần của một lời gọi API gồm những gì?

Đây là phần nhiều bài viết bỏ qua, nhưng lại giúp người không chuyên đọc hiểu tài liệu API và trao đổi với đội kỹ thuật. Cùng “mổ xẻ” từng phần.

Endpoint: địa chỉ của tài nguyên

Endpoint là đường dẫn cụ thể mà client gửi yêu cầu tới, ví dụ https://api.example.com/v1/orders/1024. Trong đó:

• api.example.com là máy chủ cung cấp API (tên miền minh hoạ).
• /v1 là phiên bản API.
• /orders/1024 là tài nguyên (resource): đơn hàng số 1024.
• Phần sau dấu “?” nếu có, như ?status=paid, là tham số truy vấn (query parameter) để lọc hoặc phân trang.

Phương thức: muốn làm gì với tài nguyên

Phương thức HTTP (HTTP method) cho máy chủ biết bạn muốn đọc, tạo, sửa hay xoá. Các khái niệm “an toàn” và “lặp lại không đổi kết quả” (idempotent) dưới đây theo đặc tả HTTP RFC 9110 do IETF công bố tháng 6/2022; riêng PATCH được định nghĩa trong RFC 5789 (tháng 3/2010).

Phương thức	Dùng để	Ví dụ	Gọi lại nhiều lần có an toàn?
GET	Đọc dữ liệu, không thay đổi gì trên máy chủ	Xem chi tiết đơn hàng 1024	An toàn và idempotent
POST	Tạo mới hoặc gửi một yêu cầu xử lý	Tạo đơn hàng mới	Không: gọi hai lần có thể tạo hai đơn
PUT	Thay thế toàn bộ một tài nguyên	Ghi đè toàn bộ địa chỉ giao hàng	Idempotent: gọi lại cho cùng kết quả
PATCH	Sửa một phần tài nguyên	Chỉ đổi số điện thoại người nhận	Không bảo đảm idempotent
DELETE	Xoá tài nguyên	Huỷ một mã giảm giá	Idempotent

Vì sao điều này quan trọng với doanh nghiệp? Khi mạng chập chờn, phần mềm thường tự gửi lại yêu cầu. Với POST tạo đơn hay tạo lệnh thanh toán, gửi lại có thể sinh giao dịch trùng. Các API thanh toán vì vậy thường yêu cầu thêm một “khoá chống trùng” (idempotency key) để máy chủ nhận ra đây là cùng một yêu cầu.

Header: thông tin đi kèm

Header là các dòng “phong bì” đi kèm yêu cầu và phản hồi. Ba header bạn sẽ gặp nhiều nhất:

• Authorization: chứa khoá API hoặc mã truy cập (access token) để chứng minh bạn có quyền gọi.
• Content-Type: cho biết dữ liệu gửi đi là loại gì, thường là application/json.
• Accept: cho biết client muốn nhận dữ liệu loại gì.

Body: dữ liệu gửi đi hoặc nhận về

Body là phần “ruột” của thông điệp. Yêu cầu GET thường không có body. Yêu cầu POST, PUT, PATCH mang dữ liệu cần tạo hoặc sửa. Định dạng phổ biến nhất hiện nay là JSON (JavaScript Object Notation): dễ đọc với người, dễ xử lý với máy. Các hệ thống cũ, đặc biệt dùng SOAP, dùng XML.

Mã trạng thái: kết quả ra sao

Mỗi phản hồi có một mã trạng thái (status code) ba chữ số. Chữ số đầu cho biết nhóm kết quả.

Mã	Ý nghĩa	Khi nào gặp
200 OK	Thành công	Lấy dữ liệu hoặc cập nhật thành công
201 Created	Đã tạo mới tài nguyên	Tạo đơn hàng, tạo khách hàng thành công
204 No Content	Thành công, không có dữ liệu trả về	Xoá thành công
400 Bad Request	Yêu cầu sai từ phía client	Thiếu trường bắt buộc, sai định dạng ngày
401 Unauthorized	Chưa xác thực hoặc thông tin xác thực không hợp lệ	Thiếu khoá API, token hết hạn
403 Forbidden	Đã biết bạn là ai nhưng không cho phép	Tài khoản không có quyền xem dữ liệu này
404 Not Found	Không tìm thấy tài nguyên	Sai mã đơn hàng, sai đường dẫn
429 Too Many Requests	Gửi quá nhiều yêu cầu trong một khoảng thời gian	Vượt giới hạn tốc độ (rate limit), theo RFC 6585
500 Internal Server Error	Lỗi bất ngờ ở máy chủ	Lỗi phần mềm phía nhà cung cấp
503 Service Unavailable	Máy chủ tạm thời không phục vụ được	Bảo trì, quá tải

Mẹo nhớ nhanh: 2xx là ổn, 4xx là lỗi do bên gọi, 5xx là lỗi do bên cung cấp. Khi báo lỗi cho đối tác, chỉ cần gửi mã trạng thái, thời điểm và mã yêu cầu (request ID) là đội kỹ thuật đã tra được rất nhanh.

Ví dụ trọn vẹn: tra cứu thời tiết qua API

Ví dụ minh hoạ, tên miền và dữ liệu là giả định. Yêu cầu gửi đi:

Thành phần	Giá trị	Ý nghĩa
Phương thức	GET	Chỉ đọc dữ liệu
Endpoint	https://api.example.com/v1/weather?city=hanoi	Thời tiết hiện tại của Hà Nội, API phiên bản 1
Header Authorization	Bearer eyJhbGci… (rút gọn)	Mã truy cập do nhà cung cấp cấp cho ứng dụng
Header Accept	application/json	Muốn nhận kết quả dạng JSON
Body	(không có)	Yêu cầu GET không cần gửi dữ liệu

Phản hồi nhận về:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "city": "Hà Nội",
  "temperature_c": 29,
  "humidity_percent": 78,
  "condition": "Nhiều mây",
  "updated_at": "2026-10-07T09:00:00+07:00"
}

Ứng dụng chỉ việc đọc các trường temperature_c, condition rồi hiển thị. Nếu khoá truy cập sai, cùng yêu cầu đó sẽ nhận 401 kèm thông báo lỗi thay vì dữ liệu thời tiết.

REST API là gì?

REST (Representational State Transfer) là một kiểu kiến trúc do Roy Fielding mô tả trong luận án tiến sĩ năm 2000 “Architectural Styles and the Design of Network-based Software Architectures”. REST API (hay RESTful API) là API được thiết kế theo các nguyên tắc đó. Đây là kiểu API phổ biến nhất cho web và ứng dụng di động hiện nay.

Các ràng buộc chính của REST, diễn giải dễ hiểu:

• Tách client và server: hai bên phát triển độc lập, chỉ cần giữ đúng “hợp đồng”.
• Không lưu trạng thái (stateless): mỗi yêu cầu tự mang đủ thông tin, máy chủ không cần nhớ yêu cầu trước. Nhờ vậy dễ mở rộng thêm máy chủ.
• Cho phép lưu đệm (cache): phản hồi cho biết có được lưu tạm hay không, giảm tải cho máy chủ.
• Giao diện thống nhất: mọi thứ là tài nguyên có địa chỉ riêng, thao tác bằng các phương thức HTTP chuẩn.
• Hệ thống phân lớp: giữa client và server có thể có cổng API, bộ cân bằng tải, CDN mà client không cần biết.
• Mã theo yêu cầu (code on demand): tuỳ chọn, máy chủ có thể gửi mã cho client chạy.

Trên thực tế, nhiều API tự gọi là “REST” nhưng chỉ dùng HTTP và JSON, không theo đủ các ràng buộc trên. Với người dùng doanh nghiệp, điều quan trọng hơn là API có tài liệu rõ, đặt tên nhất quán và xử lý lỗi minh bạch.

Có những loại API nào?

Có hai cách phân loại hay bị trộn lẫn: theo ai được dùng và theo cách giao tiếp. Hãy tách riêng để khỏi nhầm.

Phân loại theo phạm vi sử dụng

Loại	Ai được dùng	Ví dụ	Điểm cần lưu ý
API nội bộ (private API)	Chỉ các hệ thống, đội ngũ trong doanh nghiệp	App bán hàng gọi API kho nội bộ	Dễ bị coi nhẹ về bảo mật vì “chỉ dùng trong nhà”
API đối tác (partner API)	Đối tác đã ký hợp đồng, được cấp quyền riêng	Hãng vận chuyển nhận đơn từ sàn thương mại điện tử; Open API ngân hàng cho bên thứ ba	Cần hợp đồng, phân quyền, nhật ký truy cập rõ ràng
API công khai (public API)	Bất kỳ nhà phát triển nào đăng ký	API bản đồ, API dữ liệu thời tiết, API mô hình AI	Phải có hạn mức, tính phí, chống lạm dụng
API tổng hợp (composite API)	Thường dùng nội bộ hoặc cho ứng dụng di động	Một lời gọi trả về cả thông tin khách, đơn hàng, điểm thưởng	Giảm số lượt gọi, nhưng một lỗi có thể kéo theo cả chuỗi

REST, SOAP, GraphQL, gRPC và webhook khác nhau thế nào?

Kiểu	Cách hoạt động	Định dạng dữ liệu	Điểm mạnh	Hạn chế	Phù hợp khi
REST	Mỗi tài nguyên một địa chỉ, thao tác bằng GET, POST, PUT, PATCH, DELETE	Phổ biến là JSON	Đơn giản, dễ học, tận dụng cache của web, hệ sinh thái công cụ lớn	Có thể lấy thừa hoặc thiếu dữ liệu, phải gọi nhiều lần	Đa số API web, di động, tích hợp SaaS
SOAP	Thông điệp theo chuẩn của W3C, mô tả dịch vụ bằng WSDL	XML	Chặt chẽ, có chuẩn mở rộng về bảo mật và giao dịch	Nặng, phức tạp, khó dùng trên di động	Hệ thống cũ trong ngân hàng, bảo hiểm, cơ quan nhà nước
GraphQL	Một điểm truy cập; client viết truy vấn nêu đúng trường cần lấy	JSON	Lấy đúng dữ liệu cần, gộp nhiều nguồn trong một lần gọi	Khó cache, khó kiểm soát truy vấn quá nặng	Ứng dụng có giao diện phức tạp, nhiều loại thiết bị
gRPC	Gọi hàm từ xa, chạy trên HTTP/2	Mặc định Protocol Buffers (nhị phân)	Rất nhanh, gọn, hỗ trợ truyền luồng hai chiều	Trình duyệt khó gọi trực tiếp, khó đọc bằng mắt	Giao tiếp giữa các dịch vụ nội bộ (microservices)
Webhook	Ngược chiều: khi có sự kiện, hệ thống nguồn tự gọi tới địa chỉ bạn đăng ký	Thường là JSON	Nhận thông báo tức thời, không phải hỏi liên tục	Phải tự xác minh chữ ký, xử lý gửi trùng hoặc gửi lại	Báo thanh toán thành công, đơn hàng đổi trạng thái

Một vài ghi chú ngắn. GraphQL ra đời tại Facebook (nay là Meta), hiện do GraphQL Foundation thuộc Linux Foundation quản lý. gRPC do Google phát triển từ hệ thống nội bộ Stubby và công bố mã nguồn mở năm 2015. Webhook thực chất là “API gọi ngược”: thay vì bạn hỏi 5 phút một lần “khách trả tiền chưa?”, hệ thống thanh toán sẽ tự báo cho bạn ngay khi có kết quả.

Ngoài ra còn có WebSocket cho kết nối hai chiều liên tục (chat, bảng giá trực tiếp) và API của hệ điều hành, thư viện phần mềm. Tuy nhiên khi doanh nghiệp nói “tích hợp qua API”, gần như luôn là web API kiểu REST hoặc webhook.

Doanh nghiệp dùng API vào những việc gì?

Kết nối ERP, CRM và các phần mềm SaaS

Một doanh nghiệp vừa và nhỏ hiện có thể dùng cùng lúc phần mềm kế toán, hệ thống quản trị nguồn lực ERP, phần mềm quản lý quan hệ khách hàng, sàn thương mại điện tử, phần mềm hoá đơn điện tử, công cụ email marketing. Nếu không có API, dữ liệu nằm rời ở từng nơi và nhân viên phải nhập đi nhập lại.

Ví dụ minh hoạ một luồng tích hợp:

1. Khách đặt hàng trên website. Website gọi API của CRM để tạo hoặc cập nhật hồ sơ khách.
2. Website gọi API của ERP để giữ hàng trong kho và tạo đơn bán.
3. ERP gọi API của đơn vị vận chuyển để tạo vận đơn, nhận lại mã vận đơn.
4. Đơn vị vận chuyển gửi webhook mỗi khi trạng thái giao hàng thay đổi.
5. Khi giao thành công, ERP gọi API phần mềm hoá đơn điện tử để phát hành hoá đơn.

Khi chọn phần mềm dạng SaaS, hãy đưa “có API mở, có tài liệu, có webhook” vào tiêu chí bắt buộc. Một phần mềm tốt nhưng “đóng” sẽ thành ốc đảo dữ liệu sau vài năm.

Có hai cách tổ chức tích hợp. Cách điểm–điểm (point-to-point) nối thẳng từng cặp hệ thống, nhanh lúc đầu nhưng rối khi số hệ thống tăng: 6 hệ thống nối đủ với nhau cần tới 15 kết nối. Cách thứ hai dùng một lớp tích hợp trung gian (nền tảng tích hợp, iPaaS hoặc ESB) để mọi hệ thống chỉ nối vào một chỗ, dễ giám sát và thay thế hơn.

Tự động hoá quy trình

API là “cần gạt” để tự động hoá. Một luồng công việc (workflow) như duyệt đề nghị thanh toán có thể tự lấy dữ liệu từ ERP, gửi yêu cầu duyệt, rồi ghi kết quả ngược lại, tất cả qua API. Khi hệ thống cũ không có API, doanh nghiệp mới phải dùng robot phần mềm (RPA) thao tác trên giao diện như người. Nguyên tắc chung: có API thì ưu tiên API vì ổn định hơn, RPA là phương án bù cho chỗ không có API.

Open API ngân hàng theo Thông tư 64/2024/TT-NHNN

Ngân hàng mở (open banking) là xu hướng ngân hàng cho phép bên thứ ba, với sự đồng ý của khách hàng, kết nối vào hệ thống để cung cấp dịch vụ. Tại Việt Nam, Ngân hàng Nhà nước ban hành Thông tư 64/2024/TT-NHNN ngày 31/12/2024 quy định về triển khai giao diện lập trình ứng dụng mở trong ngành Ngân hàng, có hiệu lực từ 01/03/2025. Những điểm chính:

• Định nghĩa: Open API là tập hợp các API được ngân hàng cung cấp cho bên thứ ba để kết nối trực tiếp, xử lý dữ liệu nhằm cung cấp dịch vụ cho khách hàng. Thông tư chia thành Open API cơ bản và Open API khác.
• Nhóm Open API cơ bản: truy vấn thông tin tỷ giá, lãi suất; thông tin khách hàng như tài khoản, lịch sử giao dịch; và nhóm khởi tạo thanh toán, nạp và rút ví điện tử.
• Sự đồng ý của khách hàng phải được thể hiện rõ ràng, tự nguyện trước khi dữ liệu cá nhân được xử lý.
• Chuẩn kỹ thuật: theo thông tin của Ngân hàng Nhà nước, khung tiêu chuẩn dựa trên kiến trúc REST, định dạng JSON, xác thực OAuth 2.0, mã hoá đường truyền TLS 1.2 trở lên; hệ thống triển khai Open API phải đạt cấp độ an toàn hệ thống thông tin tối thiểu cấp độ 3.
• Minh bạch: ngân hàng phải công khai danh mục Open API và thông tin môi trường thử nghiệm (sandbox) trên trang thông tin điện tử trước khi kết nối với bên thứ ba.
• Lộ trình: ngân hàng đã triển khai API cho bên thứ ba trước ngày Thông tư có hiệu lực phải hoàn thành việc đáp ứng quy định chậm nhất ngày 01/03/2027.

Với doanh nghiệp, điều này có nghĩa là việc kết nối phần mềm kế toán, ERP với ngân hàng để tự động đối soát, chi lương, thu tiền sẽ ngày càng chuẩn hoá hơn. Bối cảnh rộng hơn của ngành được phân tích trong bài chuyển đổi số trong ngân hàng.

API cho AI

Phần lớn doanh nghiệp không tự huấn luyện mô hình AI mà gọi mô hình qua API của nhà cung cấp. Chiều ngược lại cũng đang phổ biến: trợ lý AI được cấp quyền gọi API nội bộ (tra đơn hàng, tạo phiếu hỗ trợ). Khi đó, mọi nguyên tắc phân quyền và giới hạn ở phần bảo mật dưới đây càng quan trọng, vì “người gọi” là một phần mềm có thể hiểu sai yêu cầu.

Làm sao bảo mật API?

API mở ra cánh cửa vào dữ liệu, nên cũng là mục tiêu tấn công hấp dẫn. Phần này tập trung vào khái niệm và biện pháp phòng vệ; bức tranh tổng thể về phòng thủ có trong bài an ninh mạng là gì.

Xác thực và phân quyền: hai câu hỏi khác nhau

• Xác thực (authentication): bạn là ai? Trả lời bằng khoá API, mã truy cập, chứng thư số.
• Phân quyền (authorization): bạn được làm gì, với dữ liệu nào? Ví dụ khách A chỉ được xem đơn của chính A.

Các cách xác thực phổ biến:

Cách	Hoạt động	Phù hợp	Rủi ro chính
Khoá API (API key)	Một chuỗi bí mật gửi kèm mỗi yêu cầu	Máy chủ gọi máy chủ, dữ liệu ít nhạy cảm	Lộ khoá trong mã nguồn hoặc ứng dụng di động; khó gắn với từng người dùng
OAuth 2.0	Ứng dụng xin một mã truy cập có thời hạn và phạm vi giới hạn, thay vì cầm mật khẩu	Ứng dụng bên thứ ba truy cập dữ liệu thay mặt người dùng	Cấu hình sai địa chỉ chuyển hướng, phạm vi cấp quá rộng
OpenID Connect	Lớp định danh xây trên OAuth 2.0, cho biết người dùng là ai	Đăng nhập một lần, “Đăng nhập bằng Google”	Như OAuth 2.0, cộng với việc kiểm tra mã định danh không chặt
mTLS (TLS hai chiều)	Cả hai bên trình chứng thư số cho nhau	Kết nối đối tác, ngân hàng, dịch vụ nội bộ	Quản lý vòng đời chứng thư phức tạp

OAuth 2.0 hoạt động ra sao?

OAuth 2.0 được IETF công bố trong RFC 6749 tháng 10/2012. Nó cho phép một ứng dụng bên thứ ba có quyền truy cập giới hạn vào dịch vụ HTTP thay mặt người dùng, mà không cần biết mật khẩu. Đặc tả xác định bốn vai: chủ sở hữu tài nguyên (người dùng), client (ứng dụng), máy chủ cấp quyền và máy chủ tài nguyên.

OWASP API Security Top 10 2023: 10 rủi ro cần biết

OWASP (Open Worldwide Application Security Project) là tổ chức phi lợi nhuận về bảo mật ứng dụng. Danh sách 10 rủi ro bảo mật API phiên bản 2023 là bộ khung tham chiếu được dùng rộng rãi khi thiết kế và kiểm thử API.

Mã	Rủi ro	Hiểu đơn giản	Cách phòng
API1	Broken Object Level Authorization	Đổi mã đơn trong địa chỉ là xem được đơn của người khác	Kiểm tra quyền trên từng đối tượng ở mọi API có nhận mã định danh
API2	Broken Authentication	Cơ chế đăng nhập, token bị cài đặt sai	Dùng chuẩn có sẵn (OAuth 2.0, OpenID Connect), token có hạn, chống dò mật khẩu
API3	Broken Object Property Level Authorization	Trả về thừa trường nhạy cảm, hoặc cho sửa trường không được phép	Chỉ trả và chỉ nhận đúng các trường cần thiết
API4	Unrestricted Resource Consumption	Không giới hạn số lượt, kích thước, chi phí mỗi yêu cầu	Rate limit, giới hạn kích thước, phân trang, hạn mức chi phí
API5	Broken Function Level Authorization	Người dùng thường gọi được chức năng của quản trị	Phân quyền theo vai trò ở từng chức năng, mặc định từ chối
API6	Unrestricted Access to Sensitive Business Flows	Bot tự động gom hết hàng khuyến mãi, tạo tài khoản ảo hàng loạt	Nhận diện hành vi tự động, giới hạn theo nghiệp vụ
API7	Server Side Request Forgery (SSRF)	API tải tài nguyên từ đường dẫn người dùng cung cấp mà không kiểm tra	Danh sách địa chỉ được phép, chặn truy cập mạng nội bộ
API8	Security Misconfiguration	Cấu hình sai: bật chế độ gỡ lỗi, lộ thông báo lỗi chi tiết, thiếu TLS	Chuẩn hoá cấu hình, rà soát định kỳ
API9	Improper Inventory Management	Không biết mình có bao nhiêu API, phiên bản cũ vẫn chạy	Danh mục API đầy đủ, tắt phiên bản cũ đúng lịch
API10	Unsafe Consumption of APIs	Tin dữ liệu từ API bên thứ ba hơn dữ liệu người dùng nhập	Kiểm tra, lọc cả dữ liệu nhận từ đối tác

Giới hạn tốc độ (rate limit)

Rate limit là số yêu cầu tối đa một client được gửi trong một khoảng thời gian, ví dụ 100 yêu cầu mỗi phút. Khi vượt, máy chủ trả mã 429 Too Many Requests (RFC 6585, tháng 4/2012) và có thể kèm header Retry-After báo client chờ bao lâu. Rate limit bảo vệ hệ thống khỏi quá tải, chống dò mật khẩu và kiểm soát chi phí. Phía gọi API cũng nên thiết kế để chờ rồi thử lại với khoảng giãn tăng dần, thay vì dồn dập gửi lại.

Danh sách kiểm tra bảo mật API tối thiểu

• Chỉ dùng HTTPS; không bao giờ gửi khoá hay token qua đường dẫn công khai.
• Không ghi khoá API vào mã nguồn hay ứng dụng di động; lưu trong kho bí mật và xoay vòng định kỳ.
• Cấp quyền tối thiểu: mỗi khoá, mỗi token chỉ đủ cho việc cần làm.
• Kiểm tra phân quyền ở máy chủ cho từng đối tượng, không tin vào việc “giao diện đã ẩn nút”.
• Kiểm tra dữ liệu đầu vào và chỉ trả về trường cần thiết.
• Xác minh chữ ký của webhook nhận được, bỏ qua thông điệp quá cũ hoặc trùng lặp.
• Ghi nhật ký truy cập, cảnh báo khi lưu lượng bất thường.
• Duy trì danh mục API và tắt hẳn phiên bản không còn dùng.

Quản lý API: gateway, tài liệu và phiên bản

Khi doanh nghiệp có hàng chục API, câu hỏi chuyển từ “viết API thế nào” sang “quản lý chúng thế nào”. Ba công cụ cốt lõi:

API gateway: “cổng bảo vệ” đứng trước mọi API

API gateway là lớp đứng giữa client và các dịch vụ phía sau. Thay vì từng dịch vụ tự làm, gateway gánh các việc chung: xác thực, rate limit, ghi nhật ký, định tuyến, chuyển đổi định dạng, lưu đệm. Nó giúp áp chính sách thống nhất và có một chỗ duy nhất để quan sát toàn bộ lưu lượng. Đi kèm thường có cổng thông tin cho nhà phát triển (developer portal), nơi đối tác đăng ký, lấy khoá, đọc tài liệu và thử API.

Tài liệu theo chuẩn OpenAPI

OpenAPI Specification (OAS), trước đây gọi là Swagger Specification, là chuẩn mô tả API HTTP độc lập với ngôn ngữ lập trình. Theo chính đặc tả, nó cho phép cả người và máy hiểu được khả năng của một dịch vụ mà không cần đọc mã nguồn hay theo dõi lưu lượng mạng. Một tệp OpenAPI (YAML hoặc JSON) liệt kê mọi endpoint, tham số, cấu trúc dữ liệu và mã lỗi. Từ tệp đó có thể sinh tự động trang tài liệu, mã mẫu cho client và bộ kiểm thử.

Lưu ý tên gọi dễ nhầm: “OpenAPI” (chuẩn mô tả tài liệu) khác “Open API” theo nghĩa API mở cho bên ngoài, như Open API ngân hàng ở trên.

Quản lý phiên bản (versioning)

API thay đổi theo thời gian, nhưng client đang dùng không thể “vỡ” theo. Các nguyên tắc hay dùng:

• Đánh số phiên bản trong đường dẫn (/v1, /v2) hoặc trong header.
• Thay đổi tương thích (thêm trường mới, thêm endpoint) giữ nguyên phiên bản; thay đổi phá vỡ (đổi tên, xoá trường, đổi kiểu dữ liệu) phải ra phiên bản mới.
• Báo trước lịch ngừng hỗ trợ. Header Sunset (RFC 8594, tháng 5/2019) cho phép máy chủ báo thời điểm một tài nguyên dự kiến ngừng phục vụ.
• Chạy song song hai phiên bản trong thời gian chuyển đổi, theo dõi ai còn gọi bản cũ trước khi tắt hẳn.

Kinh tế API (API economy) và chi phí dùng API

Kinh tế API là cách gọi hiện tượng doanh nghiệp đóng gói năng lực của mình (thanh toán, bản đồ, định danh, gửi tin nhắn, mô hình AI, dữ liệu) thành API để đối tác dùng, từ đó tạo doanh thu hoặc mở rộng hệ sinh thái. Nhiều sản phẩm số ngày nay thực chất là “lắp ráp” từ API của nhiều bên.

Các mô hình tính phí API phổ biến

Mô hình	Cách tính	Cần chú ý
Miễn phí	Không thu phí, thường để mở rộng hệ sinh thái hoặc phục vụ sản phẩm chính	Hạn mức thấp, có thể thay đổi điều khoản bất cứ lúc nào
Freemium	Miễn phí đến một hạn mức, vượt thì trả tiền	Theo dõi sát lưu lượng để không “vỡ” ngân sách khi tăng trưởng
Trả theo lượt dùng	Tính theo số lượt gọi, số bản ghi, dung lượng hoặc số token (với API AI)	Chi phí biến động theo lưu lượng, cần cảnh báo ngân sách
Thuê bao theo gói	Phí cố định theo tháng hoặc năm, kèm hạn mức	Dễ dự toán, nhưng trả cả phần không dùng hết
Phí giao dịch, chia sẻ doanh thu	Thu theo phần trăm hoặc phí cố định mỗi giao dịch thành công	Phổ biến ở API thanh toán; tính kỹ phí trên biên lợi nhuận

Chi phí thật sự của một tích hợp API

Phí gọi API thường chỉ là phần nổi. Khi lập ngân sách, hãy tính đủ:

• Chi phí tích hợp ban đầu: phân tích, lập trình, kiểm thử, xử lý trường hợp lỗi.
• Chi phí bảo trì: mỗi lần nhà cung cấp ra phiên bản mới hoặc tắt phiên bản cũ, bạn phải sửa theo.
• Giám sát và vận hành: cảnh báo khi API đối tác chậm hoặc lỗi, người trực xử lý.
• Bảo mật và tuân thủ: quản lý khoá, đánh giá đối tác, thủ tục về dữ liệu cá nhân.
• Rủi ro phụ thuộc (vendor lock-in): nếu nhà cung cấp tăng giá hoặc ngừng dịch vụ, chi phí chuyển đổi có thể lớn.

Cách kiểm soát chi phí: lưu đệm kết quả ít thay đổi, gom nhiều yêu cầu thành một, dùng webhook thay cho hỏi liên tục (polling), đặt hạn mức và cảnh báo theo từng khoá, và luôn có phương án dự phòng cho API quan trọng.

Doanh nghiệp nên bắt đầu với API như thế nào?

1. Kiểm kê: liệt kê các phần mềm đang dùng, phần mềm nào có API, có webhook, có tài liệu.
2. Chọn một luồng đau nhất: nơi nhân viên đang nhập lại dữ liệu nhiều nhất, ví dụ đơn hàng từ sàn về kho và kế toán.
3. Xác định “nguồn sự thật”: mỗi loại dữ liệu (khách hàng, sản phẩm, tồn kho) do hệ thống nào làm chủ, để tránh ghi đè lẫn nhau.
4. Chọn cách tích hợp: kết nối có sẵn của nhà cung cấp, nền tảng tích hợp hoặc tự lập trình.
5. Thiết kế xử lý lỗi: khi API đối tác lỗi, dữ liệu được giữ lại và gửi lại thế nào, ai được báo.
6. Đo kết quả: số giờ nhập liệu tiết kiệm, tỷ lệ sai lệch dữ liệu trước và sau.

Câu hỏi thường gặp

API là viết tắt của từ gì?

API là viết tắt của Application Programming Interface, dịch là giao diện lập trình ứng dụng. Đó là tập quy tắc để các phần mềm giao tiếp và trao đổi dữ liệu với nhau.

REST API và RESTful API có khác nhau không?

Trong giao tiếp hằng ngày, hai cách gọi được dùng như nhau. Về lý thuyết, REST là kiểu kiến trúc, còn RESTful API là API tuân theo các nguyên tắc của kiến trúc đó.

API và Web API khác nhau thế nào?

API là khái niệm chung, bao gồm cả API của hệ điều hành, thư viện phần mềm. Web API là API được gọi qua mạng bằng giao thức HTTP. Khi doanh nghiệp nói “tích hợp qua API”, gần như luôn là Web API.

API khác SDK như thế nào?

API là bản “hợp đồng” quy định cách gọi. SDK (bộ công cụ phát triển phần mềm) là gói thư viện, mã mẫu do nhà cung cấp viết sẵn để lập trình viên gọi API đó dễ hơn bằng một ngôn ngữ cụ thể.

Dùng API có mất phí không?

Tuỳ nhà cung cấp. Có API miễn phí, có API miễn phí đến một hạn mức, có API tính theo lượt gọi, theo gói hoặc theo phí giao dịch. Hãy đọc kỹ bảng giá và điều khoản thay đổi giá trước khi tích hợp sâu.

Không biết lập trình có dùng được API không?

Có, ở mức nhất định. Nhiều công cụ tự động hoá và nền tảng tích hợp cho phép kéo thả để nối các phần mềm qua API có sẵn. Với luồng phức tạp, dữ liệu nhạy cảm hoặc khối lượng lớn, vẫn nên có người hiểu kỹ thuật thiết kế và giám sát.

Khoá API có giống mật khẩu không?

Gần giống: ai có khoá là gọi được API với quyền của khoá đó. Vì vậy cần giữ bí mật, cấp quyền tối thiểu, xoay vòng định kỳ và thu hồi ngay khi nghi bị lộ.

Open API ngân hàng là gì?

Theo Thông tư 64/2024/TT-NHNN, Open API là tập hợp các API ngân hàng cung cấp cho bên thứ ba để kết nối trực tiếp và xử lý dữ liệu nhằm cung cấp dịch vụ cho khách hàng, như truy vấn tỷ giá, lãi suất, thông tin tài khoản hoặc khởi tạo thanh toán, với sự đồng ý rõ ràng của khách hàng.