Versioning และ Caching

API ที่อยู่ได้นานถูกกำหนดรูปร่างด้วยสองแรง: ต้อง เปลี่ยนแปลง ได้โดยไม่ทำให้ client ที่ใช้งานอยู่พัง และต้อง เร็ว คือไม่ทำงานซ้ำในสิ่งที่เคยทำไปแล้ว เรื่องแรกเป็นหน้าที่ของ versioning ส่วนเรื่องที่สองเป็นหน้าที่ของ HTTP caching

สองประเด็นสำคัญ

flowchart TD
  API --> V[Versioning: evolve safely]
  API --> Cn[Content negotiation: pick a representation]
  API --> Ca[Caching: avoid repeating work]
  V --> V1[URI / header / media-type]
  Ca --> Ca1[Cache-Control + ETag + conditional requests]

พัฒนา contract และให้บริการอย่างมีประสิทธิภาพ

ทั้งสองเรื่องนี้เกี่ยวข้องกัน: caching ขึ้นอยู่กับ representation ที่เสถียร, และ versioning เป็นตัวกำหนดว่า representation เหล่านั้นจะมีหน้าตาเป็นอย่างไรเมื่อเวลาผ่านไป

โมดูลนี้ครอบคลุมอะไรบ้าง

Versioning strategies — versioning แบบ URI, header, และ media-type
Content negotiation — การเลือก representation ด้วย Accept
Caching และ ETags — Cache-Control, validator, และ 304 Not Modified
Conditional requests และ idempotency keys — การเขียนและการ retry ที่ปลอดภัย

🌐 เวอร์ชันที่ถูกที่สุดคือการไม่ต้องมีเวอร์ชันใหม่

การเปลี่ยนแปลงส่วนใหญ่ทำแบบเพิ่มเข้าไป (additive) ได้ — เพิ่ม field ที่เป็น optional หรือเพิ่ม endpoint ใหม่ — client เดิมก็แค่มองข้ามไป เก็บการขึ้นเวอร์ชันใหม่ไว้ใช้กับ breaking change จริง ๆ เท่านั้น ทุกเวอร์ชันที่ปล่อยออกไปคือภาระที่คุณต้องดูแลต่อ ดังนั้นตั้งมาตรฐานให้สูงไว้ก่อนตัดสินใจขึ้นเวอร์ชัน

การเปลี่ยนแปลงแบบใดที่มักจะไม่ต้องการ API เวอร์ชันใหม่? การลบ field ออก การเพิ่ม field ใหม่ที่เป็น optional การเปลี่ยนชื่อ endpoint การเปลี่ยน type ของ field

HTTP caching ช่วย API เป็นหลักในด้านใด? เข้ารหัส response หลีกเลี่ยงการทำงานซ้ำสำหรับ resource ที่ไม่ได้เปลี่ยนแปลง ตรวจสอบความถูกต้องของ input ทำ versioning ให้ API