รหัสการตอบกลับ REST สำหรับข้อมูลที่ไม่ถูกต้อง

272

ควรส่งรหัสตอบสนองอะไรให้กับลูกค้าในกรณีที่เกิดสถานการณ์ต่อไปนี้

ข้อมูลที่ส่งผ่านไม่ถูกต้องขณะลงทะเบียนผู้ใช้เช่นรูปแบบอีเมลที่ไม่ถูกต้อง
ชื่อผู้ใช้ / อีเมลนี้มีอยู่แล้ว

ฉันเลือก 403 ฉันยังพบว่าฉันรู้สึกว่าสามารถใช้งานได้

วิกิพีเดีย:

412 เงื่อนไขเบื้องต้นล้มเหลว: เซิร์ฟเวอร์ไม่เป็นไปตามเงื่อนไขข้อใดข้อหนึ่งที่ผู้ร้องขอร้องขอ

แนะนำรหัสถ้าฉันควรใช้นอกเหนือจาก 403

http rest jax-rs

— Amit Patel
แหล่งที่มา

ซ้ำซ้อนที่เป็นไปได้: stackoverflow.com/questions/3050518/…

— Genjo

ฉันกำลังแก้ไขปัญหานี้เช่นกัน บทที่ 7. การตรวจสอบความถูกต้องของข้อมูลจำเพาะ JAX-RS (2017) ให้คำแนะนำรหัสสถานะโดยเฉพาะสำหรับการละเมิดข้อ จำกัด download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-spec/…

— burntsugar

298

400 เป็นตัวเลือกที่ดีที่สุดในทั้งสองกรณี หากคุณต้องการชี้แจงข้อผิดพลาดเพิ่มเติมคุณสามารถเปลี่ยนเหตุผลวลีหรือรวมเนื้อหาเพื่ออธิบายข้อผิดพลาด

412 - เงื่อนไขเบื้องต้นล้มเหลวใช้สำหรับคำขอที่มีเงื่อนไขเมื่อใช้วันที่แก้ไขล่าสุดและ ETags

403 - ห้ามใช้เมื่อเซิร์ฟเวอร์ต้องการป้องกันการเข้าถึงทรัพยากร

ตัวเลือกอื่น ๆ เท่านั้นที่เป็นไปได้คือ 422 - เอนทิตีที่ไม่สามารถประมวลผลได้

— Darrel Miller
แหล่งที่มา

10

ในขณะที่มันมักจะใช้ในบริบทนี้ 403 ไม่ จำกัด เฉพาะการควบคุม acces เนื่องจาก rfc2616-10.4.4 พูดว่า: "เซิร์ฟเวอร์เข้าใจคำขอ แต่ไม่ยอมทำตาม [... ] หากเซิร์ฟเวอร์ต้องการทำ สาธารณะว่าทำไมคำขอไม่ได้รับการตอบสนองมันควรอธิบายเหตุผลของการปฏิเสธในองค์กร " เหตุผลอาจเป็นข้อมูลที่ไม่ถูกต้อง อย่างไรก็ตาม 422 สามารถใช้งานได้มากขึ้นที่นี่

— Yannick Loiseau

7

อย่าไปจมอยู่กับการวิจารณ์เชิงข้อความ ดูตัวอย่างtrac.tools.ietf.org/wg/httpbis/trac/ticket/294ซึ่งพยายามชี้แจงว่า 403 เป็นและอยู่เสมอเกี่ยวกับการอนุญาต

— fumanchu

2

@ fumanchu จับได้ดี เชื่อมโยงไปยังขอเปลี่ยนที่มีเพียง 7 ชั่วโมงเก่า :-)

— Darrel มิลเลอร์

1

@fumanchu หมายความว่า 403 ควรกลับมาในกรณีที่ผู้ใช้ไม่ได้รับอนุญาตให้เข้าถึงทรัพยากรที่ร้องขอ แต่ฉันคิดว่า 401 Unauthorized เหมาะสมกว่าการเข้าถึงทรัพยากรที่ผู้ใช้ไม่ได้รับอนุญาต

— Amit Patel

1

401 ไม่ได้รับอนุญาตจะแจ้งให้เว็บเบราเซอร์แสดงพร้อมท์ชื่อผู้ใช้ / รหัสผ่าน HTTP มาตรฐานให้ผู้ใช้ หากคุณไม่ได้ใช้การตรวจสอบความถูกต้องแบบนั้นสำหรับบริการของคุณหรือหากผู้ใช้มีการตรวจสอบสิทธิ์ HTTP อยู่แล้ว 401 จะไม่เหมาะสม

— Greg Ball

92

ฉันอยากจะแนะนำ 422 มันไม่ได้เป็นส่วนหนึ่งของข้อมูลจำเพาะ HTTP หลัก แต่ถูกกำหนดโดยมาตรฐานสาธารณะ (WebDAV) และควรได้รับการปฏิบัติโดยเบราว์เซอร์เช่นเดียวกับรหัสสถานะ 4xx อื่น ๆ

