pagina - Devolver http 200 OK con error dentro del cuerpo de respuesta

http/1.1 200 ok

Question

Me pregunto si es correcto devolver HTTP 200 OK cuando se produjo un error en el lado del servidor con algún error dentro del cuerpo de respuesta.

Ejemplo:

1. Estamos enviando http GET
2. Algo inesperado sucedió en el lado del servidor.
3. El servidor devuelve el código de estado http 200 OK con un error dentro de una respuesta (por ejemplo, {"status":"some error occured"}

¿Es el comportamiento correcto o no? ¿No deberíamos cambiar el código de estado?

Answer 1

Creo que las personas han puesto demasiado peso en la lógica de la aplicación frente al protocolo. Lo importante es que la respuesta debe tener sentido. ¿Qué sucede si tiene una API que sirve un recurso dinámico y se realiza una solicitud para X que se deriva de la plantilla Y con datos Z y Y o Z no están disponibles actualmente? ¿Es eso un error de lógica de negocios o un error técnico? La respuesta correcta es "¿a quién le importa?"

Su API y sus respuestas deben ser inteligibles y consistentes. Debe ajustarse a algún tipo de especificación, y esa especificación debe definir qué es una respuesta válida. Algo que se ajuste a una respuesta válida debería generar un código 200. Algo que no se ajusta a una respuesta válida debería generar un código 4xx o 5xx indicativo de por qué no se pudo generar una respuesta válida.

Si la definición de su especificación de una respuesta válida permite { "error": "invalid ID" } , entonces es una respuesta exitosa. Si su especificación no hace ese ajuste, sería una mala decisión devolver esa respuesta con un código 200.

parseFoo una analogía para llamar a una función parseFoo . ¿Qué sucede cuando llamas a parseFoo("invalid data") ? ¿Devuelve un resultado de error (tal vez nulo)? ¿O arroja una excepción? Muchos tomarán una posición casi religiosa sobre si un enfoque u otro es correcto, pero finalmente depende de la especificación API.

"El elemento de código de estado es un código entero de tres dígitos que proporciona el resultado del intento de comprender y satisfacer la solicitud"

Obviamente, hay una diferencia de opinión con respecto a si "devolver un error con éxito" constituye un éxito o error HTTP. Veo diferentes personas interpretando las mismas especificaciones de diferentes maneras. Así que elija un lado, claro, pero también acepte que de cualquier manera el mundo entero no va a estar de acuerdo con usted. ¿Yo? Me encuentro en algún lugar en el medio, pero ofreceré algunas consideraciones de sentido común.

1. Si su código del lado del servidor detecta una excepción inesperada al enviar una solicitud, eso suena como la definición misma de un 500 Internal Server Error . Esta parece ser la situación de OP. La aplicación no debe devolver un 200 por errores inesperados, sino también ver el punto 3.
2. Si su código del lado del servidor debe ser capaz de manejar con gracia una entrada inválida dada, y no constituye una condición de error "excepcional", su especificación debe acomodar las respuestas HTTP 200 que proporcionan información de diagnóstico significativa.
3. Sobre todo: tener una especificación. Hazlo consistente. Apégate a ello.

En la situación de OP, parece que tiene un estándar de facto que las excepciones no controladas producen un 200 con un cuerpo de respuesta distinguible. No es lo ideal, pero si no está rompiendo cosas y causando problemas activamente, es probable que tenga problemas más grandes e importantes que resolver.

Answer 2

HTTP es el protocolo que maneja la transmisión de datos a través de Internet.

Si esa transmisión se interrumpe por cualquier razón, los códigos de error HTTP le indican por qué no se la pueden enviar.

Los datos que se transmiten no se manejan mediante códigos de error HTTP. Solo el método de transmisión.

HTTP no puede decir ''Ok, esta respuesta es gobbledigook, pero aquí está''. solo dice 200 OK .

es decir: he completado mi trabajo de enviártelo, el resto depende de ti.

Sé que esto ya ha sido respondido, pero lo expresé con palabras que puedo entender. Perdón por cualquier repetición.

Answer 3

Incluso si quiero devolver un error de lógica de negocios como código HTTP, no existe un código de error HTTP aceptable para esos errores en lugar de usar HTTP 200 porque tergiversará el error real.

Entonces, HTTP 200 será bueno para los errores de lógica de negocios. Pero todos los errores que están cubiertos por los códigos de error HTTP deberían usarlos.

Básicamente, HTTP 200 significa qué servidor procesa correctamente la solicitud del usuario (en caso de que no haya asientos en el avión, no importa porque la solicitud del usuario se procesó correctamente, incluso puede devolver solo una cantidad de asientos disponibles en el avión, por lo que habrá no hay errores de lógica de negocios o esa lógica de negocios puede estar del lado del cliente. El error de lógica de negocios es un significado abstracto, pero el error de HTTP es más definido).

Answer 4

Los códigos de estado HTTP dicen algo sobre el protocolo HTTP. HTTP 200 significa que la transmisión está bien en el nivel HTTP (es decir, la solicitud era técnicamente correcta y el servidor pudo responder correctamente). Vea esta página wiki para obtener una lista de todos los códigos y su significado.

HTTP 200 no tiene nada que ver con el éxito o el fracaso de su "código comercial". En su ejemplo, el HTTP 200 es un estado aceptable para indicar que su "mensaje de error de código comercial" se transfirió con éxito, siempre que ningún problema técnico impida que la lógica comercial se ejecute correctamente.

Alternativamente, podría dejar que su servidor responda con HTTP 5xx si ocurrieran problemas técnicos o irrecuperables en el servidor. O HTTP 4xx si la solicitud entrante tenía problemas (por ejemplo, parámetros incorrectos, método HTTP inesperado ...) Nuevamente, todos estos indican errores técnicos , mientras que HTTP 200 indica NO errores técnicos, pero no garantiza los errores de lógica de negocios.

Para resumir: SÍ, es válido enviar mensajes de error (para problemas no técnicos) en su respuesta http junto con el estado HTTP 200. Si esto se aplica a su caso, depende de usted. Si, por ejemplo, el cliente solicita un archivo que no está allí, sería más como un 404 . Si hay una configuración incorrecta en el servidor, podría ser 500 . Si el cliente solicita un asiento en un avión que está lleno, eso sería 200 y su "implementación" determinará cómo reconocer / manejar esto (por ejemplo, bloque JSON con un { "booking","failed" } )

Answer 5

No, esto es muy incorrecto.

HTTP es un protocolo de aplicación. 200 implica que la respuesta contiene una carga útil que representa el estado del recurso solicitado. Un mensaje de error generalmente no es una representación de ese recurso.

Si algo sale mal mientras se procesa GET, el código de estado correcto es 4xx ("te equivocaste") o 5xx ("me equivoqué").

Answer 6

Para aclarar, debe usar códigos de error HTTP donde encajen con el protocolo, y no usar códigos de estado HTTP para enviar errores de lógica de negocios .

Errores como saldo insuficiente , no hay cabinas disponibles , usuario / contraseña incorrecta califican para el estado HTTP 200 con manejo de errores específicos de la aplicación en el cuerpo de respuesta.

Vea esta respuesta de ingeniería de software :

Diría que es mejor ser explícito sobre la separación de protocolos. Deje que el servidor HTTP y el navegador web hagan lo suyo y que la aplicación haga lo suyo. La aplicación debe poder realizar solicitudes, y necesita las respuestas, y su lógica sobre cómo solicitar, cómo interpretar las respuestas, puede ser más (o menos) compleja que la perspectiva HTTP.