ฉันควรใช้รหัสตอบกลับสถานะ HTTP ใดหากคำขอไม่มีพารามิเตอร์ที่ต้องการ

ฉันคิดว่า 412 (เงื่อนไขเบื้องต้นล้มเหลว) แต่อาจมีมาตรฐานที่ดีกว่า

สถานะ 422 ดูเหมือนว่าเหมาะสมที่สุดขึ้นอยู่กับสเปค

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

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

UPDATE @DavidV ชี้ให้เห็นอย่างถูกต้องว่าข้อมูลจำเพาะนี้มีไว้สำหรับ WebDAV ไม่ใช่ core HTTP แต่บางอย่างที่ไม่ใช่ WebDAV APIs ยอดนิยมนั้นใช้ 422 อยู่ดีเพราะไม่มีรหัสสถานะที่ดีกว่านี้ ( ดูที่นี่ )

ฉันไม่แน่ใจว่ามีมาตรฐานที่กำหนดไว้ แต่ฉันจะใช้400 คำขอไม่ถูกต้องซึ่งข้อกำหนด HTTP ล่าสุด (จากปี 2014) เอกสารดังต่อไปนี้ :

6.5.1 400 คำขอไม่ถูกต้อง

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

WCF APIในการจับ .NET พารามิเตอร์โดยกลับหายไปHTTP 404"ปลายทางไม่พบข้อผิดพลาด" เมื่อใช้webHttpBinding

404 Not Foundสามารถทำให้ความรู้สึกถ้าคุณพิจารณาชื่อวิธีการบริการเว็บของคุณพร้อมกับลายเซ็นของพารามิเตอร์ นั่นคือถ้าคุณเปิดเผยวิธีการให้บริการเว็บLoginUser(string, string)และคุณร้องขอLoginUser(string)ไม่พบวิธีหลัง

โดยทั่วไปสิ่งนี้จะหมายความว่าไม่พบวิธีการบริการเว็บที่คุณโทรพร้อมกับลายเซ็นพารามิเตอร์ที่คุณระบุ

10.4.5 404 ไม่พบ

เซิร์ฟเวอร์ไม่พบสิ่งใดที่ตรงกับ Request-URI ไม่มีการบ่งชี้ว่าเงื่อนไขเป็นแบบชั่วคราวหรือถาวร

400 Bad Requestเป็นเกิร์ตที่แนะนำยังคงเป็นรหัสการตอบสนองที่ถูกต้อง แต่ฉันคิดว่ามันถูกนำมาใช้ตามปกติเพื่อบ่งบอกถึงปัญหาในระดับต่ำกว่า สามารถตีความได้อย่างง่ายดายว่าเป็นคำขอ HTTP ที่มีรูปแบบไม่ถูกต้องอาจขาดหายไปหรือส่วนหัว HTTP ที่ไม่ถูกต้องหรือคล้ายกัน

10.4.1 400 คำขอไม่ถูกต้อง

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

คุณสามารถส่งรหัสขอได้ 400 รหัส เป็นหนึ่งในรหัสสถานะ 4xx ที่เป็นวัตถุประสงค์ทั่วไปดังนั้นคุณสามารถใช้เพื่อหมายถึงสิ่งที่คุณต้องการ: ลูกค้ากำลังส่งคำขอที่ไม่มีข้อมูล / พารามิเตอร์ที่แอปพลิเคชันของคุณต้องการเพื่อดำเนินการอย่างถูกต้อง

ในหนึ่งในโครงการ API ของเราเราตัดสินใจที่จะตั้งสถานะ 409 เป็นคำขอบางอย่างเมื่อเราไม่สามารถเติมเต็มได้ที่ 100% เนื่องจากพารามิเตอร์ที่ขาดหายไป

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

การอ้างอิง: w3.org/Protocols/

ดังนั้นในการตอบสนองอื่น ๆ เช่น 400 หรือ 404 เราเลือก 409 เพื่อบังคับใช้ความต้องการในการดูบันทึกย่อในคำขอที่เป็นประโยชน์ในการตั้งค่าคำขอใหม่และถูกต้อง

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

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

ฉันมักจะไป 422 (เอนทิตีที่ไม่สามารถประมวลผลได้) ถ้าสิ่งที่อยู่ในพารามิเตอร์ที่ต้องการไม่ตรงกับที่จุดสิ้นสุด API ต้องการ (เช่นรหัสผ่านสั้นเกินไป) แต่สำหรับพารามิเตอร์ที่ขาดหายไปฉันจะไป 406 (ยอมรับไม่ได้)

สำหรับผู้ที่สนใจ Spring MVC (3.x อย่างน้อย) จะคืนค่า 400 ในกรณีนี้ซึ่งดูเหมือนว่าผิดสำหรับฉัน

ฉันทดสอบ URL ของ Google หลายอัน (accounts.google.com) และลบพารามิเตอร์ที่จำเป็นออกและโดยทั่วไปแล้วพวกเขาจะคืนค่า 404 ในกรณีนี้

ฉันจะคัดลอก Google

เป็นที่ถกเถียงกันอยู่ว่า404 Not Foundควรใช้a เนื่องจากไม่พบทรัพยากรที่ระบุ

ฉันมักจะใช้ข้อผิดพลาดที่ต้องห้าม 403 เหตุผลก็คือคำขอนั้นเข้าใจ แต่ฉันจะไม่ทำตามที่ถาม (เพราะมีสิ่งผิดปกติ) เอนทิตีการตอบสนองอธิบายสิ่งที่ผิดดังนั้นหากการตอบสนองเป็นหน้า HTML ข้อความแสดงข้อผิดพลาดจะอยู่ในหน้านั้น หากเป็นการตอบสนอง JSON หรือ XML ข้อมูลข้อผิดพลาดจะอยู่ในนั้น

จากrfc2616 :

10.4.4 403 สิ่งต้องห้าม

เซิร์ฟเวอร์เข้าใจคำขอ แต่ปฏิเสธที่จะปฏิบัติตาม
การอนุญาตจะไม่ช่วยและคำขอจะไม่ถูกทำซ้ำ
หากวิธีการร้องขอไม่ได้เป็น HEAD และเซิร์ฟเวอร์ประสงค์ที่จะ
เปิดเผยต่อสาธารณะว่าทำไมคำขอไม่ได้รับการตอบสนองก็ควรอธิบายเหตุผลของการปฏิเสธในเอนทิตี หากเซิร์ฟเวอร์ไม่ต้องการให้ข้อมูลนี้พร้อมใช้งานสำหรับลูกค้าสามารถใช้รหัสสถานะ 404
(ไม่พบ) แทน

เพียงแค่ใช้ ASP.NET Core เป็นข้อมูลอ้างอิงหรือเป็นตัวอย่าง ASP.NET Core ช่วยให้คุณสามารถควบคุมตัวควบคุมพร้อมการกระทำได้นี่คือลักษณะการทำงานของ "รายละเอียด"

    // GET: Cars/Details/5
    public async Task<IActionResult> Details(int? id)
    {
        if (id == null)
        {
            return NotFound();
        }

        var car = await _context.Cars.FirstOrDefaultAsync(m => m.CarId == id);
        if (car == null)
        {
            return NotFound();
        }

        return View(car);
    }

หากidไม่ได้ตั้งค่าพารามิเตอร์ไว้จะส่งคืน 404 Not Found

ส่งคืน 404 - ซึ่งหมายความว่าไม่พบทรัพยากร

ลองแก้ไข URL ของเว็บไซต์ที่มีรหัส ฉันพยายามไม่กี่:

• ปัญหา repo gitub
• หน้าบรรจบ
• มุมมองผลิตภัณฑ์ amazon
• รายชื่ออีเบย์
• บทความข่าวบีบีซี

ผลตอบแทนทั้งหมด 404 นั้นเป็นเพราะนักพัฒนาเหล่านั้นตีความมาตรฐานอย่างถูกต้องซึ่งคำตอบที่นี่และอื่น ๆ อีกมากมายนั้นไม่ใช่!

ฉันจะไปกับ 403

จากRFC 2616 - Hypertext Transfer Protocol - HTTP / 1.1

403 ต้องห้าม

เซิร์ฟเวอร์เข้าใจคำขอ แต่ปฏิเสธที่จะปฏิบัติตาม การอนุญาตจะไม่ช่วยและคำขอจะไม่ถูกทำซ้ำ หากวิธีการร้องขอไม่ได้เป็น HEAD และเซิร์ฟเวอร์ประสงค์ที่จะเปิดเผยต่อสาธารณะว่าทำไมคำขอไม่ได้รับการตอบสนองก็ควรอธิบายเหตุผลของการปฏิเสธในเอนทิตี หากเซิร์ฟเวอร์ไม่ต้องการให้ข้อมูลนี้พร้อมใช้งานสำหรับลูกค้าสามารถใช้รหัสสถานะ 404 (ไม่พบ) แทน

คุณควรอธิบายถึงสาเหตุของความล้มเหลวในการตอบสนองของคุณ หากคุณไม่ต้องการทำเพียงแค่ใช้ 404