HTTP Response Code กับสิ่งที่เป็นปัญหากับชาว Backend

HTTP Response Code กับสิ่งที่เป็นปัญหากับชาว Backend
11/02/19   |   11.1k   |  

    คงไม่มี Developer คนไหนที่ไม่รู้จัก HTTP Response Code (หรือเรียกว่า HTTP Status Code แต่ในบทความนี้จะขอเรียกว่า HTTP Response Code นะครับ) ในยุคที่ RESTFul API ครองโลกอินเตอร์เน็ตอย่างนี้นะครับ ในบทความนี้ผู้เขียนจะนำประสบการณ์ รวมถึงปัญหาต่าง ๆ ที่เคยเจอมาแชร์ให้ฟังกัน ถ้าผู้อ่านท่านไหนที่รู้สึกว่ามี solution ที่ดีกว่าก็คอมเม้นต์มาคุยกันนะครับ

    ก่อนอื่นขอเกริ่นเกี่ยวกับ HTTP Response Code ก่อนว่ามันคืออะไร

 

ref: https://hangtenseo.com/http-status-codes-seo-best-practice/

 

HTTP Response Code คือตัวเลขชุดหนึ่ง ประกอบด้วยตัวเลข 3 ตัว ซึ่งเป็นมาตรฐานที่มีไว้เพื่อใช้ตอบกลับจากเซิฟเวอร์บนเว็บไซต์ต่าง ๆ

โดยตัวเลขแต่ละชุดก็จะมีความหมายที่แตกต่างกันไป ยกตัวอย่างง่าย ๆ เมื่อเราเข้าสู่เว็บไซต์ www.google.com สิ่งที่เกิดขึ้นคือ เราได้รับการตอบกลับจาก google ด้วย status code 200 (Success) และได้หน้าเว็บ (HTML) กลับมานั่นเอง

 

และแน่นอนว่า status code ไม่ได้มีเพียงแค่ 200 success เพียงอย่างเดียว มันยังมีเคสอื่นมากมายที่อาจเกิดขึ้นได้ 

งั้นเรามาทำความรู้จักกับ response code ที่พบเจอบ่อย ๆ กันครับ

201 created

ข้อมูลถูกเพิ่มเรียบร้อยแล้ว

202 Accepted

เซิฟเวอร์ได้รับ request แล้ว แต่ยังทำงานไม่เสร็จ

204 No Content

เซิฟเวอร์ได้ทำงานที่ต้องการเสร็จแล้ว แต่ไม่ได้มีการตอบ response body กลับไป

304 Not Modified

สิ่งที่ request ร้องขอไม่ได้มีการเปลี่ยนแปลง ทำให้ไม่มีการร้องขอข้อมูลใหม่จากเซิฟเวอร์

400 Bad Request

เซิฟเวอร์ไม่เข้าใจสิ่งที่ client ร้องขอมา ซึ่งอาจเกิดจากการที่ request ผิดรูปแบบที่ต้องการ

401 Unauthorized

เกิดจากการที่ client ไม่ได้ทำ authenticate มาก่อน ทำให้เซิฟเวอร์ไม่สามารถให้ request นี้ทำงานได้

403 Forbidden

คล้ายกับ 401 แต่กรณีนี้เซิฟเวอร์รู้ว่า client เป็นใคร แต่ client ไม่มีสิทธ์ในการเข้าถึงข้อมูลที่ต้องการ

413 Payload Too Large

เกิดจาก request ที่ client ส่งมามีขนาดใหญ่เกินกว่าที่เซิฟเวอร์รองรับ

422 Unprocessable Entity

เกิดจาก request ที่ส่งเข้ามามีรูปแบบที่ถูกต้อง แต่ข้อมูลที่ส่งเข้ามาไม่ถูกต้อง หรือไม่ครบตามความต้องการของเซิฟเวอร์

500 Internal Server Error 

เกิดการทำงานที่ไม่สมบูรณ์ขึ้นที่เซิฟเวอร์ ทำให้ไม่สามารถตอบกลับ client ตามที่ร้องขอมาได้

503 Service Unavailable

ขณะนี้เซิฟเวอร์ไม่สามารถทำงานได้ชั่วคราว อาจเกิดจากการทำงานหนักเกินไป หรือกำลังอยู่ในช่วงแก้ไขระบบ

สามารถดูข้อมูล HTTP response code ทั้งหมดได้ List of HTTP status codes

 

HTTP Response Code ก็ดูครบถ้วนดีนี่นา แล้วปัญหามันอยู่ตรงไหนล่ะ ?

