Soll ich meine eigenen HTTP-Statuscodes erstellen? (a la Twitter 420: Verbessere deine Ruhe)

Ich implementiere derzeit eine HTTP-API, meine allererste.

Ich habe viel Zeit damit verbracht, auf der Wikipedia-Seite nach HTTP-Statuscodes zu suchen, da ich fest entschlossen bin, die richtigen Codes für die richtigen Situationen zu implementieren. Auf dieser Seite ist ein Code mit der Nummer 420 aufgeführt. Hierbei handelt es sich um einen benutzerdefinierten Code, den Twitter zur Begrenzung der Rate verwendet hat.

Es gibt jedoch bereits einen Code für die Ratenbegrenzung. Es ist 429.

Dies führte mich zu der Frage, warum sie ein benutzerdefiniertes festlegen würden, wenn es bereits einen Anwendungsfall gibt. Ist das nur süß? Und wenn ja, unter welchen Umständen ist es akzeptabel, einen anderen Statuscode zurückzugeben, und was ist, wenn Kunden Probleme damit haben?

Ich habe irgendwo gelesen, dass Mozilla die Scherzantwort nicht implementiert 418: I’m a teapot, was mich glauben lässt, dass Kunden auswählen, welche Statuscodes sie implementieren. Wenn das stimmt, kann ich mir vorstellen, dass Twitters lustige kleine Verbesserung Ihres Ruhecodes problematisch ist.

Es sei denn, ich täusche mich, und wir können jede beliebige Codenummer so verwenden, dass sie bedeutet, was wir wollen, und dass nur die Konvention vorschreibt, dass 404 nicht gefunden bedeutet, und 429 bedeutet, dass Sie es ruhig angehen.

Das gesamte Internet basiert auf Konventionen. Wir nennen sie RFCs. Wenn Sie gegen einen RFC verstoßen, wird Sie zwar niemand verhaften, aber Sie laufen Gefahr, dass Ihr Service nicht mit dem Rest der Welt interoperiert. Und in diesem Fall laufen Sie Gefahr, dass Ihr Startup keine Kunden mehr bekommt, Ihr Unternehmen schlecht drückt, Ihre Aktionäre sich auflehnen, dauerhaft entlassen werden usw.

HTTP-Statuscodes haben eine eigene IANA-Registrierung , die jeweils auf den RFC (oder in einem Fall auf die ID) zurückgeführt werden kann, der sie definiert hat.

Im besonderen Fall des seltsamen 420-Statuscodes von Twitter gegenüber dem in RFC 6585 definierten Standard-429-Statuscode ist die wahrscheinlichste Erklärung, dass letzterer erst kürzlich definiert wurde. Die RFC-Daten stammen aus dem April 2012. Wir sehen, dass Twitter in der vorherigen veralteten Version 1 seiner API nur 420 verwendet . Die aktuelle API-Version 1.1 verwendet tatsächlich den Statuscode 429 . Es ist also klar, dass Twitter hierfür einen Statuscode benötigte und einen eigenen definierte. Sobald ein Standard verfügbar war, wechselten sie zu ihm.

Best Practice ist natürlich, sich so genau wie möglich an die Standards zu halten. Wenn Sie RFCs lesen, werden Sie fast immer Wörter wie "MUST" und "SHOULD" finden. Diese haben bestimmte Bedeutungen, wenn Sie Ihre Anwendung erstellen. Diese finden Sie in RFC 2119 .

Diese Frage beschäftigt sich ein wenig mit dem Thema. Die Sache ist jedoch, dass Sie zwar technisch jeden gewünschten Statuscode erstellen können, das Erstellen eines Statuscodes außerhalb des herkömmlichen Bereichs der Statuscodebedeutungen jedoch Ihre API für andere nur stumpfer und geheimnisvoller macht. Es sei denn, das ist der Punkt, und die API, die Sie erstellen, ist so unglaublich, dass jeder gerne seine Codierung ändert, um Ihrem Beispiel zu folgen. Was ist also überhaupt wichtig, oder?

Es läuft darauf hinaus: Jeder Standard kann gebrochen werden. Aber wenn Sie es brechen, was gewinnen oder verlieren Sie dadurch?

Im Allgemeinen ist es in Fällen, in denen Sie etwas anderes tun können, aber die Standards Standards implizieren, am besten, sich an die Standards zu halten, es sei denn, es gibt einen sehr starken und zwingenden Grund, von etablierten Standards abzuweichen. Bei Twitter 420: Enhance Your Calmerstellen sie einen Antwortcode, der eindeutig auf eine besondere Situation hinweist, mit der sie konfrontiert sind. Dadurch werden Anforderungen verlangsamt, ohne den Dienst zu verweigern.