HTTP status code ถูกจัดกลุ่มเป็น ห้าคลาส ตามตัวเลขหลักแรก และการเลือกให้ถูกทำให้ client ตอบสนองได้อย่างถูกต้องโดยไม่ต้องแกะ body
2xx Success — the request worked
3xx Redirection — further action / resource moved
4xx Client error — the caller did something wrong
5xx Server error — the server failed
2xx
200 OK — สำเร็จโดยทั่วไป (GET, PUT, PATCH)201 Created — มีการสร้างทรัพยากร (คืนค่า header Location)202 Accepted — รับไว้เพื่อประมวลผลแบบ async ยังไม่เสร็จ204 No Content — สำเร็จโดยไม่มี body (พบบ่อยกับ DELETE)4xx
400 Bad Request — ไวยากรณ์ผิดรูปหรือ input ไม่ถูกต้อง401 Unauthorized — ยังไม่ได้ยืนยันตัวตน (ไม่มี/credential ไม่ถูกต้อง)403 Forbidden — ยืนยันตัวตนแล้วแต่ไม่ได้รับอนุญาต404 Not Found — ทรัพยากรไม่มีอยู่409 Conflict — ขัดแย้งกับสถานะปัจจุบัน (เช่น อีเมลซ้ำ)422 Unprocessable Entity — รูปแบบถูกต้องแต่ไม่ผ่าน validation429 Too Many Requests — ถูก rate limit5xx
500 Internal Server Error — ความผิดพลาดของ server ที่ไม่คาดคิด503 Service Unavailable — หยุด/โอเวอร์โหลดชั่วคราวPOST /users → 201 Created
Location: /users/42
DELETE /users/42 → 204 No Content
GET /users/999 → 404 Not Found
{ "error": "user not found" }
จุดแยกแยะสำคัญที่ผู้สัมภาษณ์ชอบเจาะ: 401 ("คุณเป็นใคร?") vs 403 ("รู้จักคุณแล้ว แต่ไม่ให้") และ 400 (ไวยากรณ์ผิด) vs 422 (ไวยากรณ์ถูก ข้อมูลผิด)
Status code คือสัญญาณหลักใน response ของ REST — client, proxy, monitoring, และลอจิก retry ล้วนอิงจากมัน การใส่ให้ถูกจึงจำเป็นต่อการทำงานร่วมกัน (interoperability) ความล้มเหลวที่พบบ่อยคือการคืน 200 OK พร้อม body { "error": ... }: มันบังคับให้ทุก client แกะ body ก่อนถึงจะรู้ว่าสำเร็จหรือไม่ ทำลายเครื่องมือ HTTP ทั่วไป และซ่อนความล้มเหลวจาก monitoring โค้ดที่แม่นยำยังขับเคลื่อนพฤติกรรมอัตโนมัติ: 429 หรือ 503 บอกให้ client ที่สร้างมาดีถอยและ retry ส่วน 4xx บอกว่า "อย่า retry แก้ request ซะ" ผู้สัมภาษณ์ใช้คำถามนี้ตรวจว่าคุณเข้าใจ HTTP ในฐานะสัญญา ไม่ใช่ท่อส่งข้อมูลใบ้ ๆ และแยกคู่ที่ละเอียดอ่อน (401/403, 400/422) ได้ถูกต้อง — อันเป็นเครื่องหมายของคนที่สร้างและใช้ API จริง
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค