รหัสสถานะ REST HTTP สำหรับการตรวจสอบที่ล้มเหลวหรือซ้ำกันไม่ถูกต้อง

ฉันกำลังสร้างแอปพลิเคชันด้วย API ที่ใช้ REST และมาถึงจุดที่ฉันระบุรหัสสถานะสำหรับแต่ละคำขอ

ฉันควรส่งรหัสสถานะใดสำหรับคำร้องขอที่ไม่ผ่านการตรวจสอบความถูกต้องหรือที่คำขอกำลังพยายามเพิ่มซ้ำในฐานข้อมูลของฉัน

ฉันได้ตรวจสอบhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlแต่ดูเหมือนว่าไม่มีสิ่งใดถูกต้อง

มีวิธีปฏิบัติทั่วไปเมื่อส่งรหัสสถานะหรือไม่

สำหรับการตรวจสอบอินพุตล้มเหลว: 400 คำขอไม่ถูกต้อง + คำอธิบายเพิ่มเติมของคุณ สิ่งนี้แนะนำในหนังสือ " RESTful Web Services " สำหรับการส่งซ้ำ: 409 ความขัดแย้ง

อัปเดตมิถุนายน 2014

ข้อมูลจำเพาะที่เกี่ยวข้องเคยเป็นRFC2616ซึ่งให้การใช้ 400 (คำขอไม่ถูกต้อง) ค่อนข้างแคบเป็น

เซิร์ฟเวอร์ไม่สามารถเข้าใจการร้องขอได้เนื่องจากไวยากรณ์ผิดรูปแบบ

ดังนั้นจึงอาจเป็นที่ถกเถียงกันอยู่ว่ามันไม่เหมาะสมสำหรับข้อผิดพลาดทางความหมาย แต่ไม่มีอีกต่อไป; ตั้งแต่เดือนมิถุนายน 2014 มาตรฐานRFC 7231 ที่เกี่ยวข้องซึ่งแทนที่ RFC2616 ก่อนหน้านี้ทำให้มีการใช้400 (คำขอไม่ถูกต้อง) ในวงกว้างมากขึ้นเป็น

เซิร์ฟเวอร์ไม่สามารถหรือไม่สามารถดำเนินการตามคำขอเนื่องจากสิ่งที่ถูกมองว่าเป็นข้อผิดพลาดของไคลเอ็นต์

• การตรวจสอบล้มเหลว: 403 ถูกห้าม ("เซิร์ฟเวอร์เข้าใจคำขอ แต่ปฏิเสธที่จะทำตาม") ตรงกันข้ามกับความคิดเห็นที่ได้รับความนิยม RFC2616 ไม่ได้พูดว่า "403 มีไว้สำหรับการรับรองความถูกต้องที่ล้มเหลวเท่านั้น" แต่ "403: ฉันรู้ว่าคุณต้องการอะไร แต่ฉันจะไม่ทำอย่างนั้น" เงื่อนไขนั้นอาจจะใช่หรือไม่ใช่เพราะการพิสูจน์ตัวตน
• กำลังพยายามเพิ่มรายการที่ซ้ำกัน: 409 Conflict ("การร้องขอไม่สามารถดำเนินการได้เนื่องจากข้อขัดแย้งกับสถานะปัจจุบันของทรัพยากร")

คุณควรให้คำอธิบายโดยละเอียดเพิ่มเติมในส่วนหัวการตอบสนองและ / หรือเนื้อหา (เช่นมีส่วนหัวที่กำหนดเอง - X-Status-Reason: Validation failed)

ผมขอแนะนำให้รหัสสถานะ 422 "ไม่สามารถประมวลผล Entity"

11.2 422 เอนทิตีที่ไม่สามารถประมวลผลได้

รหัสสถานะ 422 (หน่วยประมวลผลไม่ได้) หมายความว่าเซิร์ฟเวอร์เข้าใจประเภทเนื้อหาของเอนทิตีที่ร้องขอ (ดังนั้นรหัสสถานะ 415 (ประเภทสื่อที่ไม่สนับสนุน) ไม่เหมาะสม) และไวยากรณ์ของเอนทิตีที่ร้องขอนั้นถูกต้อง (ดังนั้น 400 (คำขอไม่ถูกต้อง) ) รหัสสถานะไม่เหมาะสม) แต่ไม่สามารถประมวลผลคำแนะนำที่มีอยู่ ตัวอย่างเช่นเงื่อนไขข้อผิดพลาดนี้อาจเกิดขึ้นหากเนื้อความคำขอ XML มีรูปแบบที่ถูกต้อง (เช่นถูกต้องทางไวยากรณ์) แต่คำแนะนำ XML ที่ผิดพลาดทางความหมาย

200,300, 400, 500 ล้วนแล้วแต่เป็นของทั่วไป ถ้าคุณต้องการทั่วไป 400 ก็โอเค

422 นั้นถูกใช้งานโดย API ที่เพิ่มจำนวนขึ้นและยังถูกใช้โดย Rails ด้วย

