รหัสสถานะ HTTP ที่เหมาะสมในการส่งคืนโดยบริการ REST API สำหรับการตรวจสอบความล้มเหลวคืออะไร

394

ปัจจุบันฉันกลับ 401 ไม่ได้รับอนุญาตเมื่อใดก็ตามที่ฉันประสบความล้มเหลวในการตรวจสอบความถูกต้องในแอปพลิเคชัน RANG API ของDjango / Pistonของฉัน เมื่อดูที่HTTP Status Code Registry ฉันไม่มั่นใจว่านี่เป็นรหัสที่เหมาะสมสำหรับการตรวจสอบความล้มเหลวคุณควรแนะนำอะไร

400 คำขอไม่ถูกต้อง
401 ไม่ได้รับอนุญาต
403 ต้องห้าม
ไม่อนุญาตให้ใช้วิธี 405
406 ไม่เป็นที่ยอมรับ
412 เงื่อนไขเบื้องต้นล้มเหลว
417 ความคาดหวังล้มเหลว
422 เอนทิตีที่ไม่สามารถประมวลผลได้
424 การพึ่งพาล้มเหลว

อัปเดต : "การตรวจสอบความล้มเหลว" ด้านบนหมายถึงความล้มเหลวในการตรวจสอบความถูกต้องของข้อมูลระดับแอปพลิเคชันเช่นวันที่และเวลาที่ระบุไม่ถูกต้องที่อยู่อีเมลปลอมเป็นต้น

validation rest http-status-codes

— michaeljoseph
แหล่งที่มา

2

ลองดูคำตอบนี้: stackoverflow.com/a/2657624/221612

— Kenny Meyer

3

FWIW การเชื่อมโยงของเคนนีแสดงให้เห็นรหัส 422 เป็นคำตอบของจิมตอนนี้ไม่ด้านล่าง #TheMoreYouKnow #SavingYouAClick

— ruffin

ฉันคิดว่า 401 ชัดเจนยิ่งขึ้น

— insign

298

หาก "การตรวจสอบความล้มเหลว" หมายความว่ามีข้อผิดพลาดบางอย่างของไคลเอนต์ในคำขอให้ใช้ HTTP 400 (คำขอไม่ถูกต้อง) ตัวอย่างเช่นถ้า URI ควรจะมีวันที่ ISO-8601 และคุณพบว่ามันอยู่ในรูปแบบที่ไม่ถูกต้องหรืออ้างอิงถึงวันที่ 31 กุมภาพันธ์คุณจะต้องส่งคืน HTTP 400 เช่นเดียวกันถ้าคุณคาดหวังว่า XML ที่มีรูปแบบที่ดีในองค์กร มันไม่สามารถแยกวิเคราะห์

(1/2016): กว่าห้าปีที่ผ่านWebDAV 's HTTP เฉพาะเจาะจงมากขึ้น 422 (ไม่สามารถประมวลผล Entity) ได้กลายเป็นทางเลือกที่เหมาะสมมากที่จะ HTTP 400 ดูตัวอย่างการใช้งานในJSON API แต่ไม่ทราบว่า HTTP 422 ยังไม่ได้ทำให้มันเป็น HTTP 1.1 RFC-7231

บริการเว็บ RESTfulของ Richardson and Ruby มีภาคผนวกที่มีประโยชน์มากเมื่อใช้รหัสตอบกลับ HTTP ต่างๆ พวกเขาพูดว่า:

400 (“ คำขอไม่ถูกต้อง”)
ความสำคัญ: สูง
นี่คือสถานะข้อผิดพลาดฝั่งไคลเอ็นต์ทั่วไปใช้เมื่อไม่มีรหัสข้อผิดพลาด 4xx อื่นที่เหมาะสม โดยทั่วไปจะใช้เมื่อลูกค้าส่งการแสดงพร้อมกับคำขอ PUT หรือ POST และการเป็นตัวแทนนั้นอยู่ในรูปแบบที่ถูกต้อง แต่ไม่มีเหตุผลใด ๆ (หน้า 381)

และ:

401 (“ ไม่ได้รับอนุญาต”)
ความสำคัญ: สูง
ไคลเอ็นต์พยายามดำเนินการกับทรัพยากรที่มีการป้องกันโดยไม่ต้องให้ข้อมูลรับรองการตรวจสอบความถูกต้องที่เหมาะสม อาจให้ข้อมูลประจำตัวที่ไม่ถูกต้องหรือไม่มีเลย ข้อมูลรับรองอาจเป็นชื่อผู้ใช้และรหัสผ่านคีย์ API หรือโทเค็นการตรวจสอบความถูกต้อง - บริการใด ๆ ที่เป็นที่ต้องการ เป็นเรื่องปกติที่ไคลเอนต์จะร้องขอ URI และรับ 401 เพียงเพื่อให้รู้ว่าชนิดของข้อมูลประจำตัวที่จะส่งและรูปแบบใด [ ... ]

— จิมเฟอแรน
แหล่งที่มา

3

แต่อาจหากรูปแบบ URI ไม่ถูกต้อง 404 อาจเหมาะสมกว่า

— มนู

11

ตามที่ระบุไว้โดย @ReWrite ฉันยังคิดว่า 422 จะดีกว่าสำหรับข้อผิดพลาดในการตรวจสอบความถูกต้อง

— panteo

11

ฉันว่านี่มันผิด 400 คำขอไม่ถูกต้องจะใช้เมื่อมีบางสิ่งผิดปกติทางไวยากรณ์กับคำขอนั้น ฉันจะบอกว่า ReWrite ถูกต้องในการแนะนำ 422 ซึ่งเป็นเรื่องเกี่ยวกับเนื้อหาของคำขอ

— Stijn de Witt

