¿Debo usar códigos de estado HTTP para describir eventos de nivel de aplicación

Varios servidores con los que he tratado devolverán HTTP 200 para solicitudes que el cliente debería considerar un error, con algo como 'éxito: falso' en el cuerpo.

Esto no me parece una implementación adecuada de códigos HTTP, particularmente en casos de autenticación fallida. He leído los códigos de error HTTP resumidos de manera bastante sucinta, ya que '4xx' indica que la solicitud no se debe volver a hacer hasta que se modifique, mientras que '5xx' indica que la solicitud puede o no ser válida y se puede volver a intentar, pero no tuvo éxito. En este caso 200: error de inicio de sesión, o 200: no se pudo encontrar ese archivo, o 200: falta el parámetro x, definitivamente parece incorrecto.

Por otro lado, pude ver el argumento de que '4xx' solo debería indicar un problema estructural con la solicitud. Por lo tanto, es correcto devolver 200: usuario / contraseña incorrecta en lugar de 401 sin autorización porque el cliente puede realizar la solicitud, pero resulta ser incorrecta. Este argumento podría resumirse ya que, si el servidor pudo procesar la solicitud y tomar una determinación, el código de respuesta debería ser 200, y el cliente debe verificar el cuerpo para obtener más información.

Básicamente, esto parece ser una cuestión de preferencia. Pero eso no es satisfactorio, así que si alguien tiene una razón por la cual cualquiera de estos paradigmas es más correcto, me gustaría saberlo.

Interesante pregunta.

Básicamente, podemos reducir esto a la forma correcta de clasificar las cosas en términos análogos a las capas OSI. HTTP se define comúnmente como un protocolo de nivel de aplicación, y HTTP es de hecho un protocolo genérico de cliente / servidor.

Sin embargo, en la práctica, el servidor es casi siempre un dispositivo de retransmisión, y el cliente es un navegador web, responsable de interpretar y representar el contenido: el servidor simplemente pasa las cosas a una aplicación arbitraria, y esas aplicaciones envían scripts arbitrarios que el navegador Es responsable de la ejecución. La interacción HTTP en sí misma, los formularios de solicitud / respuesta, los códigos de estado, etc., es principalmente una cuestión de cómo solicitar, servir y presentar contenido arbitrario de la manera más eficiente posible, sin interferir. Muchos de los códigos de estado y encabezados están diseñados para estos fines.

El problema al tratar de aprovechar el protocolo HTTP para manejar flujos específicos de la aplicación, es que te queda una de dos opciones: 1) Debes hacer que tu lógica de solicitud / respuesta sea un subconjunto de las reglas HTTP; o 2) Debe reutilizar ciertas reglas, y luego la separación de las preocupaciones tiende a volverse confusa. Esto puede verse bien y limpio al principio, pero creo que es una de esas decisiones de diseño que terminas lamentando a medida que tu proyecto evoluciona.

Por lo tanto, 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.

El otro beneficio de este enfoque, que vale la pena mencionar, es que las aplicaciones, en términos generales, no deberían depender de un protocolo de transporte subyacente (desde un punto de vista lógico). HTTP en sí mismo ha cambiado en el pasado, y ahora tenemos el inicio de HTTP 2, después de SPDY. Si ve que su aplicación no es más que un complemento de funcionalidad HTTP, es posible que se quede atascado allí cuando las nuevas infraestructuras se hagan cargo.

Esta pregunta está un poco basada en la opinión, pero de cualquier manera.

A mi modo de ver, 200 puede servir "errores suaves". Cuando se trata de crear API, trato de distinguir entre estos y los "errores duros".

Los "errores suaves" se mostrarán con un código de estado de 200, pero contendrán una descripción del error y un estado de éxito de false. Los "errores suaves" solo ocurrirán cuando el resultado sea "como se esperaba", pero no un éxito en el sentido más estricto.