ไม่ว่าคุณจะเลือกรหัสสถานะใดสำหรับ API ใครบางคนก็จะไม่เห็นด้วย แต่ฉันชอบ 422 เพราะฉันคิดว่า '400+ สถานะข้อความ' นั้นกว้างเกินไป นอกจากนี้คุณไม่ได้รับประโยชน์จากโปรแกรมแยกวิเคราะห์ JSON ที่พร้อมใช้งาน ในทางตรงกันข้าม 422 ที่มีการตอบสนอง JSON นั้นชัดเจนมากและสามารถถ่ายทอดข้อมูลข้อผิดพลาดได้อย่างมากมาย

เมื่อพูดถึงการตอบสนองของ JSON ฉันมักจะสร้างมาตรฐานในการตอบสนองข้อผิดพลาด Rails สำหรับกรณีนี้ซึ่งก็คือ:

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

รูปแบบนี้เหมาะสำหรับการตรวจสอบความถูกต้องของรูปแบบซึ่งฉันพิจารณากรณีที่ซับซ้อนที่สุดที่จะสนับสนุนในแง่ของ 'การรายงานข้อผิดพลาด' หากโครงสร้างข้อผิดพลาดของคุณเป็นแบบนี้ก็น่าจะตอบสนองความต้องการการรายงานข้อผิดพลาดทั้งหมดของคุณได้

200

ฮึ ... (309, 400, 403, 409, 415, 422) ... จำนวนมากของคำตอบที่พยายามที่จะคาดเดาเถียงและมาตรฐานสิ่งที่เป็นรหัสตอบแทนที่ดีที่สุดสำหรับการร้องขอ HTTP ที่ประสบความสำเร็จแต่โทร REST ล้มเหลว

มันผิดที่จะรวมรหัสสถานะ HTTP และรหัสสถานะ REST

อย่างไรก็ตามฉันเห็นการใช้งานหลายอย่างผสมกันและนักพัฒนาหลายคนอาจไม่เห็นด้วยกับฉัน

รหัสส่งคืน HTTP เกี่ยวข้องกับHTTP Requestตัวเอง การเรียกใช้ REST เสร็จสิ้นโดยใช้การร้องขอ Hypertext Transfer Protocol และทำงานในระดับที่ต่ำกว่าวิธี REST ที่เรียกใช้ REST เป็นแนวคิด / วิธีการและผลลัพธ์เป็นผลลัพธ์ทางธุรกิจ / ตรรกะในขณะที่โค้ดผลลัพธ์ HTTP คือการส่งผ่าน

ตัวอย่างเช่นการส่งคืน "404 ไม่พบ" เมื่อคุณโทร / ผู้ใช้ / สับสนเนื่องจากอาจหมายถึง:

• URI ผิด (HTTP)
• ไม่พบผู้ใช้ (REST)

"403 ถูกห้าม / ปฏิเสธการเข้าถึง" อาจหมายถึง:

• ต้องได้รับอนุญาตพิเศษ เบราว์เซอร์สามารถจัดการได้โดยขอให้ผู้ใช้ / รหัสผ่าน (HTTP)
• สิทธิ์การเข้าถึงไม่ถูกต้องกำหนดค่าบนเซิร์ฟเวอร์ (HTTP)
• คุณต้องได้รับการรับรองความถูกต้อง (REST)

และรายการอาจดำเนินการต่อด้วย '500 เซิร์ฟเวอร์ข้อผิดพลาด "(ข้อผิดพลาดโยน Apache / Nginx HTTP หรือข้อผิดพลาดข้อ จำกัด ทางธุรกิจในส่วนที่เหลือ) หรือข้อผิดพลาด HTTP อื่น ๆ ฯลฯ ...

จากรหัสนั้นยากที่จะเข้าใจว่าอะไรคือสาเหตุของความล้มเหลวความล้มเหลว HTTP (การขนส่ง) หรือความล้มเหลว REST (ตรรกะ)

หากคำขอ HTTP ดำเนินการทางร่างกายสำเร็จแล้วควรส่งคืนรหัส 200 เสมอไม่ว่าจะพบระเบียนหรือไม่ก็ตาม เนื่องจากพบทรัพยากร URI และจัดการโดยเซิร์ฟเวอร์ HTTP ใช่มันอาจส่งคืนชุดที่ว่างเปล่า เป็นไปได้ไหมที่จะได้รับหน้าเว็บเปล่าที่มี 200 เป็นผลลัพธ์ HTTP ใช่ไหม

แทนที่จะเป็นเช่นนี้คุณอาจส่งคืนรหัส HTTP 200 รายการพร้อมตัวเลือก:

• วัตถุ "error" ในผลลัพธ์ JSON หากมีบางอย่างผิดพลาด
• อาร์เรย์ / วัตถุ JSON ว่างเปล่าหากไม่พบบันทึก
• ค่าสถานะผลลัพธ์ / ความสำเร็จแบบบูลร่วมกับตัวเลือกก่อนหน้าเพื่อการจัดการที่ดีขึ้น

