web-services - para - http/1.1 200 ok
RESTO: asignación de errores de aplicación a códigos de estado HTTP (5)
¿Se debe considerar una buena práctica reutilizar los códigos de estado HTTP de RFC como este, o deberíamos inventar otros nuevos que se correspondan exactamente con nuestros motivos específicos de error?
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 respuestas, nuestro objetivo es devolver Códigos de estado HTTP que tengan sentido para los cachés y desarrolladores web.
¿Pero cómo se hace para mapear diferentes clases de errores en los códigos de estado HTTP apropiados? Todos en el equipo acuerdan lo siguiente:
GET / package / 1234 devuelve 404 Not Found si 1234 no existe
GET / package / 1234 / next_checkpoint devuelve 400 Bad Request si "next_checkpoint" y 1234 son válidos para pedir pero next_checkpont aquí no tiene sentido ...
y así sucesivamente ... pero, en algunos casos, las cosas deben ser más específicas que solo "400", por ejemplo:
POST / dispatch /? For_package = 1234 devuelve 412 Falló la condición previa si / dispatch y el paquete 1234 existen, PERO 1234 aún no está listo para el envío.
( Editar: códigos de estado en HTTP / 1.1 y códigos de estado en WebDAV ext. )
GET / package / 1234 / next_checkpoint devuelve 400 Bad Request si "next_checkpoint" y 1234 son válidos para pedir pero next_checkpont aquí no tiene sentido ...
Esta 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, 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.
422 Entidad no procesable es un código de error útil para escenarios como este. Consulte esta pregunta sobre qué código de respuesta http para el servicio de reposo en el método put cuando las reglas de dominio no son válidas para obtener información adicional.
Debe usar las respuestas de la serie 4xx que mejor coincidan con su solicitud cuando el cliente se equivoca, aunque tenga cuidado de no usar 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 posterior 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.
El uso RESTful de HTTP significa que debe mantener la API uniforme. 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
En realidad, no deberías hacer esto en absoluto. El uso de 404 Not Found es correcto, pero 400 Bad Request se está utilizando de forma incorrecta. Una 400 Bad Request según RFC se utiliza únicamente cuando el protocolo HTTP está mal formado. En su caso, la solicitud es sintácticamente correcta, es solo un argumento inesperado. Debería devolver un 500 Server Error y luego incluir un código de error en su resultado de REST.