การอ้างอิงรหัสสถานะ HTTP

การอ้างอิงรหัสสถานะ HTTP เป็นดัชนีข้อมูลที่สมบูรณ์และค้นหาได้ง่ายของทุกรหัสสถานะที่ถูกกำหนดไว้ในข้อกำหนดคุณลักษณะของ HTTP — ตั้งแต่ 100 Continue ไปจนถึง 511 Network Authentication Required โดยแต่ละรายการจะแสดงชื่ออย่างเป็นทางการ เอกสาร RFC ที่ใช้กำหนด ความหมายที่แท้จริงของรหัสสถานะ หมายถึง อะไร เมื่อใดที่ควรส่ง เมื่อใดที่ ไม่ควร ส่ง และข้อผิดพลาดทั่วไปที่มักเกิดขึ้นในโค้ด นอกจากนี้ยังมีตัวกรองสดแบบเรียลไทม์และปุ่มตัวกรองหมวดหมู่ที่ช่วยให้คุณสลับดูคลาสต่าง ๆ ได้ในคลิกเดียว

เครื่องมือนี้นำเสนอข้อมูลที่แตกต่างจากตารางสรุปทั่วไป โดยจะให้หน้าย่อยเฉพาะสำหรับแต่ละรหัส ซึ่งประกอบด้วยแผงข้อมูลแถบสี 3 ส่วน (สิ่งที่ควรทำ / สิ่งที่ไม่ควรทำ / ข้อผิดพลาดที่พบบ่อย) พร้อมด้วยโค้ดสำเร็จรูปที่พร้อมสำหรับนำไปวางใน Express.js, Django, FastAPI และ Go net/http แผนภาพจำลองแบบเคลื่อนไหวช่วยแสดงให้เห็นเส้นทางการเดินทางของคำขอจากไคลเอนต์ไปยังเซิร์ฟเวอร์ และการส่งรหัสสถานะที่เลือกกลับมา ซึ่งเป็นประโยชน์มากสำหรับนักพัฒนาหน้าใหม่ในการทำความเข้าใจว่ารหัสสถานะมีบทบาทอย่างไรในการสื่อสารผ่านเครือข่าย

ทำไมข้อมูลการอ้างอิงรหัสสถานะถึงมีความสำคัญ

วิธีใช้งาน การอ้างอิงรหัสสถานะ HTTP

1. ค้นหาด่วน. เพียงพิมพ์ตัวเลขรหัส (404) หรือส่วนหนึ่งของชื่อสถานะ (teapot, gateway) ลงในกล่องค้นหาที่อยู่ด้านบนสุดแล้วกดส่ง ข้อมูลที่ตรงกันจะเปิดแสดงขึ้นมาพร้อมกับแผงรายละเอียดที่ครบถ้วน
2. เรียกดูตามคลาสข้อมูล. คลิกที่ปุ่มหมวดหมู่ทั้ง 5 ปุ่ม (1xx, 2xx, 3xx, 4xx, 5xx) เพื่อกรองตารางข้อมูลให้แสดงเฉพาะรหัสในคลาสนั้น ๆ และคลิกที่ปุ่ม ทั้งหมด เพื่อรีเซ็ตตัวกรอง
3. ตัวกรองแบบสด. กล่องตัวกรองที่อยู่เหนือตารางข้อมูลจะช่วยคัดกรองการ์ดข้อมูลให้แคบลงในขณะที่คุณพิมพ์ ซึ่งมีประโยชน์อย่างยิ่งเมื่อคุณจำชื่อได้เพียงบางส่วน เช่น too many หรือ precondition
4. ตรวจสอบรายละเอียดรหัสข้อมูล. คลิกที่การ์ดรหัสใด ๆ เพื่อเปิดดูแผงรายละเอียด คุณจะพบความหมาย เมื่อใดควรใช้ เมื่อใดไม่ควรใช้ ข้อผิดพลาดทั่วไป และบล็อกโค้ดตัวอย่างสำหรับ 4 เฟรมเวิร์กยอดนิยม
5. คัดลอกส่วนโค้ดสำเร็จรูป. ใช้ปุ่มสลับแท็บเฟรมเวิร์กและกดปุ่ม คัดลอก เล็ก ๆ เพื่อคัดลอกโค้ดไปใช้อย่างง่ายดาย
6. เปรียบเทียบรหัสใกล้เคียง. ที่ส่วนท้ายของแผงรายละเอียดจะมีการ์ดของรหัสอื่น ๆ ที่อยู่ในคลาสเดียวกัน (1xx / 2xx / 3xx / 4xx / 5xx) แสดงอยู่ด้วย เพื่อให้คุณเปรียบเทียบข้อมูลเคียงข้างกันได้อย่างรวดเร็ว

สรุปคลาสข้อมูลรหัสสถานะ HTTP ทั้งห้าคลาสในพริบตา

คู่รหัสสถานะที่มักจะสับสนบ่อยๆ

