Kendi HTTP durum kodlarımı oluşturmalı mıyım? (bir Twitter 420: Sakin Olun)

Şu anda ilk defa bir HTTP API uyguluyorum.

HTTP durum kodları için Wikipedia sayfasına bakarak çok zaman harcıyorum çünkü doğru durumlar için doğru kodları uygulamaya kararlıyım. Bu sayfada listelenen 420 numaralı bir koddur ve Twitter'ın hız sınırlaması için kullandığı özel bir koddur.

Yine de, oran sınırlaması için bir kod zaten var. 429.

Bu, zaten bir kullanım vakası varken neden özel bir tane koyacaklarını merak etmemi sağladı. Bu sadece sevimli olmak mı? Ve eğer öyleyse, o zaman hangi koşullar farklı bir durum kodu döndürmeyi kabul edilebilir kılacaktır, ve eğer müşterilerin bununla ilgili herhangi bir sorunu olabilirse?

Mozilla'nın şaka 418: I’m a teapotyanıtını uygulamadığı bir yere okudum , bu da müşterilerin hangi durum kodlarını uyguladıklarını seçtiklerini düşünüyor. Eğer bu doğruysa, Twitter’ın komik küçük kodunun sakin kodunuzu problemli hale getirdiğini düşünebiliyorum.

Yanılmıyorsam ve ne istersen onu ifade etmek için herhangi bir kod numarası uygun olabiliriz ve bu sadece 404'ün bulunmadığı anlamına gelir ve 429 bunu kolaylaştırır.

İnternetin tamamı sözleşmeler üzerine kuruludur. Onlara RFC diyoruz. Bir RFC'yi ihlal ederseniz kimse sizi tutuklamayacak ve sizi tutuklayamazken, hizmetinizin dünyanın geri kalanıyla birlikte çalışmama riskini taşıyorsunuz. Ve eğer bu gerçekleşirse, herhangi bir müşteriye ulaşmama, işinizin kötü baskı yapması, hissedarlarınızın isyan etmesi, kalıcı olarak işten çıkarılma vs.

HTTP durum kodları , her biri onu tanımlayan RFC'ye (veya bir durumda kimliğine) geri izlenebilir olan kendi IANA kayıt defterlerine sahiptir .

Twitter'ın tuhaf 420 durum kodu ile RFC 6585'de tanımlanan standart 429 durum koduna karşı belirli bir durumda , en muhtemel açıklama, ikincisinin daha yeni tanımlandığı; RFC Nisan 2012'ye kadar uzanıyor. Twitter’ın API’sinin önceki 1 sürümünde yalnızca 420’yi kullandığını görüyoruz ; Geçerli API sürüm 1.1 aslında 429 durum kodunu kullanır . Yani Twitter'ın bunun için bir durum koduna ihtiyaç duyduğu ve kendi tanımını yaptığı açıktır; Standart bir tane mevcut olduğunda, ona geçtiler.

Elbette, en iyi uygulama, standartlara mümkün olduğunca yakından bağlı kalmaktır. RFC'leri okuduğunuzda, neredeyse her zaman "MUST" ve "SHOULD"; RFC 2119'da bulabileceğiniz, uygulamanızı oluştururken bunun özel anlamları vardır .

Bu soru konuya biraz girer. Fakat mesele şu ki, teknik olarak istediğiniz herhangi bir durum kodunu oluşturabilirsiniz, geleneksel durum kodu anlamının dışında bir durum kodu oluşturmak, API'nizi yalnızca diğerlerine karşı daha hassas ve gizli hale getirir. Mesele bu olmadığı sürece ve yarattığınız API o kadar şaşırtıcı ki, herkes liderliğini takip etmek için kodlamalarını memnuniyetle değiştirecek, peki ne önemi var ki?

Bu aşağı kaynar: Herhangi bir standart kırılabilir. Ama eğer onu kırarsan ne yaparak kazanırsın ya da kaybedersin?

Genel olarak, farklı bir şey yapabileceğiniz durumlarda ancak standartların standartlara uyduğu durumlarda, yerleşik standartlardan uzak durmak için çok güçlü ve zorlayıcı bir neden olmadıkça standartlara uymak en iyisidir. Twitter durumunda, 420: Enhance Your Calmkarşılaştıkları benzersiz bir durumla açıkça konuşabilen bir yanıt kodu yaratıyorlar. Bu hizmet reddetmeden istekleri yavaşlatıyor.