HTTP method ánh xạ sang CRUD thế nào, và safe với idempotent nghĩa là gì?

Question

IT Interview Practice · Accepted Answer

REST dùng các **HTTP method** chuẩn làm động từ tác động lên tài nguyên. Cách ánh xạ thường gặp sang **CRUD** (Create, Read, Update, Delete):

| CRUD | Method | Dùng khi |
|------|--------|----------|
| Create | `POST` | Thêm tài nguyên mới vào một collection |
| Read | `GET` | Lấy một tài nguyên hoặc danh sách |
| Update (toàn bộ) | `PUT` | Thay thế toàn bộ tài nguyên |
| Update (một phần) | `PATCH` | Sửa một vài trường |
| Delete | `DELETE` | Xoá tài nguyên |

## Ví dụ

```http
POST /users HTTP/1.1
Content-Type: application/json

{ "name": "Ann", "email": "ann@example.com" }
```

```http
HTTP/1.1 201 Created
Location: /users/42

{ "id": 42, "name": "Ann", "email": "ann@example.com" }
```

`PUT /users/42` gửi **toàn bộ** representation và thay thế nó; `PATCH /users/42` chỉ gửi **những trường cần đổi** (vd. `{ "email": "new@example.com" }`).

## Safe và idempotent

Đây là hai thuộc tính khác nhau:

- **Safe** — method **không thay đổi** trạng thái server (chỉ đọc). `GET`, `HEAD`, `OPTIONS` là safe.
- **Idempotent** — gửi **cùng một request N lần** cho kết quả giống như gửi một lần. `GET`, `PUT`, `DELETE`, `HEAD` là idempotent.

```text
Method   Safe?   Idempotent?
GET      có      có
HEAD     có      có
PUT      không   có       (thay bằng cùng body hai lần = cùng kết quả)
DELETE   không   có       (xoá hai lần = vẫn đã xoá)
PATCH    không   không*   (tuỳ patch; không đảm bảo)
POST     không   không    (POST hai lần thường tạo ra hai tài nguyên)
```

## Tại sao điều này quan trọng

Người phỏng vấn hỏi câu này để xem bạn hiểu ngữ nghĩa HTTP đủ sâu để xây API đáng tin cậy hay không. Phân biệt safe/idempotent không phải lý thuyết suông: nó quy định trực tiếp những gì client, proxy và CDN được phép làm. Method **safe** có thể cache và prefetch thoải mái; method **idempotent** có thể được **tự động retry** sau khi network timeout mà không sợ nhân đôi side effect — đó là lý do client retry `PUT` hay `DELETE` an toàn nhưng phải cẩn thận khi retry `POST` (có thể tạo hai order). Lỗi kinh điển là dùng `GET` để gây side effect (vd. `GET /users/42/delete`), làm hỏng caching và khiến crawler vô tình sửa dữ liệu. Chọn đúng method — và tôn trọng hợp đồng safe/idempotent của nó — chính là điều làm API dễ đoán và an toàn để xây tooling xung quanh.

Create	`POST`	Thêm tài nguyên mới vào một collection
Read	`GET`	Lấy một tài nguyên hoặc danh sách
Update (toàn bộ)	`PUT`	Thay thế toàn bộ tài nguyên
Update (một phần)	`PATCH`	Sửa một vài trường
Delete	`DELETE`	Xoá tài nguyên

Ví dụ

Safe và idempotent

Tại sao điều này quan trọng

Câu hỏi liên quan