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

Pregunta interesante.

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 de cliente / servidor genérico.

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 cosas a una aplicación arbitraria, y esas aplicaciones envían scripts arbitrarios. que el navegador es responsable de ejecutar. 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 procesar contenido arbitrario de la manera más eficiente posible, sin estorbar. Muchos de los códigos de estado y encabezados están diseñados para estos propósitos.

El problema de intentar combinar el protocolo HTTP para manejar flujos específicos de la aplicación, es que se queda con una de estas dos opciones: 1) Debe convertir su lógica de solicitud / respuesta en un subconjunto de las reglas HTTP; o 2) Debe reutilizar ciertas reglas, y luego la separación de las preocupaciones tiende a volverse borrosa. 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 propio con su . La aplicación debe poder realizar solicitudes y necesita las respuestas, y su lógica en cuanto a cómo solicitarlas, 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, en términos generales, las aplicaciones no deben 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 HTTP 2 activándose, siguiendo SPDY. Si considera que su aplicación no es más que un complemento de funcionalidad HTTP, podría quedarse atascado allí cuando las nuevas infraestructuras tomen el control.

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

Tal como lo veo, 200 pueden servir "errores blandos". Cuando se trata de crear API, trato de distinguir entre estos y los "errores graves".

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

Es importante tener en cuenta que los "errores blandos" son más bien una sugerencia para el implementador. Por lo tanto, es importante también proporcionar más información sobre el error, como un mensaje de error legible para las personas y / o algún tipo de código que se pueda usar 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 de las cosas.

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", no 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": []
}

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

Una vez más, es un poco basado en la opinión. Algunas personas quieren tratar todos los errores por igual, todo "error duro". 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úas con tu API utilizando las solicitudes de JavaScript XHR y jQuery o AngularJS. Estos "errores graves" tendrán que ser manejados con una devolución de llamada por separado, mientras que los "errores blandos" se pueden manejar con la llamada "éxito". 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ímelo al usuario final.

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

Como autor del cliente, sé que cuando envío una solicitud a un servidor web, puedo obtener un error (nunca he hablado 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 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 puede hacer lo que la solicitud le pide que haga, entonces debe dar una respuesta en el rango 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" por lo general debería ser un 401. "No se pudo encontrar el archivo" debería ser un 404. "El parámetro que falta x" 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 yo manejaría . Significa que mi solicitud es incorrecta. Si mi solicitud es incorrecta, no tengo un respaldo para corregir esa solicitud incorrecta. Para empezar, enviaría una solicitud correcta. Ahora me veo obligado a manejarlo. Obtengo un 200 y tengo que comprobar si hay una respuesta "falta el parámetro". Eso es horrible.

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