จากRFC 4918 :

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

— ไมค์เด็ค
แหล่งที่มา

20

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

— Matty K

87

หากการแยกวิเคราะห์คำขอไม่ถูกต้อง (รวมถึงเอนทิตีคำขอ / เนื้อหา) การตอบสนองที่เหมาะสมคือ400คำขอไม่ถูกต้อง[ 1 ]

RFC 4918ระบุว่า422 เอนทิตีที่ไม่สามารถประมวลผลได้มีผลบังคับใช้เมื่อเอนทิตีคำขอมีรูปแบบที่ดี แต่มีความผิดพลาดทางความหมาย ดังนั้นหากเอนทิตีคำขอถูกอ่านไม่ออก (เช่นรูปแบบอีเมลที่ไม่ดี) ให้ใช้ 400; แต่ถ้ามันไม่สมเหตุสมผล (เช่น@example.com) ให้ใช้ 422

หากปัญหาคือว่ามีชื่อผู้ใช้ / อีเมลอยู่แล้วคุณสามารถใช้409 Conflict [ 2 ] พร้อมคำอธิบายความขัดแย้งและคำแนะนำเกี่ยวกับวิธีแก้ไข (ในกรณีนี้ "ให้เลือก ชื่อผู้ใช้ / อีเมลอื่น ") อย่างไรก็ตามในสเป็คตามที่เขียน403 Forbidden [ 3 ] ยังสามารถใช้ในกรณีนี้ข้อโต้แย้งเกี่ยวกับการอนุญาต HTTP แม้จะมี

412 Precondition Failed [ 4 ] ถูกใช้เมื่อส่วนหัวของคำขอการร้องขอล่วงหน้า (เช่นIf-Match) ที่ไคลเอ็นต์กำหนดให้เป็นเท็จ นั่นคือลูกค้าขออะไรบางอย่างและให้เงื่อนไขเบื้องต้นโดยรู้ดีว่าเงื่อนไขเหล่านั้นอาจล้มเหลว 412 ไม่ควรที่จะผุดบนไคลเอนต์ออกจากสีฟ้าและไม่ควรจะเกี่ยวข้องกับการร้องขอกิจการต่อ se

— Matty K
แหล่งที่มา

1

ฉันควรทราบการปรับปรุง HTTP / 1.1 RFCs: 400 ร้องขอไม่ถูกต้อง 409 ความขัดแย้ง 403 Forbidden ฯลฯ อาศัยอยู่ในtools.ietf.org/html/rfc7231 ; 412 Precondition Failed อยู่ในtools.ietf.org/html/rfc7232#section-4.2

— Matty K

41

มันสนุกที่จะกลับ418 I'm a teapotไปที่คำขอที่สร้างขึ้นมาอย่างชัดเจนหรือเป็นอันตรายและ "ไม่สามารถเกิดขึ้นได้" เช่นการตรวจสอบ CSRF ที่ล้มเหลวหรือคุณสมบัติการร้องขอที่ขาดหายไป

2.3.2 418 ฉันเป็นกาน้ำชา

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

เพื่อให้เป็นเรื่องที่สมเหตุสมผลฉันจึง จำกัด การใช้รหัสข้อผิดพลาดตลกไว้ที่ RESTful endpoint ที่ไม่ได้สัมผัสกับผู้ใช้โดยตรง

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

11

ใช้มันดังกล่าวว่าผลตอบแทน API ของคุณ418 I'm a teapotสำหรับการร้องขอทั้งหมดมาจากเจ้านายของคุณ :)

— vikarjramun

2

@vikarjramun ฉันได้สร้าง DEST REST แล้วและทำตัวสุขุมอย่างหนึ่งแบบออฟไลน์ (ก่อนวางจำหน่าย) ตอนนี้นักเรียนของเรากำลังค้นหาพยายามสร้างคำขอข้อมูลที่ถูกต้อง แต่เป็นกาน้ำชาทั้งหมด ฉันเป็น "หัวหน้า" - แต่ก็ทำงานด้วยเหมือนกัน

— LenglBoy

2

RFC นี้เป็นใบ้ คุณสามารถชงกาแฟในหม้อชาตราบใดที่คุณเทเครื่องกรองชาลงในถ้วย เช่นเดียวกับการใช้ชาใบหลวม คุณสามารถชงชาในร้านกาแฟโดยไม่มีปัญหา

— gburton

2

@gburton นั้นต้องอาศัยการแทรกแซงจากมนุษย์ ผ่านเครือข่ายคุณต้องมีอุปกรณ์ที่สามารถใช้ทำกาแฟได้อย่างแน่นอน แน่นอนกาแฟและกาน้ำชาไม่ควรตอบสนองกับ 418

— แจสเปอร์