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

Question

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

Digamos que, por el bien del argumento, que el éxito de las operaciones de búsqueda web es:

GET /patrons/619 HTTP/1.1 

Si se encuentra el patrón, vuelvo código 200:

HTTP/1.1 200 OK 

Si se omite, o dar un número de cuenta que no es un número, vuelvo 400. Por ejemplo, las siguientes solicitudes malas:

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

todos vuelven de error 400 (Bad Request), ej .:

HTTP/1.1 400 Invalid patron number 

---

quiero tener un código de estado para patrón no encontrado, devuelve como el código de estado HTTP. Por ejemplo:

GET /patrons/1322 HTTP/1.1 

HTTP/1.1 404 Not Found 

he pensado en utilizar 404 (no encontrado), que es una respuesta válida (el recurso solicitado fue, realmente y verdaderamente, no se encuentra.) Pero me temo la gente depurando podría pensar que significa que deletreó /patrons/ mal.

¿Alguien puede pensar en otro código de estado http que podría usar?

---

Actualización: estoy echando un vistazo a

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

lo que dice la verdad?

---

No olvide que no todos los servidores HTTP ofrecen contenido HTML. Si se pide a un servidor Web IIS para un recurso llamado:

GET /MyStartPage.html HTTP/1.1 

A continuación, el servidor HTTP tiene que decidir qué responder con. En la mayoría de los servidores web, un recurso llamado /MisPaginaPágina.html corresponde a un archivo ubicado en el disco duro.

Mientras Stackoverflow hace:

GET /posts/1027301 HTTP/1.1 

Lo cual, si ese recurso no existe, el servidor web debe (con razón) de retorno 404.

Answer 1

404 No encontrado es lo correcto, si se trata de un servicio, realmente no lo utilizan los humanos, sino las máquinas, y por lo tanto, los errores tipográficos no deberían ser su principal preocupación.

Además, es muy poco lo que vas a poder hacer para contrarrestar el comportamiento humano de todos modos (pensando 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ías sugerirles una posible solución.

Devolver 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.

Answer 2

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

---

ACTUALIZACIÓN: he estado 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.

Answer 3

Normalmente, si su servicio encuentra un error que no puede manejar, pero la solicitud está bien formada, entonces creo que le gustaría devolver un código de estado de 500. También, otra razón por la que digo que 500 sería apropiado es que, según mi experiencia en servicios web .NET, cada vez que lanzo una excepción a través del cable (como una excepción RecordNotFound), el servidor web y el cliente siempre han interpretado la respuesta es un código de estado de 500.

De cualquier manera, sería una buena idea revisar este list de los códigos de estado de http, y seleccionar el que mejor se adapte a sus necesidades.

Answer 4

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 del usuario.

Un error 400 implica que el cliente envió una sintaxis mal formada, que no es el caso en su ejemplo. Por lo tanto, no deberías usar este código de error. Puede parecer que "Solicitud incorrecta" es precisa, pero lo que esto realmente significa es que hay un error en la sintaxis del encabezado de solicitud.

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

404 es la única respuesta adecuada, a menos que desee considerarla como una solicitud completamente válida, devolver el estado 200 y una página que explique que el Patron solicitado no existe.

Desde mi comentario original sobre la cuestión:

No creo que un error de nivel 200 sería adecuado, ya sea, tenga en cuenta las explicaciones en W3 w3.org/Protocols/rfc2616/rfc2616-sec10.html

Answer 5

pienso debe usar 404. Los desarrolladores de la API comprenderán lo que significa 404 y, por lo tanto, seguirán su propio proceso habitual de depuración para resolver el problema. Quédate con el protocolo

Answer 6

Los errores en el nivel del servicio web no solo deben devolver una simple línea de estado HTTP, sino que deben devolver el contenido en un formato válido y documentado que pueda analizar el cliente que accede a su servicio.El documento devuelto debe contener un código de error que es 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.

Answer 7

Depende del tipo de servicio web que esté construyendo.

Los servicios web SOAP y XML suelen devolver 200 OK si no se puede encontrar un objeto solicitado (usuario) y codificar el tipo de error/mensaje/descripción en el documento de respuesta. Separa un nivel de transporte (HTTP) de los mensajes intercambiados (XML). Se devuelve un error 404 (que está en el nivel de transporte) solo si se solicita un punto final API no existente (URL incorrecta).

Sin embargo, con un servicio web REST, usted usa los 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. Por lo tanto, en el caso de un servicio web REST, 404 sería el estado HTTP correcto si no se pudiera encontrar un usuario.

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

Answer 8

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

Sin embargo, creo que es más natural que la respuesta del servicio web se defina completamente en el cuerpo de la respuesta HTTP, y solo devuelva 200 para una comunicación exitosa ("Entendí su solicitud y le envié una respuesta adecuada") En este caso, devolvería 200 normalmente con la carga de su solicitud (XML o JSON o lo que sea) indicando que no se encontró ninguna entidad coincidente

Consideraría códigos de error no 200 similares a las excepciones en los convencionales lenguajes de programación, y el cuerpo de respuesta HTTP más como el código de retorno. Imagínese si estuviera implementando esto convencionalmente: ¿lanzaría una excepción si no se encontrara 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 prefiero devolver 200 OK del servicio en sí, junto con una carga útil que especifique el resultado o cualquier servicio. nivel de error

Answer 9

Puede tener 4 años, pero sigue siendo bastante relevante. Para las API que deben ser usadas tanto por los borwsers como por las aplicaciones nativas, creo que es mucho más simple usar los códigos HTTP para indicar el estado. Y si es necesario, utilice un par de códigos extra de los no asignados para las condiciones que no encajan bien con los códigos HTTP existentes.