HTTP method แมปเข้ากับ CRUD อย่างไร และ safe กับ idempotent หมายความว่าอะไร?

Question

IT Interview Practice · Accepted Answer

REST ใช้ **HTTP method** มาตรฐานเป็นคำกริยาที่กระทำต่อทรัพยากร การแมปที่พบบ่อยเข้ากับ **CRUD** (Create, Read, Update, Delete) คือ:

| CRUD | Method | การใช้งานทั่วไป |
|------|--------|-------------|
| Create | `POST` | เพิ่มทรัพยากรใหม่เข้าใน collection |
| Read | `GET` | ดึงทรัพยากรหนึ่งชิ้นหรือรายการ |
| Update (เต็ม) | `PUT` | แทนที่ทรัพยากรทั้งหมด |
| Update (บางส่วน) | `PATCH` | แก้ไขบางฟิลด์ |
| Delete | `DELETE` | ลบทรัพยากร |

## ตัวอย่าง

```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` ส่ง representation **ทั้งหมด** ไปและแทนที่มัน ส่วน `PATCH /users/42` ส่ง **เฉพาะฟิลด์ที่จะเปลี่ยน** (เช่น `{ "email": "new@example.com" }`)

## safe กับ idempotent

นี่คือสองคุณสมบัติที่ต่างกัน:

- **Safe** — method **ไม่เปลี่ยน** สถานะของ server (อ่านอย่างเดียว) `GET`, `HEAD`, `OPTIONS` เป็น safe
- **Idempotent** — การส่ง **request เดิม N ครั้ง** ให้ผลเหมือนส่งครั้งเดียว `GET`, `PUT`, `DELETE`, `HEAD` เป็น idempotent

```text
Method   Safe?   Idempotent?
GET      yes     yes
HEAD     yes     yes
PUT      no      yes      (replacing with the same body twice = same result)
DELETE   no      yes      (deleting twice = still deleted)
PATCH    no      no*      (depends on the patch; not guaranteed)
POST     no      no       (posting twice usually creates two resources)
```

## ทำไมจึงสำคัญ

ผู้สัมภาษณ์ถามข้อนี้เพื่อดูว่าคุณเข้าใจความหมาย (semantics) ของ HTTP ลึกพอที่จะสร้าง API ที่เชื่อถือได้หรือไม่ การแยก safe/idempotent ไม่ใช่เรื่องวิชาการ: มันกำกับโดยตรงว่า client, proxy, และ CDN ได้รับอนุญาตให้ทำอะไร method **safe** สามารถ cache และ prefetch ได้อย่างอิสระ ส่วน method **idempotent** สามารถ **retry อัตโนมัติ** ได้หลัง network timeout โดยไม่เสี่ยงต่อการทำ side effect ซ้ำ — จึงเป็นเหตุว่าทำไม client จึง retry `PUT` หรือ `DELETE` ได้อย่างปลอดภัย แต่ต้องระวังเมื่อ retry `POST` (อาจสร้าง order สองรายการ) ความผิดพลาดคลาสสิกคือการใช้ `GET` เพื่อกระตุ้น side effect (เช่น `GET /users/42/delete`) ซึ่งทำลาย caching และทำให้ crawler แก้ไขข้อมูลโดยไม่ตั้งใจ การเลือก method ที่ถูกต้อง — และเคารพสัญญา safe/idempotent ของมัน — คือสิ่งที่ทำให้ API คาดเดาได้และปลอดภัยพอที่จะสร้างเครื่องมือรอบ ๆ มัน

Create	`POST`	เพิ่มทรัพยากรใหม่เข้าใน collection
Read	`GET`	ดึงทรัพยากรหนึ่งชิ้นหรือรายการ
Update (เต็ม)	`PUT`	แทนที่ทรัพยากรทั้งหมด
Update (บางส่วน)	`PATCH`	แก้ไขบางฟิลด์
Delete	`DELETE`	ลบทรัพยากร

ตัวอย่าง

safe กับ idempotent

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง