Czy powinienem tworzyć własne kody stanu HTTP? (a la Twitter 420: Enhance Your Calm)

Obecnie wdrażam API HTTP, mój pierwszy w historii.

Spędziłem dużo czasu, szukając kodów stanu HTTP na stronie Wikipedii, ponieważ jestem zdeterminowany, aby zaimplementować odpowiednie kody dla odpowiednich sytuacji. Na tej stronie znajduje się kod o numerze 420, który jest niestandardowym kodem, którego Twitter używał do ograniczania stawek.

Jest już jednak kod ograniczenia prędkości. To 429.

Doprowadziło mnie to do zastanowienia się, dlaczego mieliby ustawić niestandardowy, skoro istnieje już przypadek użycia. Czy to po prostu urocze? A jeśli tak, to w jakich okolicznościach dopuszczalny byłby zwrot innego kodu stanu, a co, jeśli klienci mogą mieć z tym jakieś problemy?

Czytałem gdzieś, że Mozilla nie implementuje żartu 418: I’m a teapot, co sprawia, że ​​myślę, że klienci wybierają kody statusu, które implementują. Jeśli to prawda, mogę sobie wyobrazić, że śmieszne śmieszne Twittera poprawiają twój spokojny kod, który jest problematyczny.

O ile się nie mylę i możemy nadać dowolnemu numerowi kod dowolny, co nam się podoba, a tylko ta konwencja nakazuje, że 404 oznacza, że ​​nie znaleziono, a 429 oznacza spokojnie.

Cały Internet opiera się na konwencjach. Nazywamy je RFC. Chociaż nikt nie przyjdzie i nie aresztuje Cię, jeśli naruszysz RFC, ryzykujesz, że Twoja usługa nie będzie współpracować z resztą świata. A jeśli tak się stanie, ryzykujesz, że Twój startup nie zdobędzie żadnych klientów, Twoja firma otrzyma złą prasę, akcjonariusze zbuntują się, zostaniesz zwolniony na stałe itp.

Kody stanu HTTP mają swój własny rejestr IANA , każdy z nich jest identyfikowalny z RFC (lub w jednym przypadku z identyfikatorem), który go zdefiniował.

W szczególnym przypadku dziwnego kodu statusu Twittera 420 w porównaniu ze standardowym kodem statusu 429 zdefiniowanym w RFC 6585 , najbardziej prawdopodobnym wyjaśnieniem jest to, że ten ostatni został zdefiniowany dopiero niedawno; RFC pochodzi z kwietnia 2012 r. Widzimy, że Twitter używa tylko 420 w poprzedniej nieaktualnej wersji 1 interfejsu API; obecna wersja API 1.1 faktycznie używa kodu statusu 429 . Jest więc jasne, że Twitter potrzebował do tego kodu statusu i zdefiniował własny; kiedy standard był już dostępny, przełączyli się na niego.

Najlepszą praktyką jest oczywiście jak najściślejsze przestrzeganie standardów. Kiedy czytasz RFC, prawie zawsze znajdziesz takie słowa jak „MUST” i „SHOULD”; mają one określone znaczenie podczas tworzenia aplikacji, które można znaleźć w RFC 2119 .

To pytanie nieco zagłębia się w problem. Ale chodzi o to, że technicznie możesz utworzyć dowolny kod statusu, który chcesz, ale utworzenie kodu statusu poza tradycyjnym zakresem znaczeń kodu statusu sprawia, że ​​interfejs API jest bardziej tępy i tajemniczy dla innych. Chyba że o to chodzi, a interfejs API, który tworzysz, jest tak niesamowity, że wszyscy chętnie zmienią kodowanie, aby podążać za tobą, więc co to w ogóle ma znaczenie, prawda?

Sprowadza się do tego: Każdy standard może zostać złamany. Ale jeśli go złamiesz, co zyskasz lub stracisz, robiąc to?

Ogólnie rzecz biorąc, w przypadkach, w których można zrobić coś innego, ale standardy implikują standardy, najlepiej jest je stosować, chyba że istnieje bardzo silny i przekonujący powód, aby odejść od ustalonych standardów. W przypadku Twittera 420: Enhance Your Calmtworzą kod odpowiedzi, który wyraźnie mówi o wyjątkowej sytuacji, z którą się spotykają. Co spowalnia żądania bez odmowy usługi.