¿Qué código HTTP debo devolver para "Cosa no encontrada"?

https://stackoverflow.com/questions/1027300

06-07-2019
|

Pregunta

Estoy construyendo un servicio web que se utiliza, en este caso particular, para solicitar información sobre un usuario.

Digamos, en aras de la discusión, que la búsqueda en la web es:

GET /patrons/619 HTTP/1.1

Si se encuentra al usuario, devuelvo el código 200:

HTTP/1.1 200 OK

Si omite o da un número de cuenta que no es un número, devuelvo 400. Por ejemplo, las siguientes solicitudes incorrectas:

GET /patrons HTTP/1.1
GET /patrons/ HTTP/1.1
GET /patrons/G619 HTTP/1.1
GET /patrons/kirsten%20guyer HTTP/1.1

todos devuelven el error 400 (Solicitud incorrecta), por ejemplo:

HTTP/1.1 400 Invalid patron number

Quiero tener un código de estado para usuario no encontrado , devuelto como el código de estado HTTP. Por ejemplo:

GET /patrons/1322 HTTP/1.1

HTTP/1.1 404 Not Found

He pensado en usar 404 (No encontrado) , que es una respuesta válida (el recurso solicitado fue, real y verdaderamente, no encontrado). Pero yo me temo que las personas que lo depuran podrían pensar que significa que escribieron /patrons/ incorrecto.

¿Alguien puede pensar en otro código de estado http que pueda usar?

Actualización: estoy mirando

204 No Content 
The server successfully processed the request, but is not returning any content.

¿Qué dices?

No olvide que no todos los servidores HTTP sirven contenido HTML. Si se le pide a un servidor web IIS un recurso llamado:

GET /MyStartPage.html HTTP/1.1

Entonces el servidor HTTP tiene que decidir con qué responder. En la mayoría de los servidores web, un recurso llamado /MyStartPage.html corresponde a un archivo que se encuentra en el disco duro.

Mientras que StackOverflow lo hace:

GET /posts/1027301 HTTP/1.1

Que, si ese recurso no existe, el servidor web debería (correctamente) devolver 404.

Solución

404 Not Found es lo correcto para devolver, si es un servicio, en realidad no está siendo utilizado por humanos sino por máquinas, y por lo tanto, los errores tipográficos no deberían ser su primera preocupación.

Además, hay muy poco que puedas hacer para contrarrestar el comportamiento humano de todos modos (pensar en una cosa cuando realmente es otra). Si devuelve un pequeño mensaje de error como parte del código de error, todo debería funcionar. Incluso podría sugerirles una posible solución.

Devolver un 500 cuando la aplicación está haciendo exactamente lo que está diseñado para hacer también parece un poco extraño. 404 describe exactamente la situación: recurso no encontrado.

Otros consejos

Creo que debería usar 404. Los desarrolladores de la API entenderán lo que significa 404 y, por lo tanto, seguirán su propio proceso de depuración habitual para resolver el problema. Cumplir con el protocolo.

El error 404 es en realidad una respuesta más aceptable para este caso, porque el recurso realmente no se encuentra. Siempre puede tener un documento de error personalizado que explique que no se encuentra la identificación de usuario.

Un error 400 implica que el cliente envió una sintaxis con formato incorrecto, que no es el caso en su ejemplo. Por lo tanto, no debe usar este código de error. Puede parecer que "Solicitud incorrecta" es preciso, pero lo que esto realmente significa es que hay un error en la sintaxis del encabezado de la solicitud.

Esto tampoco es un error 500 porque no se ha producido ningún error. No hay ningún problema con el servidor web que cumple con la solicitud, el hecho es que la solicitud busca un recurso que no está presente.

404 es la única respuesta apropiada, a menos que desee considerarla una solicitud totalmente válida, devolver el estado 200 y una página que explique que el Patrón solicitado no existe.

De mi comentario original sobre la pregunta:

No creo que un error de 200 niveles sea apropiado tampoco, considere las explicaciones en W3 w3.org/Protocols/rfc2616/rfc2616-sec10.html

