# API RESTful Là Gì? Giải Thích Dễ Hiểu Cho Tester

> Càng đi sâu vào nghề, bạn sẽ càng nghe nhiều về API — và câu hỏi api restful là gì gần như chắc chắn sẽ xuất hiện. 🙂 Bài này tôi giải thích REST và RESTful theo cách dễ hiểu nhất cho tester, không sa đà vào code, kèm bảng tra HTTP method/status code và một ví dụ request/response thực tế. Quan trọng nhất: bạn sẽ biết tester cần kiểm thử gì ở một RESTful API.

- **URL canonical**: https://itlearn.edu.vn/blog/api-restful-la-gi
- **Published**: 2026-06-23T15:12:00+07:00
- **Modified**: 2026-06-23T17:26:06+07:00
- **Author**: Anh Tuấn
- **Category**: API Testing (https://itlearn.edu.vn/blog/cat/api-testing)
- **Reading time**: 8 phút
- **Source site**: IT LEARN — Học viện Software Testing tiếng Việt

---

## 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](/blog/bug-life-cycle-bug-report) đú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](/blog/cach-viet-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.

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

### REST và RESTful khác nhau không?

Về mặt học thuật, REST là một phong cách kiến trúc gồm các ràng buộc, còn RESTful là tính từ mô tả API tuân theo các nguyên tắc REST đó. Trong thực tế, hai từ thường được dùng thay cho nhau khi nói về API thiết kế theo REST. Bạn không cần quá bận tâm sự khác biệt này khi mới bắt đầu.

### RESTful API dùng những HTTP method nào?

Phổ biến nhất là GET (đọc dữ liệu), POST (tạo mới), PUT (cập nhật/thay thế toàn bộ), PATCH (cập nhật một phần) và DELETE (xóa). Mỗi method ứng với một loại thao tác trên tài nguyên. Khi test, bạn cần kiểm tra API dùng đúng method cho đúng mục đích và trả về status code phù hợp.

### Status code nào hay gặp khi test API?

Hay gặp nhất là 200 (OK), 201 (Created), 204 (No Content) ở nhóm thành công; 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found) ở nhóm lỗi client; và 500 (Internal Server Error) ở nhóm lỗi server. Nhớ rằng 4xx là lỗi do request, còn 5xx là lỗi do server.

### Tester có cần hiểu RESTful API không?

Rất nên. Ngày càng nhiều ứng dụng giao tiếp qua API, nên hiểu và test được API là một kỹ năng giá trị, giúp bạn phát hiện lỗi sớm ở tầng dữ liệu trước khi nó lộ ra trên giao diện. Đây cũng là kỹ năng được trả lương tốt và mở đường sang automation.

### JSON và XML trong REST API khác gì?

Cả hai đều là định dạng trao đổi dữ liệu. JSON gọn nhẹ, dễ đọc và phổ biến hơn nhiều trong REST API hiện đại; XML dài dòng hơn nhưng vẫn dùng ở một số hệ thống cũ. REST không bắt buộc định dạng cụ thể, nhưng JSON gần như là chuẩn mặc định ngày nay. Muốn học test API bài bản với Postman và thực hành trên dự án thật, bạn có thể tham khảo [khóa API Testing](/api.html) của IT LEARN. Nếu bạn mới hoàn toàn, hãy bắt đầu từ [lộ trình học tester](/blog/lo-trinh-hoc-tester-cho-nguoi-moi-bat-dau-2026), và tra cứu khái niệm lạ ở [thuật ngữ kiểm thử](/blog/thuat-ngu-kiem-thu/).