นอกจากนี้ผู้ให้บริการอินเทอร์เน็ตบางรายอาจขัดขวางคำขอของคุณและส่งคืนรหัส HTTP 404 ให้คุณ นี่ไม่ได้หมายความว่าไม่พบข้อมูลของคุณ แต่เป็นสิ่งที่ผิดปกติในระดับการขนส่ง

จากWiki :

ในเดือนกรกฎาคม 2004 กลุ่มผู้ให้บริการโทรคมนาคมของสหราชอาณาจักรกลุ่ม BT ได้ติดตั้งระบบบล็อกเนื้อหา Cleanfeed ซึ่งจะส่งกลับข้อผิดพลาด 404 ไปยังคำขอใด ๆ สำหรับเนื้อหาที่ระบุว่าอาจผิดกฎหมายโดย Internet Watch Foundation ISP อื่น ๆ ส่งคืนข้อผิดพลาด "ต้องห้าม" HTTP 403 ในสถานการณ์เดียวกัน ในประเทศไทยและตูนิเซียมีรายงานการปฏิบัติที่ใช้ข้อผิดพลาดปลอม 404 เพื่อปกปิดการเซ็นเซอร์ ในตูนิเซียที่การเซ็นเซอร์รุนแรงก่อนการปฏิวัติปี 2554 ผู้คนเริ่มตระหนักถึงธรรมชาติของข้อผิดพลาดปลอม 404 และสร้างตัวละครในจินตนาการชื่อ "Ammar 404" ซึ่งเป็นตัวแทนของ "เซ็นเซอร์ที่มองไม่เห็น"

ทำไมไม่ตอบคำถามแบบนี้ด้วยล่ะ?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google จะส่งคืน 200 เป็นรหัสสถานะใน API Geocoding ของตนเสมอแม้ว่าคำขอจะล้มเหลวอย่างมีเหตุผล: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

Facebook จะส่งคืน 200 เสมอสำหรับคำขอ HTTP ที่ประสบความสำเร็จแม้ว่าคำขอ REST จะล้มเหลว: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

ง่ายมากรหัสสถานะ HTTP ใช้สำหรับการร้องขอ HTTP REST API เป็นของคุณกำหนดรหัสสถานะของคุณ

409 CONFLICTซ้ำในฐานข้อมูลที่ควรจะเป็น

ฉันแนะนำให้ใช้422 UNPROCESSABLE ENTITYสำหรับข้อผิดพลาดในการตรวจสอบ

ฉันให้คำอธิบายเพิ่มเติมของรหัส 4xx ที่นี่อีกต่อไป

รหัสสถานะ 304 ไม่ได้แก้ไขจะทำให้การตอบสนองที่ยอมรับได้กับคำขอซ้ำซ้อน สิ่งนี้คล้ายกับการประมวลผลส่วนหัวของการIf-None-Matchใช้แท็กเอนทิตี

ในความเห็นของฉันคำตอบของ @ Piskvor เป็นตัวเลือกที่ชัดเจนกว่าสิ่งที่ฉันเห็นว่าเป็นเจตนาของคำถามต้นฉบับ แต่ฉันมีทางเลือกที่เกี่ยวข้องเช่นกัน

หากคุณต้องการปฏิบัติต่อคำขอซ้ำซ้อนเป็นคำเตือนหรือการแจ้งเตือนแทนที่จะเป็นข้อผิดพลาดรหัสสถานะการตอบกลับของ304Not Modified และContent-Locationส่วนหัวที่ระบุว่าทรัพยากรที่มีอยู่นั้นจะถูกต้องเช่นกัน เมื่อความตั้งใจนั้นเป็นเพียงเพื่อให้แน่ใจว่ามีทรัพยากรอยู่คำขอที่ซ้ำกันจะไม่เป็นข้อผิดพลาด แต่เป็นการยืนยัน การร้องขอนั้นไม่ผิด แต่เป็นการทำซ้ำซ้อนและลูกค้าสามารถอ้างถึงทรัพยากรที่มีอยู่

กล่าวอีกนัยหนึ่งคำขอนั้นดี แต่เนื่องจากทรัพยากรมีอยู่แล้วเซิร์ฟเวอร์จึงไม่จำเป็นต้องดำเนินการใด ๆ เพิ่มเติม

อะแดปเตอร์ ActiveRecord ของ Ember-Data คาดว่า422 UNPROCESSABLE ENTITYจะถูกส่งคืนจากเซิร์ฟเวอร์ ดังนั้นหากคุณเป็นลูกค้าที่เขียนด้วย Ember.js คุณควรใช้ 422 เท่านั้น DS.Errors จะถูกเติมด้วยข้อผิดพลาดที่ส่งคืน แน่นอนคุณสามารถเปลี่ยน 422 เป็นรหัสอื่น ๆในอะแดปเตอร์ของคุณ