En mi humilde opinión, la respuesta HTTP es no el lugar adecuado para manejar esto, ya que el error no está en el nivel HTTP. Está a nivel de aplicación. Una posible solución es utilizar el Patrón de objeto nulo para devolver un 'Patrón' nulo que se ajuste a la interfaz de usuario, pero indica que no existe tal persona.

ACTUALIZACIÓN: me he convencido de que esta respuesta es incorrecta. Sin embargo, quiero dejarlo, ya que es una respuesta potencialmente válida (dependiendo de los detalles no presentados en la pregunta), y creo que los comentarios son instructivos.

Normalmente, si su servicio encuentra un error que no puede manejar, pero la solicitud está bien formada, entonces creo que desearía devolver un código de estado 500.

Además, otra razón por la que digo que 500 sería apropiado es que, desde mi experiencia en los servicios web .NET, cada vez que lanzo una excepción (como una excepción RecordNotFound), el servidor web y el cliente siempre han interpretado el la respuesta será un código de estado 500.

De cualquier manera, sería una buena idea revisar esta lista de códigos de estado http, y bien el que mejor se adapte a sus necesidades.

Depende del tipo de servicio web que esté construyendo.

Los servicios web SOAP y XML generalmente devuelven 200 OK si no se puede encontrar un objeto solicitado (usuario) y codifican el tipo de error / mensaje / descripción en el documento de respuesta. Separan un nivel de transporte (HTTP) de los mensajes intercambiados (XML). Solo se devuelve un error 404 (que se encuentra en el nivel de transporte) si solicita un punto final de API no existente (URL incorrecta).

Sin embargo, con un servicio web REST, utiliza métodos y estados HTTP directamente para el intercambio de mensajes. REST utiliza diferentes métodos HTTP (GET / POST / PUT / DELETE) para especificar qué acción se desea y el servidor devuelve el estado como el estado HTTP. Entonces, en el caso de un servicio web REST, 404 sería el estado HTTP adecuado si no se pudiera encontrar un usuario.

500 es inapropiado en cualquier caso, creo, ya que 5xx significa que ha habido algo mal en el lado del servidor (que no es el caso), mientras que los errores 4xx significan que hay algo mal en el lado del cliente.

Puede tener 4 años, pero sigue siendo bastante relevante. Para las API que deben usar tanto los usuarios como las aplicaciones nativas, considero que es mucho más simple usar los códigos HTTP para la indicación del estado. Y si es necesario, use un par de códigos adicionales de los no asignados para condiciones que no se ajustan bien a los códigos HTTP existentes.

Los errores en el nivel de servicio web no solo deberían devolver una simple línea de estado HTTP, sino que deberían devolver el contenido en un formato válido y documentado que el cliente pueda analizar al acceder a su servicio. El documento devuelto debe contener un código de error que sea parte de un conjunto documentado de códigos específicos de su servicio web, así como una breve descripción del problema y, opcionalmente, una descripción más detallada del problema.

Si desea controlar las respuestas del servicio web a través de códigos de respuesta HTTP, puede utilizar un 404 para indicar esta condición.

Sin embargo, creo que es más natural tener la respuesta del servicio web definida por completo en el cuerpo de la respuesta HTTP, y simplemente devolver 200 para una comunicación exitosa ("Comprendí su solicitud y le envié una respuesta apropiada". ) En este caso, devolvería 200 de forma normal con la carga útil de su solicitud (XML o JSON o lo que sea) indicando que no se encontró una entidad coincidente

Consideraría que los códigos de error que no son 200 son similares a las excepciones en los lenguajes de programación convencionales, y el cuerpo de respuesta HTTP se parece más al código de retorno. Imagínese si estuviera implementando esto convencionalmente: ¿lanzaría una excepción si no se encuentra ninguna entidad o devolvería null ? Personalmente, dada la naturaleza frágil de las conexiones de red, me gustaría reservar todos los códigos de error de nivel HTTP para problemas de comunicación, y preferiría siempre devolver 200 OK del servicio en sí, junto con una carga útil que especifica el resultado o cualquier error de nivel de servicio.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow