Dois-je créer mes propres codes de statut HTTP? (à la Twitter 420: Améliorez votre calme)

J'implémente actuellement une API HTTP, ma toute première.

J'ai passé beaucoup de temps à regarder la page Wikipedia pour les codes d'état HTTP, car je suis déterminé à mettre en œuvre les bons codes pour les bonnes situations. Sur cette page est répertorié un code avec le numéro 420, qui est un code personnalisé que Twitter utilisait pour limiter le taux.

Cependant, il existe déjà un code pour limiter le débit. C'est 429.

Cela m'a amené à me demander pourquoi ils en définiraient un personnalisé, alors qu'il existe déjà un cas d'utilisation. C'est juste être mignon? Et si c'est le cas, quelles circonstances rendraient acceptable le retour d'un code de statut différent, et qu'en cas de problème, les clients pourraient-ils rencontrer?

J'ai lu quelque part que Mozilla n'implémente pas la 418: I’m a teapotréponse de plaisanterie , ce qui me fait penser que les clients choisissent les codes d'état qu'ils implémentent. Si c'est vrai, alors je peux imaginer que le petit drôle de Twitter améliore votre code calme problématique.

À moins que je ne me trompe, et nous pouvons nous approprier n'importe quel numéro de code pour signifier ce que nous voulons, et cette seule convention dicte que 404 signifie non trouvé, et 429 signifie que c'est facile.

L'ensemble d'Internet est construit sur des conventions. Nous les appelons RFC. Bien que personne ne vienne vous arrêter si vous violez un RFC, vous courez le risque que votre service n'interagisse pas avec le reste du monde. Et si cela se produit, vous courez le risque que votre startup n'obtienne pas de clients, que votre entreprise se fasse mal, que vos actionnaires se révoltent, que vous soyez licencié de façon permanente, etc.

Les codes d'état HTTP ont leur propre registre IANA , chacun pouvant être retracé au RFC (ou dans un cas, à l'ID) qui l'a défini.

Dans le cas particulier de l'étrange code d'état 420 de Twitter par rapport au code d'état standard 429 défini dans la RFC 6585 , l'explication la plus probable est que ce dernier n'a été défini que récemment; la RFC date d'avril 2012. Nous voyons que Twitter n'utilise que 420 dans la version 1 obsolète précédente de son API; l'API actuelle version 1.1 utilise en fait le code d'état 429 . Il est donc clair que Twitter avait besoin d'un code d'état pour cela et a défini le leur; une fois qu'une version standard était disponible, ils y sont passés.

La meilleure pratique, bien sûr, est de rester aussi fidèle que possible aux normes. Lorsque vous lisez les RFC, vous trouverez presque toujours des mots comme "DOIT" et "DEVRAIT"; ceux-ci ont des significations spécifiques lorsque vous créez votre application, que vous pouvez trouver dans la RFC 2119 .

Cette question approfondit un peu le problème. Mais le fait est que, bien que vous puissiez techniquement créer le code d'état que vous voulez, la création d'un code d'état en dehors de la portée traditionnelle des significations de code d'état ne fait que rendre votre API plus obtuse et mystérieuse pour les autres. À moins que ce ne soit le cas, et l'API que vous créez est tellement incroyable que tout le monde sera ravi de changer son codage pour suivre votre exemple, alors qu'importe de toute façon, non?

Cela se résume à ceci: toute norme peut être brisée. Mais si vous le cassez, qu'est-ce que vous gagnez ou perdez en le faisant?

En général, dans les cas où vous pouvez faire quelque chose de différent mais les normes impliquent des normes, il est préférable de respecter les normes, sauf s'il existe une raison très forte et impérieuse de s'écarter des normes établies. Dans le cas de Twitter, 420: Enhance Your Calmils créent un code de réponse qui parle clairement d'une situation unique à laquelle ils sont confrontés. Ce qui ralentit les demandes sans refuser le service.