¿Cuál es el código de respuesta REST adecuado para una solicitud válida pero con datos vacíos?

Me opongo firmemente a 404 a favor de 204 o 200 con datos vacíos. O al menos uno debería usar una entidad de respuesta con el 404.

La solicitud se recibió y se procesó correctamente: activó el código de la aplicación en el servidor, es posible que el cliente no haya cometido ningún error y, por lo tanto, toda la clase de códigos de error del cliente (4xx) puede no ser adecuada.

Más importante aún, el 404 puede ocurrir por varias razones técnicas. Por ejemplo, la aplicación se desactiva o desinstala temporalmente en el servidor, problemas de conexión de proxy y todo eso.

Claro, la clase de error 5xx existe para tales casos, pero en realidad los componentes de middleware afectados a menudo no tienen forma de saber que el error está de su lado y luego simplemente asumen que el error está en el lado del cliente y luego responden con un 404. en lugar de 500/503.

Por lo tanto, basándose únicamente en el código de estado, el cliente no puede distinguir entre un 404 que significa "lo que estaba buscando no existe" y un 404 que significa "algo anda muy mal, informe este error al equipo de operaciones".

Esto puede ser fatal: imagine un servicio de contabilidad en su empresa que enumera a todos los empleados a los que se les debe una bonificación anual. Desafortunadamente, la única vez que se llama, devuelve un 404. ¿Eso significa que nadie debe recibir una bonificación o que la aplicación está actualmente inactiva por una nueva implementación y el 404 en realidad proviene del Tomcat que se supone? para instalarlo, en lugar de hacerlo desde la propia aplicación? Estos dos escenarios producen el mismo código de estado, pero su significado es fundamentalmente diferente.

-> Para aplicaciones que necesitan saber que un recurso solicitado no existe en lugar de simplemente ser temporalmente inaccesible, 404 sin entidad de respuesta es prácticamente imposible.

Además, muchos marcos de clientes responden a un 404 lanzando una excepción sin hacer más preguntas. Esto obliga al desarrollador del cliente a detectar esa excepción, evaluarla y luego decidir en base a eso si registrarla como un error detectado, por ejemplo, por un componente de monitoreo o si ignorarla. Eso tampoco me parece bonito.

La ventaja de 404 sobre 204 es que puede devolver una entidad de respuesta que puede contener información sobre por qué no se encontró el recurso solicitado. Pero si eso es realmente relevante, entonces también se puede considerar usar una respuesta 200 OK y diseñar el sistema de manera que permita respuestas de error en los datos de la carga útil. Alternativamente, se podría utilizar la carga útil de la respuesta 404 para devolver información estructurada a la persona que llama. Si recibe, por ejemplo, una página html en lugar de XML o JSON que puede analizar, entonces es un buen indicador de que algo técnico salió mal en lugar de una respuesta "sin resultado" que puede ser válida desde el punto de vista de la persona que llama. O se podría usar un encabezado de respuesta HTTP para eso.

Aún así, preferiría un 204 o 200 con una respuesta vacía. De esta forma se separa el estado de ejecución técnica de la solicitud del resultado lógico de la solicitud. 2xx significa "ejecución técnica correcta, este es el resultado, ocúpese de ello".

Creo que en la mayoría de los casos debería dejarse al cliente decidir si un resultado vacío es aceptable o no. Al devolver el 404 sin entidad de respuesta a pesar de una correcta ejecución técnica el cliente puede decidir considerar casos como errores que simplemente no lo son.

Otra perspectiva: desde el punto de vista operativo, un 404 puede ser problemático. Dado que puede indicar un problema de conectividad/middleware en lugar de una respuesta de servicio válida, no quisiera un número fluctuante de 404 "válidos" en mis métricas/paneles que puedan ocultar problemas técnicos genuinos (por ejemplo, un proxy mal configurado en algún lugar del enrutamiento de la solicitud) eso debería ser investigado y arreglado. Esto se ve aún más exacerbado por algunas API que incluso usan 404 en lugar de 401/403 (por ejemplo, gitlab hace tal cosa), para ocultar la información de que el URI de la solicitud habría sido válido pero la solicitud carecía de autorización para acceder a él. También en este caso un 404 debe tratarse como un error técnico y no como un resultado válido de "recurso no encontrado".

Editar: Vaya, esto ha causado mucha controversia. Aquí hay otro argumento en contra de 404: estrictamente desde el punto de vista de una especificación HTTP (RFC7231), 404 ni siquiera significa que un recurso no exista. Sólo significa que el servidor no tiene ninguna representación actual del recurso solicitado disponible, e incluso esto puede ser solo temporal. Estrictamente según la especificación HTTP, 404 es inherentemente poco confiable con respecto a la inexistencia de un elemento solicitado. Si desea comunicar que lo solicitado positivamente no existe, no utilice 404.

Nov 24 '2014 09:11 Jens Wurm