• 401 เทียบกับ 403. 401 หมายถึง ยังไม่ได้ตรวจสอบสิทธิ์ (unauthenticated) — คำขอนั้นขาดข้อมูลประจำตัวที่ถูกต้อง ส่วน 403 หมายถึง ตรวจสอบสิทธิ์แล้วแต่ไม่มีสิทธิ์ (authenticated but not allowed) — ข้อมูลประจำตัวถูกต้องดีแต่ผู้ใช้รายนั้นไม่มีสิทธิ์เข้าถึงทรัพยากรดังกล่าว
• 404 เทียบกับ 410. 404 หมายถึง ไม่พบ / ไม่รู้จัก: ทรัพยากรนั้นอาจจะมีอยู่ที่ไหนสักแห่ง หรือผู้ใช้อาจพิมพ์ URL ผิด ส่วน 410 หมายถึง ถูกลบออกอย่างถาวร: ตัวค้นหา (search engines) ควรนำ URL นี้ออกจากดัชนีการค้นหาทันที
• 301 เทียบกับ 302 เทียบกับ 307 เทียบกับ 308. 301 และ 308 เป็นการย้ายแบบถาวร (โดยรหัส 308 จะคงรูปแบบวิธีการเมธอดและข้อมูลในเนื้อหา body ไว้อย่างเข้มงวด) ส่วน 302 และ 307 เป็นการย้ายแบบชั่วคราว (โดยรหัส 307 จะคงรูปแบบวิธีการเมธอดและข้อมูลในเนื้อหา body ไว้) แนะนำให้ใช้รหัส 307 และ 308 สำหรับการเปลี่ยนเส้นทางของคำขอประเภท POST / PUT / PATCH
• 400 เทียบกับ 422. 400 หมายถึงรูปแบบคำขอผิดพลาด (เช่น โครงสร้าง JSON ผิดเพี้ยน, ขาดฟิลด์ที่จำเป็น) ส่วน 422 หมายถึงการวิเคราะห์โครงสร้างข้อมูลถูกต้องครบถ้วน แต่ค่าของข้อมูลไม่ผ่านกฎเกณฑ์ทางธุรกิจ (เช่น รูปแบบอีเมลไม่ถูกต้อง, ระบุจำนวนเกินขอบเขตที่กำหนด)
• 502 เทียบกับ 503 เทียบกับ 504. 502 หมายถึงเซิร์ฟเวอร์ปลายทางส่งข้อมูลที่ใช้งานไม่ได้กลับมา 503 หมายถึงเซิร์ฟเวอร์ทำงานหนักเกินไปหรือกำลังปิดปรับปรุง และ 504 หมายถึงเซิร์ฟเวอร์ปลายทางไม่ตอบสนองกลับมาภายในเวลาที่กำหนด
• 409 เทียบกับ 412. 409 คือการเกิดข้อขัดแย้งกับสถานะปัจจุบันของทรัพยากร ส่วน 412 หมายถึงข้อมูลส่วนหัวที่เป็นเงื่อนไขล่วงหน้า (precondition header เช่น If-Match, If-Unmodified-Since) ได้รับการประเมินผลออกมาเป็นเท็จ (false)

ข้อมูลส่วนหัว (Headers) ที่ต้องใช้คู่กับรหัสสถานะเฉพาะ

• 201 Created — ควรใส่ส่วนหัว Location ที่ระบุลิงก์ไปยังทรัพยากรใหม่ที่ถูกสร้างขึ้น
• 301 / 302 / 307 / 308 — จำเป็นต้องมีส่วนหัว Location พร้อม URL ปลายทางที่จะเปลี่ยนเส้นทางไป
• 304 Not Modified — ต้องแสดงข้อมูลส่วนหัวเหมือนกับที่ควรจะปรากฏในรหัส 200 (เช่น ETag, Cache-Control, Vary)
• 401 Unauthorized — จำเป็นต้องใส่ส่วนหัว WWW-Authenticate เพื่อระบุรูปแบบการตรวจสอบสิทธิ์ที่รองรับ (เช่น Basic, Bearer)
• 405 Method Not Allowed — จำเป็นต้องมีส่วนหัว Allow เพื่อระบุรายการของเมธอดที่ อนุญาต ให้ใช้งานได้
• 413 / 429 / 503 — มักจะมีการใส่ส่วนหัว Retry-After (ระบุเป็นวินาทีหรือรูปแบบวันที่ของ HTTP) เพื่อบอกให้ไคลเอนต์เว้นระยะเวลาก่อนส่งคำขอมาใหม่ได้อย่างถูกต้อง
• 416 Range Not Satisfiable — จำเป็นต้องระบุส่วนหัว Content-Range: bytes */<length>

รหัสสถานะที่คุณสามารถมองข้ามไปได้เกือบทั้งหมด

