ฉันควรสร้างรหัสสถานะ HTTP ของตัวเองหรือไม่ (a Twitter Twitter 420: Enhance Calm Your)

ฉันกำลังใช้ HTTP API เป็นครั้งแรก

ฉันใช้เวลาไปกับการดูหน้า Wikipedia สำหรับรหัสสถานะ HTTP เพราะฉันมุ่งมั่นที่จะใช้รหัสที่ถูกต้องสำหรับสถานการณ์ที่เหมาะสม รายชื่อในหน้านั้นเป็นรหัสที่มีหมายเลข 420 ซึ่งเป็นรหัสที่กำหนดเองซึ่ง Twitter ใช้เพื่อ จำกัด อัตรา

มีรหัสสำหรับการ จำกัด อัตราอยู่แล้ว มันคือ 429

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

ฉันอ่านที่ไหนสักแห่งที่ Mozilla ไม่ได้ใช้การ418: I’m a teapotตอบสนองตลกซึ่งทำให้ฉันคิดว่าลูกค้าเลือกรหัสสถานะที่พวกเขาใช้ ถ้านั่นเป็นเรื่องจริงฉันก็นึกภาพเล็ก ๆ น้อย ๆ ของ Twitter ที่ทำให้รหัสสงบของคุณเป็นปัญหา

นอกจากว่าฉันเข้าใจผิดและเราสามารถใส่หมายเลขรหัสใดก็ได้เพื่อหมายถึงสิ่งที่เราชอบและมีเพียงการประชุมที่บอกว่าไม่พบ 404 หมายถึงและ 429 หมายถึงง่าย

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

รหัสสถานะ HTTP มีรีจิสตรี IANA ของตัวเองแต่ละคนสามารถติดตามกลับไปที่ RFC (หรือในกรณีเดียว ID) ที่กำหนดไว้

ในกรณีเฉพาะของรหัสสถานะ 420 ของ Twitter ที่แปลกเมื่อเทียบกับรหัสสถานะ 429 มาตรฐานที่กำหนดในRFC 6585คำอธิบายที่เป็นไปได้มากที่สุดก็คือ RFC วันที่ถึงเมษายน 2012 เราเห็นว่า Twitter ใช้ 420 ใน API รุ่นที่คัดค้านก่อนหน้า 1ของ API เท่านั้น รุ่นปัจจุบัน 1.1 API จริงใช้รหัส ดังนั้นชัดเจนว่า Twitter ต้องการรหัสสถานะสำหรับสิ่งนี้และกำหนดรหัสของตัวเอง เมื่อมีมาตรฐานก็พร้อมใช้งานพวกเขาเปลี่ยนไป

แน่นอนการปฏิบัติที่ดีที่สุดคือการยึดติดกับมาตรฐานให้มากที่สุด เมื่อคุณอ่าน RFCs คุณจะพบคำเช่น "MUST" และ "SHOULD" เกือบทุกครั้ง เหล่านี้มีความหมายเฉพาะเมื่อคุณกำลังสร้างแอพลิเคชันของคุณซึ่งคุณจะพบในRFC 2119

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

มันลดลงมาถึงสิ่งนี้: มาตรฐานใด ๆ ที่สามารถทำลายได้ แต่ถ้าคุณทำลายมันคุณจะได้รับหรือสูญเสียอะไรในการทำเช่นนั้น?

โดยทั่วไปในกรณีที่คุณสามารถทำสิ่งที่แตกต่าง แต่มาตรฐานบ่งบอกถึงมาตรฐานที่ดีที่สุดคือการยึดมั่นในมาตรฐานเว้นแต่มีเหตุผลที่แข็งแกร่งและน่าสนใจมากที่จะแยกออกจากมาตรฐานที่กำหนดไว้ ในกรณีของ Twitter 420: Enhance Your Calmพวกเขากำลังสร้างรหัสการตอบสนองที่พูดถึงสถานการณ์ที่ไม่ซ้ำกันอย่างชัดเจน ซึ่งทำให้คำขอช้าลงโดยไม่ปฏิเสธบริการ