รหัสสถานะ HTTP ที่แนะนำสำหรับการตอบสนอง“ เกินขีด จำกัด แผน”

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

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

ผู้สมัครคือ IMHO:

• 403 Forbidden - อย่างไรก็ตามฉันต้องการแยกความแตกต่างระหว่างกรณีนี้และกรณีอื่น ๆ ที่ผู้ใช้ขาดสิทธิ์ในการดำเนินการนี้

• 401 Unauthorized - ไม่ใช่ความคิดที่ดีเราใช้มันเพื่อตรวจสอบปัญหาที่เกี่ยวข้อง

• 402 Payment Required - ทำให้รู้สึก แต่ฉันกังวลเกี่ยวกับการใช้รหัสสถานะที่ไม่ได้มาตรฐาน แต่สงวนไว้

• บางสิ่งที่เป็นมาตรฐานน้อยลงอย่าง423 Lockedที่ไม่น่าเป็นไปได้เราจะใช้มันเพื่อสิ่งอื่นในอนาคต

ตัวเลือกอื่นคือไปกับสิ่งที่มาตรฐานมากเช่น403แต่ระบุเฉพาะข้อผิดพลาดในเนื้อหาการตอบสนอง

ฉันสงสัยว่าวิธีการใดที่คุณเชื่อว่า (ก) จะทำงานได้ดีที่สุดในระยะยาวและ (ข) จะยึดมั่นในหลักการสงบมากขึ้น

ฉันคิดว่า 403 เป็นการตอบสนองที่สมเหตุสมผลเพียงอย่างเดียวแม้ว่า 405 Method Not Allowed หรือ 409 Conflict อาจเป็นที่ยอมรับ แต่ฉันไม่คิดว่าจะดีเท่า 403 ซึ่งระบุว่า:

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

หากคุณส่งคืนข้อผิดพลาด 403 ข้อมูลนั้นจะรวมถึงข้อมูลบางอย่างเกี่ยวกับสาเหตุที่ทรัพยากรถูกปฏิเสธ - การอนุญาตที่ไม่ถูกต้องเป็นเพียงกรณีที่พบบ่อยที่สุดเกินขีด จำกัด ไม่แตกต่างกันมาก - คุณไม่มีสิทธิ์เนื่องจากเกินขีด จำกัด ของคุณ

ฉันเชื่อว่า 403 ผิดเพราะ 403 สำหรับสถานการณ์ที่คุณไม่ได้รับการเข้าถึงทรัพยากรและไม่มีวิธีใด ๆ ในการเข้าถึง สำหรับลูกค้าของคุณมีวิธีการเข้าถึงที่ชัดเจน: ชำระเงิน

401 เป็นสิ่งที่ผิดอย่างแท้จริงเพราะไม่เพียง แต่คุณจะใช้มันเพื่อการตรวจสอบความถูกต้อง แต่นั่นคือสิ่งที่มันมีอยู่

เนื่องจากคุณกำลังเขียน API ฉันถือว่าผู้อื่นจะต้องเขียนโค้ดที่ใช้ API และบุคคลนั้นจำเป็นต้องอ่านข้อมูลจำเพาะ API ของคุณ คุณอาจไปกับ 429 "คำขอมากเกินไป" โดยปกติจะมีจุดประสงค์เพื่อ จำกัด อัตรา (ซึ่งลูกค้าสามารถทำการร้องขอได้ 100 ครั้งต่อวัน) แต่ใช้กับสถานการณ์ของคุณอย่างสมเหตุสมผล ฉันคิดว่า 402 (ต้องชำระเงิน) ขึ้นอยู่กับเครื่องมือที่คุณคาดหวังให้ผู้คนใช้ในการใช้ API ของคุณ 429 มีความเสี่ยงที่เครื่องมือที่ชาญฉลาดจะพยายามส่งคำขอน้อยลงต่อนาที / ชั่วโมง / วันและไม่ประสบความสำเร็จ

BTW ตามhttps://tools.ietf.org/html/rfc6585ข้อผิดพลาด 429 ควรมีข้อความ html ที่อธิบายลักษณะของปัญหาดังนั้นจึงมีโอกาสดีที่ผู้ใช้จะได้รับการแจ้งว่าปัญหาคืออะไรถ้าคุณให้ ข้อมูลนั้นในการตอบกลับของคุณ

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