REST คืออะไร และมีข้อจำกัด (constraints) หลักอะไรบ้าง?

Question

IT Interview Practice · Accepted Answer

**REST** (Representational State Transfer) คือ **สไตล์เชิงสถาปัตยกรรม (architectural style)** สำหรับแอปพลิเคชันบนเครือข่าย นิยามโดย Roy Fielding มันไม่ใช่โปรโตคอลหรือมาตรฐาน — แต่เป็นชุด **ข้อจำกัด (constraints)** ที่เมื่อทำตามแล้ว จะทำให้ API ขยายตัวได้ (scalable), cache ได้, และวิวัฒน์ได้ง่าย API ที่ "RESTful" จะจำลองทุกอย่างเป็น **ทรัพยากร (resource)** (user, order, product) ที่ระบุด้วย URI และจัดการมันด้วย HTTP method มาตรฐาน

## ข้อจำกัดหลัก

- **Client–server** — แยก UI (client) ออกจากที่จัดเก็บข้อมูล (server) เพื่อให้แต่ละฝั่งวิวัฒน์อย่างอิสระ
- **Stateless** — ทุก request พก (carry) ข้อมูลทั้งหมดที่จำเป็นต่อการประมวลผลไปด้วย server **ไม่เก็บสถานะ session ของ client** ระหว่าง request server ตัวใดก็จัดการ request ใดก็ได้ ซึ่งทำให้การขยายแนวนอน (horizontal scaling) ง่าย
- **Cacheable** — response ประกาศว่าตัวมัน cache ได้หรือไม่ ให้ client และ proxy นำกลับมาใช้ซ้ำได้
- **Uniform interface** — ข้อจำกัดที่เป็นเอกลักษณ์ที่สุด: ทรัพยากรถูกระบุด้วย URI, จัดการผ่าน representation (มักเป็น JSON), ข้อความอธิบายตัวเองได้ (self-descriptive), และ hypermedia link นำทาง client
- **Layered system** — proxy, gateway, และ load balancer สามารถแทรกอยู่ระหว่าง client กับ server ได้อย่างโปร่งใส
- **Code-on-demand** (ตัวเลือกเสริม) — server อาจส่งโค้ดที่รันได้ (เช่น JavaScript)

## request แบบมุ่งทรัพยากร

```http
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
```

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

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

URI `/users/42` ตั้งชื่อให้ทรัพยากร; `GET` คือการกระทำ; JSON คือ representation การผสมผสานนั้น — คำนามในเส้นทาง (path), คำกริยาเป็น HTTP method — คือหัวใจของ REST

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

REST เป็นสไตล์ที่ครองตลาดสำหรับ web API ผู้สัมภาษณ์จึงใช้คำถามนี้ตรวจว่าคุณเข้าใจ *ว่าทำไม* มันได้ผล ไม่ใช่แค่สะกดชื่อได้ ข้อจำกัดสองข้อที่สำคัญที่สุดในทางปฏิบัติคือ **statelessness** (แต่ละ request มีข้อมูลครบในตัว คุณจึงวางเซิร์ฟเวอร์กี่ตัวก็ได้ไว้หลัง load balancer แล้วขยายแนวนอนโดยไม่ต้องใช้ sticky session) และ **uniform interface** (URL แบบมุ่งทรัพยากรที่คาดเดาได้ บวกกับ HTTP method และ status code มาตรฐาน ทำให้ client ไม่ต้องมีลอจิกเฉพาะสำหรับแต่ละ endpoint) คำตอบที่ดีจะเชื่อมข้อจำกัดเข้ากับประโยชน์ที่เป็นรูปธรรม — stateless เอื้อการขยาย, cacheable ลดโหลด, layered system ให้คุณแทรก CDN และ gateway — และตั้งข้อสังเกตว่า API ที่เรียกว่า "REST" ส่วนใหญ่เป็นแบบใช้งานได้จริงมากกว่าจะ RESTful อย่างสมบูรณ์ (น้อยรายที่ทำ HATEOAS) การเข้าใจข้อจำกัดเหล่านี้คือรากฐานของทุกการตัดสินใจออกแบบ REST อื่น ๆ ตั้งแต่การเลือก status code ไปจนถึง versioning

ข้อจำกัดหลัก

request แบบมุ่งทรัพยากร

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

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