api-design – ¿Debo crear mis propios códigos de estado HTTP? (a la Twitter 420: Mejora tu calma)

Pregunta:

Actualmente estoy implementando una API HTTP, la primera que tengo.

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 hay 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. Es 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é problemas pueden tener los clientes con él, si es que tienen algún problema?

Leí en alguna parte que Mozilla no implementa el chiste 418: I'm a teapot respuesta de 418: I'm a teapot , lo que me hace pensar que los clientes eligen qué códigos de estado implementan. Si eso es cierto, entonces puedo imaginar que el pequeño y divertido mejoramiento de tu código de calma de Twitter es problemático.

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 tómatelo con calma.

Respuesta:

Todo Internet se basa en convenciones. Los llamamos RFC. Si bien nadie vendrá a arrestarlo si viola una 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 clientes, 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 IANA , cada uno rastreable 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 frente al 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 se remonta a abril de 2012. Vemos que Twitter solo usa 420 en la anterior versión obsoleta 1 de su API; la versión actual de la API 1.1 realmente usa el código de estado 429 . Así que está claro que Twitter necesitaba un código de estado para esto y definió el suyo propio; una vez que estuvo disponible uno estándar, lo cambiaron.

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

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım