Traducción realizada por: Deymar Callisaya, Cecilia Alvarado Monrroy y Ronald Vallejos DuráN @Vallejowsky)
¿Qué podría ser más simple que retornar códigos de estado HTTP? ¿La página renderizó? Entonces, retorna código 200. ¿La página no existe? Eso es un código 404. ¿Quieres redireccionar al usuario a otra página? Código 302, o tal vez 301.
La vida es dicha, bueno… hasta que alguien te dice que no estás haciendo REST. Lo que sigue es que no puedes dormir por las noches porque necesitas saber si tu nuevo recurso retorna uno de los códigos de estado aprobados por Roy Fielding. Entonces, no sabes si sólo se debe retornar el código 200, o ¿debería ser código 204 “No Content”? Incluso 202 “Accepted” o ¿tal vez 201 “Created”?
Lo que complica aún más el escenario es la guía oficial de HTTP/1.1 (cuyo RFC fue, originalmente, escrito en 1997i). El año en que tú surfeabas la red en un navegador Netscape con un módem de 33.6kbps. Realmente fuera de contexto; es como si intentáramos aplicar El Arte de la Guerra de Tsun Zu del antiguo mundo a una estrategia de negocios moderna.
Sin tan sólo hubiera existido alguna especie de árbol visual de decisiones que permita, de manera rápida, identificar los pocos códigos de estado que habrían sido relevantes en tu situación y así haber podido ignorar los otros códigos obsoletos e irrelevantes.
De nada, internet. Ese momento ha llegado y es hoy.
Dónde Empezar
Parece ser ridículamente obvio, pero he visto mucha gente perdida en saber si: “¿esto es más un 503 Service Unavailable” o un 404 Not Found?”. Suficiente. Si, en muchas ocasiones, te has visto deliberando entre códigos específicos en diferentes tipos de respuestas, estuviste equivocado. Vuelve atrás y mira el anterior diagrama de flujo.
Algunos puntos a considerar antes de dividir en diagramas de flujo específicos:
-
No tienes por qué tomar al pie de la letra este documento. Lee RFC 7231 y httpstatuses.com
-
La audiencia pensada para este documento es aquella que esté desarrollando un sitio web o una API al estilo REST.
-
Los códigos específicos de respuesta para la implementación de un servidor web se pasaron por alto.
-
(Y fueron enteramente omitidos para servidores proxy)
-
- He agrupado los códigos de respuesta en tres grupos generales:
Por último, pero no menos importante. Si se cree que hay errores en este documento, por favor, coméntelo en el blog para solucionarlo.
2XX/3XX
4XX
5XX
Por qué los Códigos de Estado importan
No estoy completamente seguro de que ellos importen.
Hay un montón de gente inteligente en Facebook que construyeron una API que simplemente devuelve un código 200, siempre.
El argumento básico para no tomar en cuenta los códigos de estado específicos es el siguiente: los códigos de estado existentes son demasiado generales para un sitio web o una API modernos. Si la respuesta tiene que incluir, de todas maneras, detalles en un formato específico de la aplicación -como, por ejemplo, qué campos de validación han fallado y por qué- al fin de que el cliente maneje la respuesta en cualquier manera significativa, entonces ¿por qué preocuparse gastando tiempo en un redundante y poco utilizado código de estado HTTP?
Cuando se exige una razón del porqué es importante usar códigos de estado específicos, una, comúnmente citada, es que HTTP es un sistema de capas y que cualquier proxy, caché o biblioteca HTTP, situada entre el cliente y el servidor, funcionará mejor cuando el código de respuesta sea significativo. No encuentro a este argumento convincente, la razón es esta: en un mundo donde todos se están moviendo a HTTPS, hemos restringido cualquier nodo de proxy o el almacenamiento en caché que no estén bajo el control directo del servidor.
En su lugar, te voy a presentar tres razones por las que, creo, los códigos de estado siguen siendo importantes:
-
Los clientes ya manejan (o fácilmente podrían extenderse a manejar) diferentes códigos con un comportamiento especial:
-
301 Moved Permanently vs 302 Found tiene implicaciones SEO con Google y otros.
-
301 Moved Permanently es implícitamente almacenado en caché, mientras que 429 Too Many Requests es implícitamente no aplicable a almacenar en caché, etc.
-
Una biblioteca de cliente podría manejar 429 Too Many Requests para dar marcha atrás y volver a intentar la petición después de un tiempo
-
Una biblioteca de cliente podría manejar 503 Service Unavailable de manera similar
-
A pesar de que no es exhaustivo para los requisitos modernos, muchos códigos de estado representan casos que aún valen la pena manejar con una respuesta especial (así que ¿por qué no usar el código estándar?)
-
APIs que retornan 404 en lugar de 405 Method Not Allowed hacen que me vuelva loco preguntando: “¿cometí un error al escribir la URL o estoy enviando un método HTTP incorrecto?”
-
Te puedo decir que habríamos ahorrado horas y horas de tiempo de depuración si hubiéramos utilizado 502 Bad Gateway en lugar de confundirlo con 500 Internal Server Error
-
Créase o no, se está estableciendo una convención entre APIs ampliamente utilizadas para devolver los códigos de estado como 201 Created, 429 Too Many Requests y 503 Service Unavailable. Si se sigue esta convención, los usuarios encontrarán mucho más fácil de usar el sitio web / API y solucionar cualquier problema con el que puedan encontrarse.
La parte más difícil de todo esto es decidir qué código devolver, pero con el conocimiento correcto y eligiendo un código significativo se vuelve mucho más fácil.
Ver también:
HTTP status code reference
HTTP status codes used by world–famous APIs
HTTP status codes visualized as a subway map
Status Codes To Cat Memes As a Service
Status Codes To Dog Memes As a Service
Esta es un traducción libre del artículo Choosing an HTTP status code – Stop Making It Hard, escrito originalmente por Michael Kropat, disponible en http://racksburg.com/choosing-an-http-status-code/
Traducción realizada por: Deymar Callisaya, Cecilia Alvarado Monrroy y Ronald Vallejos Durán.
NdE. Los términos técnicos comúnmente utilizados – como por ejemplo los códigos HTTP- no han sido traducidos.
Créase o no, se está estableciendo una convención entre APIs ampliamente utilizadas para devolver los códigos de estado como 201 Created, 429 Too Many Requests y 503 Service Unavailable. Si se sigue esta convención, los usuarios encontrarán mucho más fácil de usar el sitio web / API y solucionar cualquier problema con el que puedan encontrarse.
Recomiendas no usar tantos códigos, pero solamente los más comunes? Como lo esta haciendo Facebook, según lo que menciona el artículo?
[…] Español […]