HTTP Status Code Lookup: คู่มือฉบับสมบูรณ์สำหรับนักพัฒนา

HTTP status code คือ "ภาษา" ที่ web server และ API ใช้สื่อสารกับ client ว่า request ที่ส่งไปนั้นสำเร็จหรือไม่ เกิด error อะไร หรือต้องทำอย่างไรต่อ สำหรับนักพัฒนาที่ทำงานกับ REST API, frontend app หรือ backend service การเข้าใจ status code แต่ละตัวให้ตรงความหมายถือเป็นพื้นฐานที่จำเป็นมาก เครื่องมือ HTTP Status Code Lookup ของเราคือ reference ที่ค้นหาได้ทันที ครอบคลุม 59+ status code จาก RFC 7231 และ specs ที่เกี่ยวข้อง พร้อมคำอธิบายแบบละเอียดทั้งหมด

ไม่ว่าคุณจะกำลัง debug อยู่หน้า console ที่มี error 502 Bad Gateway โผล่ขึ้นมา หรือออกแบบ API endpoint ใหม่และต้องตัดสินใจว่าควร return 201 Created หรือ 204 No Content — การมี reference ที่ค้นหาเร็วและถูกต้องจะช่วยประหยัดเวลาได้มาก ในคู่มือนี้เราจะเจาะลึกทุก class ของ status code พร้อมกรณีใช้งานจริงและ best practices ที่จะทำให้คุณใช้งาน HTTP ได้อย่างมั่นใจ

หากคุณเพิ่งเริ่มต้น เราแนะนำให้เปิด HTTP Status Code Lookup ไว้ใน tab ข้างๆ แล้วอ่านคู่มือนี้ไปพร้อมกัน เพื่อให้ลองค้นหา code ที่สนใจได้ทันที

ทำไมต้องใช้ HTTP Status Code Lookup?

• ค้นหาเร็วด้วยคำเดียว: พิมพ์เลข เช่น 404 หรือคำว่า Not Found ก็เจอ code ที่ต้องการทันที ไม่ต้องเปิด RFC ยาวๆ
• กรองตาม category ได้: เลือกดูเฉพาะ 2xx Success, 4xx Client Error หรือ class อื่นๆ เพื่อ focus ที่กลุ่มที่สนใจ
• ครอบคลุม 59+ codes: ตั้งแต่ 100 Continue ยัน 511 Network Authentication Required ครบทุก code ที่ใช้จริงใน web development สมัยใหม่
• คำอธิบายแบบปฏิบัติ: แต่ละ code มีคำอธิบายว่า server ส่งเมื่อไหร่ และ client ควรตีความอย่างไร — ไม่ใช่แค่ copy จาก spec
• อ้างอิงมาตรฐาน: ข้อมูลจริงจาก RFC 7231 และ RFC ที่เกี่ยวข้อง ทำให้มั่นใจได้ว่าถูกต้องตามมาตรฐาน HTTP
• ใช้งานได้ทันที ไม่ต้องติดตั้ง: เป็นเครื่องมือออนไลน์ล้วน เปิดบน browser ก็ใช้ได้เลย ไม่ต้องลง package หรือ extension

ฟีเจอร์เด่น

• การ search รองรับทั้งการพิมพ์ตัวเลขล้วน (200) และชื่อเต็ม (OK) รวมถึงคำใน description — ทำให้ค้นหาได้แม้จำแค่คำในคำอธิบาย
• การ filter ทำงานแบบ real-time กดเลือก category แล้วผลลัพธ์อัปเดตทันที เหมาะกับการเปรียบเทียบ code ที่ใกล้กัน เช่น 401 กับ 403
• Reference อ้างอิง RFC ที่น่าเชื่อถือ ทำให้มั่นใจได้ว่าข้อมูลไม่ผิดเพี้ยนจากมาตรฐาน HTTP อย่างเป็นทางการ

วิธีใช้งาน Lookup Tool

1. เปิดหน้าเครื่องมือ — ไปที่ HTTP Status Code Lookup คุณจะเห็นรายการ status code ทั้งหมดพร้อมช่อง search และปุ่ม filter ที่ด้านบน
2. พิมพ์คำค้นในช่อง search — ลองพิมพ์ตัวเลข (429) หรือชื่อ message (Too Many Requests) รายการจะกรองอัตโนมัติขณะพิมพ์
3. เลือก category ถ้าต้องการ — คลิกปุ่ม filter เช่น 4xx Client Error เพื่อจำกัดผลลัพธ์เฉพาะกลุ่มที่สนใจ
4. อ่านรายละเอียดของแต่ละ code — แต่ละ code จะแสดง numeric value, status message และคำอธิบายเต็มว่า server ส่งเมื่อไหร่และมีความหมายอย่างไร
5. ใช้ข้อมูลในการ debug หรือออกแบบ API — นำความหมายที่ได้ไปใช้ตรวจสอบปัญหา หรือเลือก status code ที่เหมาะสมสำหรับ endpoint ของคุณ

ทำความเข้าใจ HTTP Status Code Classes

HTTP status code แบ่งเป็น 5 class ตามตัวเลขหลักแรก แต่ละ class สื่อความหมายระดับสูงที่ต่างกัน การเข้าใจ class ก่อนจะช่วยให้เดาความหมายของ code ที่ไม่คุ้นได้เร็วขึ้น

1xx — Informational

Status code ใน class นี้บ่งบอกว่า server ได้รับ request แล้ว และกำลังประมวลผลต่อ โดยทั่วไป client ไม่ต้องทำอะไรเป็นพิเศษ เป็น class ที่พบได้น้อยที่สุดในการใช้งานปกติ เพราะ browser และ HTTP library ส่วนใหญ่จัดการให้อัตโนมัติ

• 100 Continue — server ยืนยันว่าพร้อมรับ body ของ request ต่อ มักใช้เมื่อ client ต้องการส่ง body ขนาดใหญ่และอยากเช็คก่อนว่า server รับได้
• 101 Switching Protocols — client ขอเปลี่ยน protocol (เช่นอัปเกรดเป็น WebSocket) และ server ตกลง
• 103 Early Hints — server ส่ง hint เบื้องต้นให้ client เริ่มโหลด resource บางอย่างก่อนที่ response จริงจะพร้อม

2xx — Success

class นี้หมายถึง request สำเร็จ เป็นกลุ่มที่นักพัฒนาคุ้นเคยที่สุดและอยากเห็นบ่อยที่สุด การเลือก code ที่เจาะจง เช่น 201 หรือ 204 จะช่วยให้ client เข้าใจผลลัพธ์ได้แม่นยำกว่าการใช้ 200 กับทุกกรณี

• 200 OK — request สำเร็ต และ response มี body ที่ตรงกับสิ่งที่ขอ (GET ที่สำเร็จมักใช้ code นี้)
• 201 Created — request สำเร็จและส่งผลให้มี resource ใหม่ถูกสร้างขึ้น มักใช้กับ POST ที่สร้าง record ใหม่ ควรส่ง Location header ชี้ไปยัง resource ใหม่ด้วย
• 204 No Content — request สำเร็จแต่ไม่มี body ส่งกลับ เหมาะกับ DELETE หรือ PUT ที่ไม่ต้องส่งข้อมูลกลับ

3xx — Redirection

class นี้บอก client ว่าต้องดำเนินการเพิ่มเติมเพื่อให้ request สำเร็จ มักเป็นการติดตาม Location header ไปยัง URL ใหม่ สำคัญมากต่อ SEO, URL migration และ caching

• 301 Moved Permanently — resource ย้ายไป URL ใหม่ถาวร client ควร cache และใช้ URL ใหม่ต่อไป สำคัญมากสำหรับ SEO
• 302 Found — resource ย้ายชั่วคราว client ใช้ URL เดิมในครั้งต่อไปได้ มักใช้หลัง login redirect
• 304 Not Modified — client ส่ง If-Modified-Since หรือ If-None-Match และ resource ไม่เปลี่ยน จึงไม่ต้องส่ง body กลับ — ช่วยประหยัด bandwidth อย่างมาก

4xx — Client Error

class นี้หมายความว่า request มีปัญหา ไม่ว่าจะเป็น syntax ผิด, ไม่มีสิทธิ์ หรือ resource ไม่มีอยู่จริง เป็นฝั่ง client ที่ต้องแก้ไข request แล้วลองใหม่ เป็นกลุ่มที่ frontend developer เจอบ่อยที่สุดในการ debug

• 400 Bad Request — server ไม่เข้าใจ request เพราะ syntax ผิด เช่น JSON malformed หรือ parameter ขาด
• 401 Unauthorized — request ไม่มีข้อมูล authentication ที่ถูกต้อง client ต้อง login หรือส่ง token ก่อน
• 403 Forbidden — server เข้าใจ request แต่ปฏิเสธจะดำเนินการ มักเป็นเรื่อง authorization — user login แล้วแต่ไม่มีสิทธิ์
• 404 Not Found — resource ที่ขอไม่มีอยู่ เป็น code ที่คุ้นเคยกันดี อาจหมายถึง URL ผิดหรือ record ถูกลบไปแล้ว
• 429 Too Many Requests — client ส่ง request เร็วเกินไป เป็นวิธีของ rate limiting ควรแนะนำให้ client ชะลอผ่าน Retry-After header

5xx — Server Error

class นี้บ่งบอกว่า server ล้มเหลวในการประมวลผล request ที่ถูกต้อง เป็นฝั่ง server ที่ต้องแก้ไข หากเห็น code ในกลุ่มนี้บ่อยๆ มักหมายถึง bug ใน backend, infra ล่ม หรือ dependency (เช่น database) มีปัญหา

• 500 Internal Server Error — error ทั่วไปฝั่ง server เกิด unhandled exception เกือบทุกครั้งหมายถึงมี bug ที่ต้องตรวจสอบใน log
• 502 Bad Gateway — server ทำหน้าที่เป็น gateway หรือ proxy แล้วได้ response ไม่ถูกต้องจาก upstream server มักเจอเวลา reverse proxy คุยกับ backend ไม่ได้
• 503 Service Unavailable — server ไม่พร้อมให้บริการชั่วคราว เช่น กำลัง maintenance หรือโหลดสูงเกินไป ควรส่ง Retry-After เพื่อบอก client ว่าควรลองใหม่เมื่อไหร่
• 504 Gateway Timeout — server ทำหน้าที่เป็น gateway แต่รอ response จาก upstream เกินเวลาที่กำหนด มักเป็นปัญหา upstream ช้าหรือค้าง

กรณีใช้งานจริง

Debug API call ที่ fail

เวลา frontend ดึงข้อมูลจาก API แล้วได้ error สิ่งแรกที่ควรดูคือ status code ใน Network tab ของ browser เช่น 401 บอกว่า token หมดอายุ, 404 บอกว่า URL ผิด, 500 บอกว่า backend มี bug ใช้ lookup tool ค้นหา code ที่เจอเพื่อเข้าใจสาเหตุและแก้ไขได้ถูกจุด แทนที่จะเดาสุ่มๆ

สร้าง REST API ที่ตอบ status code ที่ถูกต้อง

การออกแบบ API endpoint ที่ดีต้องเลือก status code ให้สื่อความหมายถูกต้อง เช่น POST ที่สร้าง resource ควร return 201 Created ไม่ใช่ 200, DELETE ที่สำเร็จควร return 204 No Content, PUT ที่ update สำเร็จอาจใช้ 200 OK หรือ 204 ก็ได้ การใช้ code ที่เจาะจงจะช่วยให้ client SDK และ frontend ตีความผลลัพธ์ได้แม่นยำ ลดความสับสนในการ integrate

จัดการ rate limiting (429)

หาก API ของคุณมีผู้ใช้จำนวนมาก การใช้ 429 Too Many Requests เพื่อจำกัดการเรียกเป็นวิธีมาตรฐาน ควรแนบ Retry-After header เพื่อบอก client ว่าควรรอกี่วินาทีก่อนลองใหม่ ฝั่ง client ก็ควรมี retry logic ที่อ่านค่านี้แล้วรอตามเวลาที่กำหนด แทนที่จะ loop ยิงซ้ำจน server ล่ม

Monitor server health (5xx)

ในการดูแลระบบ production อัตราการเกิด 5xx error เป็น metric สำคัญที่ต้อง monitor หาก error rate พุ่งขึ้นทันที มักเป็นสัญญาณว่ามี deployment ที่มี bug, database ล่ม หรือ dependency ภายนอกไม่ตอบ การเข้าใจความต่างระหว่าง 502, 503 และ 504 จะช่วยให้ triage ปัญหาได้เร็วและแม่นยำขึ้น — เช่น 502 มักเป็น upstream crash, 503 คือโหลดเกิน, 504 คือ upstream ช้าเกินไป

Best Practices

• เลือก code ที่เจาะจงที่สุดเท่าที่จะเป็นไปได้ — อย่าใช้ 200 OK กับทุกกรณี หาก POST สร้าง resource ใหม่ใช้ 201, หาก DELETE ไม่มี body ส่งกลับใช้ 204
• แยก 401 กับ 403 ให้ชัดเจน — 401 หมายถึงยังไม่ได้ login, 403 หมายถึง login แล้วแต่ไม่มีสิทธิ์ การสลับสอง code นี้จะทำให้ frontend เข้าใจผิดและ redirect ผู้ใช้ผิดทาง
• ใส่ body อธิบาย error ใน 4xx/5xx — ส่ง JSON ที่มี error field และ message ที่อ่านได้ เพื่อให้ client และ developer ที่ integrate รู้ว่าเกิดอะไรขึ้น ไม่ใช่แค่ code เปล่าๆ
• อย่ารั่วข้อมูลใน 401/403 — เพื่อความปลอดภัย บางทีควร return 404 แทน 403 เพื่อไม่ให้ผู้ไม่ประสงค์ดีรู้ว่า resource นั้นมีอยู่จริง
• ออกแบบ client-side retry logic อย่างระมัดระวัง — retry เฉพาะ error ที่ "น่าจะสำเร็จในครั้งถัดไป" เช่น 429, 503, 504 และใช้ exponential backoff เพื่อไม่ให้ server ล่มซ้ำ ส่วน 400 หรือ 404 retry ก็ไม่ช่วยเพราะเป็นปัญหาฝั่ง client
• ใช้ 301 สำหรับ redirect ถาวรเท่านั้น — เพราะ browser และ search engine จะ cache URL ใหม่ หากเป็น redirect ชั่วคราวใช้ 302 หรือ 307 เพื่อไม่ให้ cache ติด

เริ่มค้นหา Status Codes วันนี้

ไม่ว่าคุณจะเป็น junior ที่เพิ่งเริ่มเรียนรู้ HTTP หรือ senior engineer ที่ออกแบบ API ทุกวัน — การมี reference ที่ค้นหาเร็วและถูกต้องคือเครื่องมือที่ขาดไม่ได้ เปิด HTTP Status Code Lookup ทุกครั้งที่ต้องตรวจสอบ status code ไม่ว่าจะตอน debug, ออกแบบ endpoint ใหม่ หรืออ่าน code ของคนอื่น แล้วคุณจะรู้ว่าการทำงานกับ HTTP ง่ายและเป็นระบบมากกว่าที่คิด ลองเลย — พิมพ์ code แรกที่คุณเจอวันนี้ลงในช่อง search แล้วดูว่ามีรายละเอียดอะไรที่คุณไม่เคยรู้มาก่อน

เครื่องมือที่เกี่ยวข้อง

• HTTP Headers Viewer — ตรวจสอบ request และ response headers ที่มาพร้อมกับ status code เพื่อ debug ปัญหาได้ครบถ้วน
• JSON Formatter — pretty-print และ validate JSON API response ที่ส่งกลับมาพร้อม body ของแต่ละ status code
• Regex Tester — ทดสอบ regex pattern กับ API payload ก่อนส่ง request เพื่อลดโอกาสเจอ 400 Bad Request

ขอให้ debug อย่างมีความสุข!