3

@ เคนจิใช่ 401 (“ ไม่ได้รับอนุญาต”): "อาจให้ข้อมูลประจำตัวที่ไม่ถูกต้อง ... " หมายถึงผู้ใช้และ / หรือรหัสผ่านผิด

— razzintown

4

@JimFerrans 400 ข้อผิดพลาดมีไว้เพื่อที่ไวยากรณ์ที่กำหนดไม่ถูกต้อง ข้อผิดพลาด 401 นั้นมีเฉพาะถ้าฉันพยายามเข้าถึงหน้าเว็บที่ฉันต้องเข้าสู่ระบบเพื่อเข้าถึงและฉันไม่ได้เข้าสู่ระบบเลย ข้อผิดพลาด 422 ใช้สำหรับการที่ไวยากรณ์ถูกต้อง แต่เซิร์ฟเวอร์ปฏิเสธบริการ ชื่อผู้ใช้ / รหัสผ่านไม่ถูกต้องคือไวยากรณ์ที่ถูกต้อง (ไม่ใช่ข้อผิดพลาด 400) และฉันไม่พยายามเข้าถึงหน้าเว็บที่ฉันต้องเข้าสู่ระบบเพราะฉันเข้าสู่หน้าเข้าสู่ระบบด้วยตัวเอง (ไม่ใช่ข้อผิดพลาด 401) ควรใช้ข้อผิดพลาด 401 เพื่อหน้าการตั้งค่าที่ผู้ใช้เท่านั้นที่สามารถเข้าถึงได้

— Zachary Weixelbaum

98

จาก RFC 4918 (และจัดทำเอกสารที่http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ):

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

— เขียน
แหล่งที่มา

6

ฉันจะแนะนำ 422 - เอนทิตีที่ประมวลผลไม่ได้สำหรับการตรวจสอบความล้มเหลวมากกว่า 400 - คำขอไม่ถูกต้อง

— java_geek

28

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

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

ฉันให้คำอธิบายเพิ่มเติมของรหัส 4xx ที่นี่: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

— ฟิลพาร์กเกอร์
แหล่งที่มา

19

นี่มันคือ:

rfc2616 # section-10.4.1 - 400 คำขอไม่ถูกต้อง

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

rfc7231 # section-6.5.1 - 6.5.1 400 คำขอไม่ถูกต้อง

รหัส 400 (Bad Request) สถานะบ่งชี้ว่าเซิร์ฟเวอร์ไม่สามารถหรือจะไม่ดำเนินการตามคำขอเนื่องจากสิ่งที่เห็นว่าเป็นข้อผิดพลาดของลูกค้า(เช่นไวยากรณ์ไม่ถูกต้องขอคำขอที่ไม่ถูกต้องกรอบข้อความหรือคำขอหลอกลวงเส้นทาง)

หมายถึงกรณีที่ผิดรูปแบบ (ไม่ดี)!

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

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

ข้อสรุป

Rule of thumb: [_] 00 ครอบคลุมกรณีทั่วไปมากที่สุดและกรณีที่ไม่ครอบคลุมโดยรหัสที่กำหนด

422เหมาะกับข้อผิดพลาดในการตรวจสอบความถูกต้องของวัตถุที่ดีที่สุด (คำแนะนำของฉันถูกต้อง :)
สำหรับความหมายที่ผิดพลาด -ลองนึกถึงบางสิ่งเช่นการตรวจสอบ "ชื่อผู้ใช้นี้มีอยู่แล้ว"

400 ใช้อย่างไม่ถูกต้องสำหรับการตรวจสอบความถูกต้องของวัตถุ

— honzajde
แหล่งที่มา

9

ฉันจะบอกว่าในทางเทคนิคมันอาจไม่ใช่ความล้มเหลว HTTP เนื่องจากทรัพยากรถูกระบุอย่างถูกต้องผู้ใช้ถูกรับรองความถูกต้องและไม่มีความล้มเหลวในการปฏิบัติงาน (อย่างไรก็ตามแม้ข้อมูลจำเพาะจะมีรหัสสงวนบางอย่างเช่น 402 อย่าพูดอย่างเคร่งครัดเกี่ยวกับ HTTP แม้ว่าอาจแนะนำให้ใช้ที่ระดับโปรโตคอลเพื่อให้อุปกรณ์ใด ๆ สามารถรับรู้สภาพได้)

หากเป็นกรณีนี้ฉันจะเพิ่มฟิลด์สถานะลงในการตอบกลับด้วยข้อผิดพลาดของแอปพลิเคชันเช่น

<status><code>4</code> <message> ช่วงวันที่ไม่ถูกต้อง </message> </status>

— jspcal
แหล่งที่มา

1

มีข้อมูลเพิ่มเติมเล็กน้อยเกี่ยวกับความหมายของข้อผิดพลาดเหล่านี้ในRFC 2616ซึ่งเป็นเอกสาร HTTP 1.1

โดยส่วนตัวแล้วฉันอาจจะใช้400 Bad Requestแต่นี่เป็นเพียงความเห็นส่วนตัวของฉันโดยไม่มีการสนับสนุนใด ๆ

— Andri
แหล่งที่มา

0

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

หากเป็นกรณีนี้ฉันจะบอกว่า 400 คำขอไม่ถูกต้องอาจเป็นสิ่งที่ถูกต้อง แต่หากไม่ทราบว่าเป็นสิ่งที่คุณ "ตรวจสอบ" ก็เป็นไปไม่ได้ที่จะพูด

— Nicholas Knight
แหล่งที่มา

จะเกิดอะไรขึ้นถ้าเรากำลังพยายามตรวจสอบความถูกต้องทางธุรกิจหรือกฎบางอย่าง

— Metalhead