🎙️ API ที่ดีไม่ควรฉลาดเกินไป — แค่ “น่าเบื่อ” ก็พอ ลองจินตนาการว่า API คือเครื่องมือช่างในกล่อง — คุณไม่อยากให้ไขควงมีฟีเจอร์ลับซ่อนอยู่ คุณแค่อยากให้มันหมุนได้ดีและไม่พังเมื่อใช้งาน Sean Goedecke เล่าไว้อย่างน่าสนใจว่า API ที่ดีควร “น่าเบื่อ” เพราะมันควรใช้งานได้โดยไม่ต้องคิดมาก ไม่ต้องอ่านเอกสารยาวเหยียด และไม่ต้องกลัวว่าพรุ่งนี้จะเปลี่ยนโครงสร้างจนโค้ดพัง แต่การออกแบบ API ไม่ใช่เรื่องง่าย เพราะมันต้องสมดุลระหว่าง “ความคุ้นเคย” กับ “ความยืดหยุ่น” และที่สำคัญที่สุดคือ “อย่าทำให้ผู้ใช้ต้องแก้โค้ดเพราะคุณเปลี่ยนใจ” เขายกตัวอย่างว่าแม้แต่การเปลี่ยนชื่อ field หรือย้ายตำแหน่งใน JSON ก็อาจทำให้ระบบ downstream พังทั้งแถบ เพราะฉะนั้นหลักการสำคัญคือ “WE DO NOT BREAK USERSPACE” ถ้าจำเป็นต้องเปลี่ยนจริงๆ ก็ต้องใช้ versioning — เช่น /v1/ กับ /v2/ — เพื่อให้ผู้ใช้เลือกได้ว่าจะอยู่กับเวอร์ชันเดิมหรืออัปเกรด นอกจากนี้ยังมีเรื่องที่นักพัฒนามักมองข้าม เช่น การรองรับ idempotency เพื่อให้ retry ได้อย่างปลอดภัย, การตั้ง rate limit เพื่อป้องกัน abuse, และการใช้ cursor-based pagination เพื่อรองรับข้อมูลจำนวนมาก สุดท้าย เขาย้ำว่า API ที่ดีไม่สามารถช่วยผลิตภัณฑ์ที่แย่ได้ และผลิตภัณฑ์ที่ดีจะทำให้ผู้ใช้ยอมทนกับ API ที่แย่ — ดังนั้นจงโฟกัสที่ “สิ่งที่ API เชื่อมต่ออยู่” มากกว่าตัว API เอง 📌 สรุปเนื้อหาเป็นหัวข้อ ➡️ API ที่ดีควร “น่าเบื่อ” เพื่อให้ผู้ใช้เข้าใจได้ทันทีโดยไม่ต้องอ่านเอกสาร ➡️ การเปลี่ยนแปลง API มีต้นทุนสูง เพราะอาจทำให้ระบบ downstream พัง ➡️ หลักการสำคัญคือ “WE DO NOT BREAK USERSPACE” — ห้ามเปลี่ยน field หรือโครงสร้างที่มีอยู่แล้ว ➡️ การเปลี่ยน API ควรใช้ versioning เช่น /v1/, /v2/ เพื่อให้ผู้ใช้เลือกได้ ➡️ API versioning เป็น “สิ่งจำเป็นแต่ยุ่งยาก” เพราะต้องดูแลหลายเวอร์ชันพร้อมกัน ➡️ API ที่ดีควรมี idempotency key เพื่อให้ retry ได้โดยไม่เกิดผลซ้ำ ➡️ ควรมี rate limit และ killswitch เพื่อป้องกันการใช้งานเกินขอบเขต ➡️ การใช้ cursor-based pagination เหมาะกับข้อมูลจำนวนมาก เพราะเร็วและเสถียรกว่า offset ➡️ ควรทำให้ field ที่ใช้ทรัพยากรสูงเป็น optional เช่น subscription status ➡️ GraphQL มีข้อดีเรื่องความยืดหยุ่น แต่ซับซ้อนและยากต่อผู้ใช้ทั่วไป ➡️ Internal API สามารถเปลี่ยนแปลงได้ง่ายกว่า เพราะควบคุมผู้ใช้ได้โดยตรง ✅ ข้อมูลเสริมจากภายนอก ➡️ API versioning ช่วยให้สามารถอัปเดตระบบโดยไม่กระทบผู้ใช้เดิม ➡️ การจัดการ breaking changes ต้องมีแผนระยะยาวและการสื่อสารที่ชัดเจน ➡️ API-as-a-Service (APIaaS) ทำให้การจัดการเวอร์ชันเป็นเรื่องสำคัญในระบบขนาดใหญ่ ➡️ การใช้ header เช่น X-Limit-Remaining และ Retry-After ช่วยให้ผู้ใช้ควบคุมการเรียก API ได้ดีขึ้น ➡️ การใช้ Redis สำหรับเก็บ idempotency key เป็นวิธีง่ายและมีประสิทธิภาพ https://bmitch.net/blog/2025-08-22-ghrc-appears-malicious/