Es importante tener en cuenta que los "errores suaves" son más una pista para el implementador. Por lo tanto, es importante proporcionar también más información sobre el error, como un mensaje de error legible por humanos y / o algún tipo de código que se pueda utilizar para proporcionar comentarios al usuario final. Estos errores proporcionan al implementador (y al usuario final) más información sobre lo que sucedió en el lado del servidor .

Por ejemplo, supongamos que tiene una API con una función de búsqueda, pero durante una búsqueda, no se obtienen resultados. Esto no es erróneo, pero tampoco es un "éxito", ni en el sentido más estricto de la definición.

Ejemplo formateado como JSON:

{
    "meta" {
        "success": false,
        "message": "Search yielded no results",
        "code": "NORESULTS"
    }
    "data": []
}

Los "errores duros", por otro lado, recibirán un código de estado que se recomienda para el error. ¿El usuario no ha iniciado sesión? - 403 / 401. ¿Entrada mal formada? - 400. ¿Error del servidor? - 50X. Y así.

De nuevo, está un poco basado en la opinión. Algunas personas quieren tratar todos los errores por igual, "error duro" todo. ¿No hay resultados de búsqueda? Eso es un 404! En el otro lado de la moneda, ¿no hay resultados de búsqueda? - Esto es como se esperaba, no hay error.

Otro factor importante a tener en cuenta es su arquitectura, por ejemplo; si interactúa con su API utilizando solicitudes XHR de JavaScript y jQuery o AngularJS. Estos "errores duros" deberán manejarse con una devolución de llamada separada, mientras que los "errores blandos" pueden manejarse con la devolución de llamada "correcta". Sin romper nada, el resultado sigue siendo "como se esperaba". El código del lado del cliente puede ver el estado de éxito y el código (o mensaje). E imprímalo al usuario final.

Hay dos aspectos de una API: el esfuerzo para implementar la API y el esfuerzo de todos los clientes para usar la API correctamente.

Como autor del cliente, sé que cuando envío una solicitud a un servidor web, es posible que reciba un error (nunca se comunicó correctamente con el servidor) o una respuesta con un código de estado. Tengo que manejar los errores. Tengo que manejar una buena respuesta. Tengo que manejar las respuestas esperadas, documentadas, "malas". Tengo que manejar lo que sea que vuelva.

Al diseñar la API, debe ver qué es lo más fácil de procesar para el cliente. Si el cliente envía una solicitud bien formada y usted puede hacer lo que la solicitud le pide que haga, entonces debe dar una respuesta en el rango de 200 (hay algunos casos en los que es apropiado un número distinto de 200 en ese rango).

Si el cliente pregunta "dame todos los registros como ...", y hay cero, entonces un 200 con éxito y una matriz de cero registros es completamente apropiado. Los casos que mencionas:

"Error de inicio de sesión" generalmente debería ser un 401. "No se pudo encontrar el archivo" debería ser un 404. El "parámetro x faltante" debería ser alrededor de 500 (en realidad, un 400 si el servidor se da cuenta de que la solicitud es incorrecta y 500 si el servidor está totalmente confundido por mi solicitud y no tiene idea de lo que está pasando). Devolver 200 en estos casos no tiene sentido. Simplemente significa que, como autor de un cliente, no puedo simplemente mirar el código de estado, también tengo que estudiar la respuesta. No puedo decir simplemente "estado 200, genial, aquí están los datos".

Especialmente el "parámetro faltante", eso no es algo que pueda manejar . Significa que mi solicitud es incorrecta. Si mi solicitud es incorrecta, no tengo una reserva para solucionar esa solicitud incorrecta; para comenzar, enviaría una solicitud correcta. Ahora me veo obligado a manejarlo. Me sale un 200 y tengo que comprobar si hay una respuesta "falta un parámetro". Eso es horrible.

Al final, hay una docena o dos códigos de estado para manejar muchas situaciones diferentes, y debe usarlos.