ข้อจำกัดของ REST

REST ถูกนิยามด้วยชุดของ ข้อจำกัด เชิงสถาปัตยกรรม API ที่ทำตามข้อจำกัดเหล่านี้จะได้ scalability, evolvability และ cacheability มาแทบจะฟรี ๆ คุณไม่จำเป็นต้องทำตามทุกข้อจำกัดอย่างสมบูรณ์แบบ แต่การรู้จักข้อจำกัดเหล่านี้จะบอกได้ว่าคุณกำลังตัดมุมตรงไหนอยู่

หกข้อจำกัด

flowchart TD
  REST --> CS[Client–Server]
  REST --> ST[Stateless]
  REST --> CA[Cacheable]
  REST --> UI[Uniform Interface]
  REST --> LS[Layered System]
  REST --> COD[Code on Demand optional]

หกข้อจำกัด; code-on-demand เป็นข้อเดียวที่เป็นทางเลือก

Client–Server — แยก UI/ผู้ใช้บริการออกจากที่จัดเก็บข้อมูล ทั้งสองพัฒนาได้อย่างอิสระต่อกัน
Stateless — แต่ละ request พกพาทุกอย่างที่ server ต้องการไปด้วย ไม่มีการเก็บ session ต่อ client ไว้ระหว่างการเรียก นี่คือสิ่งที่ทำให้คุณเพิ่ม server เข้าหลัง load balancer ได้อย่างอิสระ
Cacheable — response ต้องบอกว่านำไป cache ได้หรือไม่ (และนานแค่ไหน) เพื่อให้ client และตัวกลางต่าง ๆ หยิบไปใช้ซ้ำได้
Uniform Interface — resource ถูกระบุด้วย URI และจัดการผ่านชุด method และ representation มาตรฐาน นี่คือข้อจำกัดที่ทำให้ API รู้สึก “RESTful”
Layered System — client แยกไม่ออกว่ากำลังคุยกับ origin server หรือกับตัวกลาง (proxy, gateway, cache)
Code on Demand (ทางเลือก) — server อาจส่ง code ที่รันได้ไปเพื่อขยายความสามารถของ client แต่แทบไม่ค่อยใช้กับ API

ทำไม statelessness ถึงคุ้มค่า

เพราะ server ไม่เก็บ session ใด ๆ server ตัวใดก็สามารถจัดการ request ใดก็ได้ นั่นทำให้การ scale แนวนอนและการ retry เป็นเรื่องง่าย — แต่ก็หมายความว่า client ต้องส่ง identity ของตัวเอง (token) และ context ที่จำเป็นไปกับ ทุก request

REST Constraint	Benefits	Cost
Stateless	scale ง่าย — ทุก server handle ได้	ต้องส่ง auth ทุก request
Cacheable	ลด latency, server load	cache invalidation ซับซ้อน
Uniform Interface	predictable — developer รู้วิธีใช้ทันที	less flexible สำหรับ operation พิเศษ
Layered System	CDN, gateway, load balancer ได้โดยไม่เปลี่ยน client	เพิ่ม latency ต่อ hop
Client-Server	frontend/backend พัฒนาอิสระ	ต้องตกลง contract ก่อน

ข้อผิดพลาดที่พบบ่อย

Session State ฝั่ง Server อาการ:

server เก็บ shopping cart ใน memory session
เมื่อ scale เป็น 2 server, cart หายเมื่อ request ไปต่าง server
เก็บ state ใน client หรือ database แทน server memory

ละเมิด Uniform Interface ด้วย Endpoint พิเศษ อาการ:

POST /users/search แทน GET /users?q=john
POST ที่ side effect ไม่ชัด — cache ไม่ได้, ไม่ idempotent
ใช้ GET + query parameter สำหรับ search/filter

💡 ตัวอย่างจากของจริง

AWS API:

stateless authentication — ทุก request มี signature ของตัวเอง (SigV4)

ไม่มี session — ทุก request authenticate อิสระ

Stripe API:

Uniform Interface ครบ — resource-based URI, method แสดง intent

ทำงานกับ CDN และ reverse proxy ได้โดยไม่เปลี่ยน client