API RESTful là gì?

API (Application Programming Interface) là cách hai phần mềm giao tiếp với nhau; còn REST (Representational State Transfer) là một phong cách kiến trúc để xây dựng web service. RESTful API là API được thiết kế tuân theo các nguyên tắc của REST — dùng URL để định danh tài nguyên, dùng các HTTP method chuẩn (GET, POST, PUT, DELETE) để thao tác, và thường trao đổi dữ liệu bằng JSON.

Hình dung đơn giản: nếu phần mềm là một nhà hàng, thì API là người phục vụ — bạn (client) gọi món qua người phục vụ, họ mang yêu cầu vào bếp (server) và bưng kết quả ra. RESTful chỉ là "bộ quy tắc" giúp việc gọi món đó diễn ra gọn gàng, thống nhất và dễ đoán.

REST vs RESTful vs API — phân biệt nhanh

Ba từ này hay bị dùng lẫn, nhưng phân biệt khá đơn giản:

  • API: khái niệm chung — bất kỳ giao diện nào cho phép hai phần mềm "nói chuyện" với nhau.
  • REST: một phong cách kiến trúc (architectural style) với những ràng buộc nhất định, do Roy Fielding đề xuất.
  • RESTful: tính từ mô tả một API tuân theo các nguyên tắc REST.

Còn "REST vs RESTful"? Trong thực tế, hai từ này thường được dùng thay cho nhau. Khác biệt nhỏ về mặt học thuật: REST là tập nguyên tắc, còn RESTful nhấn mạnh việc một API có tuân thủ các nguyên tắc đó hay không.

6 ràng buộc của REST

Một API được coi là "RESTful" khi tuân theo các ràng buộc (constraints) sau:

Ràng buộc Ý nghĩa (giải thích cho tester)
Client-Server Tách phần giao diện (client) khỏi phần lưu trữ/xử lý (server)
Stateless Mỗi request tự chứa đủ thông tin; server không nhớ trạng thái phiên trước
Cacheable Response có thể được đánh dấu để cache lại, giúp tăng hiệu năng
Uniform Interface Giao diện thống nhất: tài nguyên qua URI, thao tác qua HTTP method chuẩn
Layered System Hệ thống nhiều tầng (proxy, gateway…) mà client không cần biết
Code-on-Demand (tùy chọn) Server có thể gửi đoạn code để client thực thi — không bắt buộc

Với tester, ràng buộc đáng chú ý nhất là Stateless: vì server không nhớ phiên, nên mỗi request bạn test phải tự mang đủ thông tin (ví dụ token xác thực). Đây là điểm hay sinh lỗi nếu client gửi thiếu.

Thành phần của RESTful API

Khi test một RESTful API, bạn sẽ làm việc với bốn thành phần chính: endpoint (URL định danh tài nguyên), HTTP method (hành động), status code (kết quả), và body (dữ liệu, thường là JSON).

Các HTTP method phổ biến:

Method Mục đích Ghi chú
GET Lấy/đọc dữ liệu Không làm thay đổi dữ liệu (an toàn)
POST Tạo mới tài nguyên Tạo bản ghi mới
PUT Cập nhật/thay thế Thay toàn bộ tài nguyên
PATCH Cập nhật một phần Chỉ sửa một phần tài nguyên
DELETE Xóa tài nguyên Xóa bản ghi

Các nhóm status code hay gặp:

Nhóm Mã thường gặp Ý nghĩa
2xx — Thành công 200 OK, 201 Created, 204 No Content Request được xử lý thành công
3xx — Chuyển hướng 301 Moved, 304 Not Modified Điều hướng hoặc dùng bản cache
4xx — Lỗi phía client 400, 401, 403, 404, 422 Request sai, không có quyền, không tìm thấy
5xx — Lỗi phía server 500, 502, 503 Server gặp lỗi khi xử lý

Nhớ nhanh: 4xx là "lỗi do bạn gửi sai", 5xx là "lỗi do server" — phân biệt được hai nhóm này giúp bạn báo bug đúng địa chỉ.

Tester cần kiểm thử gì ở RESTful API

Test API không chỉ là "gọi thử xem có chạy không". Một bộ test API tốt nên phủ:

  • Status code: đúng mã cho từng tình huống (200 khi lấy thành công, 201 khi tạo mới, 404 khi không tìm thấy, 401 khi thiếu token…).
  • Response body: dữ liệu trả về đúng giá trị, đúng cấu trúc (schema) — không thừa, không thiếu field.
  • Header: đúng Content-Type, có header xác thực/bảo mật cần thiết.
  • Contract/schema: API trả về đúng "hợp đồng" đã thống nhất với frontend; sai schema là dễ vỡ tích hợp.
  • Ca lỗi (negative): gửi dữ liệu sai định dạng, thiếu trường bắt buộc, sai quyền — xem API có trả lỗi đúng và rõ ràng không.
  • Tính toàn vẹn dữ liệu: sau khi POST/PUT, gọi GET lại để chắc dữ liệu đã được lưu đúng.
  • Bảo mật & hiệu năng: kiểm tra phân quyền, và thời gian phản hồi ở mức chấp nhận được.

Tư duy thiết kế ca kiểm thử ở đây giống hệt khi viết test case cho giao diện — xem lại cách viết test case để áp dụng phủ case hợp lệ/không hợp lệ/biên cho API.

Ví dụ request/response thực tế

Lấy ví dụ đặt phòng trong "Hệ thống đặt phòng họp nội bộ". Client gửi request tạo một lượt đặt phòng:

POST /api/rooms/12/bookings Headers: Authorization: Bearer <token> Content-Type: application/json Body: { "userId": 101, "title": "Họp team QA", "start": "2026-06-25T09:00:00", "end": "2026-06-25T10:00:00" }

Trường hợp thành công, server trả về 201 Created:

HTTP/1.1 201 Created { "bookingId": 5567, "roomId": 12, "status": "CONFIRMED", "start": "2026-06-25T09:00:00", "end": "2026-06-25T10:00:00" }

Còn nếu phòng đã có người đặt trùng giờ, một API tốt nên trả về lỗi rõ ràng, ví dụ 409 Conflict:

HTTP/1.1 409 Conflict { "error": "ROOM_ALREADY_BOOKED", "message": "Phòng đã được đặt trong khung giờ này." }

Việc của tester là kiểm tra cả hai nhánh: lượt đặt hợp lệ trả 201 và lưu đúng dữ liệu, còn lượt đặt trùng trả 409 với thông báo dễ hiểu — chứ không phải lỗi 500 chung chung.