Status Code และ Error

วิธีที่ API รายงานผลลัพธ์ก็เป็นส่วนหนึ่งของ contract เช่นกัน สองสิ่งที่ทำให้ contract นั้นน่าเชื่อถือคือ status code (ส่วนที่ client ใช้แตกกิ่งเงื่อนไข) และ error body ที่สม่ำเสมอ (ส่วนที่คนและ code อ่านเพื่อกู้สถานการณ์)

สำเร็จ, client error หรือ server fault?

flowchart TD
  Q{Did the request succeed?} -->|Yes| S[2xx]
  Q -->|No, caller's fault| C[4xx: fix the request]
  Q -->|No, our fault| E[5xx: retry may help]
  C --> C1[400 / 401 / 403 / 404 / 409 / 422]
  E --> E1[500 / 503]

ตัดสินใจเลือกกลุ่มก่อน แล้วจึงเลือก code ที่เจาะจง

กฎที่สำคัญที่สุดเพียงข้อเดียว: อย่าห่อความล้มเหลวไว้ใน 200 เด็ดขาด การตอบกลับที่บอกว่า 200 OK แต่กลับแนบ { "error": "..." } มาด้วยนั้นทำลายทุก client, cache และเครื่องมือ monitoring ที่เชื่อถือ status line

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

การเลือก status code — code ที่พบบ่อยและวิธีเลือกในกรณีที่ใกล้เคียงกัน
รูปแบบของ error (problem+json) — รูปทรงเดียวที่สม่ำเสมอสำหรับทุก error
Validation error — รายงาน input ที่ผิดทีละ field
การจัดการ error ใน TypeScript — แปลง error ที่ถูก throw ให้กลายเป็น response ที่สะอาด

status code กลุ่ม 5xx สื่อถึงอะไร? client ต้องเปลี่ยน request server ล้มเหลว; การ retry อาจสำเร็จ resource ย้ายที่แล้ว สำเร็จแต่ไม่มีเนื้อหา

ทำไมการตอบ 200 พร้อม error body จึงเป็นปัญหา? ทำงานช้ากว่า client, cache และ monitoring เชื่อถือ status line และจะถือว่าเป็นความสำเร็จ JSON เก็บ error ไม่ได้ ผิดข้อกำหนดของ HTTP