มีรหัสสถานะบางตัวที่ถูกต้องตามหลักการทางเทคนิค แต่พบได้ยากมากในระบบ API ยุคปัจจุบัน เช่น 305 Use Proxy (ปัจจุบันเลิกใช้งานแล้ว), 306 (ถูกจองไว้, ไม่มีการใช้งานจริง), 305, 506 Variant Also Negotiates, 510 Not Extended และ 508 Loop Detected รหัสเหล่านี้ส่วนใหญ่ยังคงถูกบันทึกไว้ในระบบลงทะเบียนด้วยเหตุผลทางประวัติศาสตร์ หากไลบรารีหรือมิดเดิลแวร์ของคุณส่งรหัสเหล่านี้ออกมา ให้คิดว่าเป็นข้อผิดพลาด (bug) ของไลบรารีนั้น ๆ มากกว่าที่จะต้องเขียนโค้ดเพื่อรองรับมันเป็นพิเศษ

คำถามที่พบบ่อย (FAQ)

เครื่องมือนี้นับรวมรหัสจากเอกสาร RFC อื่นๆ นอกเหนือจาก RFC 9110 หรือไม่?

ใช่ เครื่องมือนี้ครอบคลุมข้อมูลจาก RFC 9110 (ความหมายหลักของ HTTP), RFC 6585 (รหัสคลาส 4xx / 5xx เพิ่มเติม), RFC 4918 (WebDAV), RFC 5842 (WebDAV bindings), RFC 7725 (451), RFC 8297 (103 Early Hints), RFC 8470 (425 Too Early) รวมไปถึงรหัสตลกขบขันที่เป็นที่รู้จักกันดีอย่าง RFC 2324 (418 Teapot)

รหัสสถานะเหล่านี้ใช้ได้กับ HTTP/2 และ HTTP/3 หรือไม่?

ใช่ ความหมายของรหัสสถานะต่าง ๆ ถูกกำหนดไว้ในเอกสาร RFC 9110 ซึ่งเป็นข้อกำหนดหลักที่ไม่ขึ้นกับเวอร์ชันของ HTTP โดยที่ HTTP/2 (RFC 9113) และ HTTP/3 (RFC 9114) จะเปลี่ยนเฉพาะวิธีการจัดโครงสร้างเฟรมข้อมูลและการรับส่งข้อมูลผ่านเครือข่ายเท่านั้น

ฉันสามารถแชร์ลิงก์ตรงไปยังรหัสสถานะเฉพาะเจาะจงได้หรือไม่?

ได้ เพียงคุณค้นหารหัสสถานะที่ต้องการ (เช่น 404) แผงรายละเอียดจะถูกโหลดขึ้นมาที่ด้านล่างของกล่องค้นหา คุณสามารถคัดลอก URL ในแถบที่อยู่ของเบราว์เซอร์ไปแชร์ต่อได้ทันที และเมื่อเปิดลิงก์ขึ้นมาก็จะแสดงผลลัพธ์แบบเดียวกัน

ทำไมเฟรมเวิร์กที่ฉันใช้ถึงไม่ยอมให้ส่งค่ารหัส 418 กลับไป?

ไลบรารี HTTP เวอร์ชันเก่าบางตัวจะไม่ยอมส่งรหัสสถานะที่ไม่ได้ถูกบันทึกไว้ในระบบทะเบียนภายในของตนเอง วิธีแก้ไขคือให้ทำการอัปเดตเวอร์ชันของไลบรารี หรือหากทำได้ ให้ใช้วิธีการเขียนบรรทัดสถานะ (status line) ด้วยตัวเองแบบแมนนวล

ระบบ API ควรส่งรหัส 200 พร้อมกับข้อมูลเนื้อหา (body) ที่บอกว่าเกิดข้อผิดพลาดหรือไม่?

ไม่ควรอย่างยิ่ง เพราะระบบมอนิเตอร์, ระบบส่งคำขอซ้ำอัตโนมัติ (retries) และตัวกลางในเครือข่ายต่าง ๆ จะทึกทักเอาว่ารหัสคลาส 2xx หมายถึงการทำงานที่สำเร็จ หากคุณต้องการส่งโครงสร้างข้อผิดพลาดกลับไป ให้เลือกใช้รหัสในคลาส 4xx หรือ 5xx ที่เหมาะสม แล้วแนบรายละเอียดรูปแบบข้อผิดพลาดไว้ในเนื้อหาคำขอแทน ซึ่งข้อกำหนดรูปแบบ Problem Details สำหรับ HTTP APIs (RFC 9457) ถือเป็นแม่แบบที่ดีมากสำหรับการใช้งานในส่วนนี้

ระบบลงทะเบียนรหัสสถานะ HTTP ที่เป็นทางการและเป็นข้อยุติมีอยู่ที่ไหน?

ใช่ IANA เป็นผู้ดูแลระบบลงทะเบียนอย่างเป็นทางการที่ iana.org/assignments/http-status-codes ซึ่งเครื่องมือนี้จะทำงานสอดคล้องอัปเดตตรงตามระบบลงทะเบียนดังกล่าวควบคู่ไปกับเอกสาร RFC ต่าง ๆ ที่ถูกนำมาอ้างอิงบ่อยที่สุด