¿Debo inventar mis propios códigos de estado HTTP? (a la Twitter 420: Mejora tu calma)

Actualmente estoy implementando una API HTTP, mi primera vez.

He pasado mucho tiempo buscando códigos de estado HTTP en la página de Wikipedia, porque estoy decidido a implementar los códigos correctos para las situaciones correctas. En esa página aparece un código con el número 420, que es un código personalizado que Twitter solía usar para limitar la velocidad.

Sin embargo, ya existe un código para limitar la velocidad. Son las 429.

Esto me llevó a preguntarme por qué establecerían uno personalizado, cuando ya existe un caso de uso. ¿Eso es solo ser lindo? Y si es así, ¿qué circunstancias harían aceptable devolver un código de estado diferente y qué, si algún problema pueden tener los clientes con él?

Leí en alguna parte que Mozilla no implementa la 418: I’m a teapotrespuesta de broma , lo que me hace pensar que los clientes eligen qué códigos de estado implementan. Si eso es cierto, entonces puedo imaginar que la pequeña mejora de Twitter es problemática.

A menos que me equivoque, y podamos apropiarnos de cualquier número de código para que signifique lo que queramos, y esa única convención dicta que 404 significa no encontrado, y 429 significa que sea fácil.

Toda Internet está construida sobre convenciones. Los llamamos RFC. Si bien nadie vendrá y lo arrestará si viola un RFC, corre el riesgo de que su servicio no interopere con el resto del mundo. Y si eso sucede, corre el riesgo de que su startup no obtenga ningún cliente, que su negocio tenga mala prensa, que sus accionistas se rebelen, que lo despidan permanentemente, etc.

Los códigos de estado HTTP tienen su propio registro de IANA , cada uno de los cuales puede rastrearse hasta el RFC (o en un caso, ID) que lo definió.

En el caso particular del extraño código de estado 420 de Twitter versus el código de estado estándar 429 definido en RFC 6585 , la explicación más probable es que este último se definió recientemente; el RFC data de abril de 2012. Vemos que Twitter solo usa 420 en la versión 1 obsoleta anterior de su API; la versión actual de la API 1.1 en realidad usa el código de estado 429 . Entonces está claro que Twitter necesitaba un código de estado para esto y definió el suyo propio; Una vez que uno estándar estaba disponible, lo cambiaron.

La mejor práctica, por supuesto, es apegarse lo más posible a los estándares. Cuando lea RFC, casi siempre encontrará palabras como "DEBE" y "DEBE"; estos tienen significados específicos cuando está compilando su aplicación, que puede encontrar en RFC 2119 .

Esta pregunta profundiza un poco en el tema. Pero la cuestión es que, aunque técnicamente puede crear cualquier código de estado que desee, crear un código de estado fuera del alcance tradicional de los significados del código de estado solo hace que su API sea más obtusa y arcana para los demás. A menos que ese sea el punto, y la API que está creando es tan increíble que todos cambiarán con gusto su codificación para seguir su ejemplo, ¿qué importa de todos modos?

Todo se reduce a esto: cualquier estándar puede romperse. Pero si lo rompes, ¿qué ganas o pierdes al hacerlo?

En general, en los casos en que puede hacer algo diferente pero los estándares implican estándares, es mejor cumplir con los estándares a menos que haya una razón muy fuerte y convincente para alejarse de los estándares establecidos. En el caso de Twitter, 420: Enhance Your Calmestán creando un código de respuesta que claramente habla de una situación única que enfrentan. Lo que está ralentizando las solicitudes sin negar el servicio.