จริง ๆ response code ที่มีอยู่มันก็ครบถ้วนแล้วล่ะครับ แต่ปัญหาที่ผู้เขียนเจอคือไม่รู้ว่าควรจะใช้ตัวไหนมากกว่า มาลองดูเคสที่เกิดขึ้นด้วยกันนะครับ

 

สำหรับการเพิ่มข้อมูลไปยัง Database หากเพิ่มสำเร็จควรใช้ status ไหน ? 

ถ้าได้อ่านข้อมูลที่อยู่ข้างบนมาแล้ว คงตอบได้อย่างไม่ลังเลเลยว่าใช้ 201 Created

ใช่ครับ ! ถูกต้องแล้ว !!

แล้วทำไมถึงเอาเคสนี้มาล่ะ ? คำตอบคือผู้เขียนได้เจอ service บางที่ตอบกลับมาด้วย response code 200 Success ทำให้เกิดการสงสัยว่าอาจจะมี response code อื่นที่เหมาะสมกว่านี้ จึง google หาดู จึงพบว่าเลขที่ควรตอบกลับไปคือ 201 ดังที่กล่าวมาครับ ใครที่ยังใช้ 200  อยู่ก็อย่าลืมเปลี่ยนกันล่ะ !

 

ถ้าเราทำการ search ด้วย query บางอย่าง แล้วไม่เจอข้อมูลที่ต้องการ ต้องตอบกลับด้วย Status ไหนล่ะ ?

ในเคสนี้มีตัวเลือกที่เป็นไปได้ค่อนข้างเยอะเลยครับ ไม่ว่าจะเป็น 200 Success, 204 No Content หรือ 404 Not Found

เอาล่ะสิ แล้วควจจะใช้ตัวไหนดี ? 

จากการที่ได้ discuss กับทีมมาได้ข้อสรุปว่าจะใช้ 200 Success เพราะมองว่าตัวเซิฟเวอร์ของเราทำงานถูกต้อง เพียงแต่ว่าไม่เจอข้อมูลที่ต้องการเท่านั้น ซึ่งอาจจะตอบกลับใน response body เป็น Array ว่างเปล่ากลับไปแทน

ส่วนเหตุผลที่ไม่ใช้ 204 No Content เพราะมองว่าไม่สามารถใส่ response body กลับมาได้ ซึ่งอาจทำให้ฝั่ง client ต้อง handle มากกว่าปกติ

และเหตุผลที่ไม่ใช่ 404 Not Found เพราะมองว่า 404 เหมาะกับการที่ไม่สามารถเข้าถึงข้อมูลได้ เช่น page หรือ route นี้ไม่มีอยู่จริงมากกว่า 

 

แล้วถ้าเราต้องการอัพเดตหรือลบข้อมูลใน database แต่ไม่เจอไอดีที่ต้องการล่ะ ?

ปวดหัวอีกแล้วสิ จริง ๆ แล้วเคสนี้ยังไม่ได้ข้อสรุปที่ชัดเจนนัก แต่จะมาอธิบายให้ฟังแล้วกันนะครับว่าคิดยังไงกัน

เลือกใช้ 404 Not Found เพราะมองว่าไม่เจอ id นี้ใน database จริง ๆ

เลือกใช้ 422 Unprocessable Entity เพราะมองว่า request ที่ถูกร้องขอเข้ามามีรูปแบบที่ถูกต้องแล้ว เพียงแต่ parameter id ที่ส่งเข้ามาไม่สามารถนำไปใช้งานได้จริง หรือไม่ตรงตามที่เซิฟเวอร์ต้องการ

เลือกใช้ 204 No Content เพราะไม่ต้องการให้ client รู้ว่าลบสำเร็จจริง ๆ หรือไม่ เพราะอาจเป็นช่องโหว่ให้ hacker สามารถหาข้อมูลที่มีอยู่จริงได้

เลือกใช้ 200 Success แต่เพิ่ม response body ว่าจำนวนที่ลบออกไปเป็น 0 แทน

 

อย่างที่กล่าวไปตอนแรกครับว่านี่เป็นเพียงสิ่งที่ทีมได้ discuss และตกลงร่วมกันเพียงเท่านั้น สำหรับผู้อ่านท่านใดที่รู้สึกว่าเคสตัวอย่างที่ยกมาใช้ response code ที่ไม่ถูกต้อง ลองคอมเม้นต์มาคุยกันได้เลยครับผม

 

ยังไงก็ขอจบบทความก่อนจะปวดหัวไปมากกว่านี้นะครับ ขอบคุณที่อ่านมาจนจบครับผม !

 

Reference

tags : restful api backend developer



ติดตามข่าวสารและเรื่องราวดีๆ ทาง Email