RESTO: errores en la aplicación de mapeo para los códigos de estado HTTP

Question

¿Es para ser considerado buenas prácticas a reutilización RFC códigos de estado HTTP como este, o debemos ser hacer otras nuevas que se asignan exactamente a nuestras razones de error específicos ?

Estamos diseñando una API de servicio web alrededor de un par de aplicaciones heredadas.

Además de las estructuras de datos JSON/XML en el cuerpo de respuesta, nuestro objetivo es devolver los códigos de estado HTTP que tienen sentido para los desarrolladores de cachés web y.

Pero, ¿cómo se hace para mapear diferentes clases de errores en los códigos de estado HTTP apropiados? Todo el mundo en el equipo está de acuerdo en lo siguiente:

GET/paquete/1234 vuelve 404 Not Found si 1234 no existen

GET/paquete/1234/next_checkpoint vuelve 400 Solicitud incorrecta si "next_checkpoint" 1234 y son válidos para pedir pero next_checkpont aquí no tiene sentido ...

y así sucesivamente ... pero, en algunos casos, la cosa tiene que ser más específico que sólo "400" - por ejemplo:/for_package = 1234 vuelve

de POST/despacho 412 Error de condición previa if/dispatch y el paquete 1234 ambos existen, PERO 1234 aún no está listo para su envío.

---

(Editar: Status codes in HTTP/1.1 y Status codes in WebDAV ext.)

Answer 1

El uso RESTful de HTTP significa que debe mantener uniforme la API. Esto significa que no puede agregar métodos específicos de dominio (ala GET_STOCK_QUOTE) pero también significa que no puede agregar códigos de error específicos del dominio (producto 499 Agotado).

De hecho, los códigos de error del cliente HTTP son una buena verificación de diseño porque si diseña su semántica de recursos correctamente, los significados del código de error HTTP expresarán correctamente cualquier error. Si cree que necesita códigos de error adicionales, es probable que su diseño de recursos esté equivocado.

Ene

Answer 2

En realidad, usted no debe hacer esto en absoluto. Su uso de 404 Not Found es correcto, pero 400 Bad Request se está utilizando incorrectamente. Un 400 Bad Request de acuerdo con el RFC se usa únicamente cuando el protocolo HTTP está mal formado. En su caso, la solicitud es sintácticamente correcta, es solo un argumento inesperado. Debe devolver un 500 Server Error y luego incluir un código de error en su resultado REST.

Answer 3

Debe utilizar las respuestas de la serie 4xx que mejor se adapten a su solicitud cuando el cliente se equivoca, aunque tenga cuidado de no utilizar las que están destinadas a encabezados o condiciones específicos. Tiendo a devolver un mensaje de estado legible por humanos y una versión de texto sin formato del error como el cuerpo de la respuesta o un mensaje de error estructurado, dependiendo del contexto de la aplicación.

Actualización: Tras la lectura adicional de la RFC, "procondition failed" está destinada a los encabezados condicionales, como "if-none-match". En su lugar, daría un mensaje general de 400.

Answer 4

422 Entidad no procesable es un código de error útil para situaciones como esta. Consulte esta pregunta what http response code for rest service on put method when domain rules invalid para obtener información adicional.

Answer 5

GET/paquete/1234/next_checkpoint retornos 400 Bad Request si "next_checkpoint" y 1234 son válidos para pedir pero next_checkpont aquí no tiene sentido ...

Este es la forma incorrecta de pensar en ese URI.

Los URI son opacos, por lo que observar que algunas partes son 'válidas' y otras no lo son, no tiene ningún sentido desde la perspectiva del cliente. Por lo tanto, debe 'simplemente' devolver un 404 al cliente, ya que el recurso "paquete/1234/próximo_checkpoint" no existe.