Código de estado de "operación no válida" en una API REST de HATEOAS

7

En una API HATEOAS se devuelven enlaces que representan posibles transiciones de estado. Un cliente conforme debería simplemente recuperar y seguir esos enlaces, pero si un cliente no conforme está construyendo URI en lugar de seguir los enlaces proporcionados, ¿cuál sería el código de estado / respuesta más apropiado para devolver?

  • 400 funcionaría, junto con cierta información en el cuerpo de respuesta: esto es lo que estamos haciendo actualmente
  • 403 Supongo que sería incorrecto, ya que implica que la solicitud nunca podría funcionar, pero es posible que el enlace esté disponible en el futuro
  • 404 suena plausible: en este momento el recurso no existe

¿Qué piensa la gente? Sé que las solicitudes condicionales pueden manejar solicitudes basadas en respuestas obsoletas (que dan como resultado, por ejemplo, 412), pero esta es una situación ligeramente diferente.

Actualización:

Bien, ahora veo que la respuesta correcta para estos tipos de operaciones no válidas sería un 404. ¿Qué hay de dónde es correcta la sintaxis de una solicitud? Va a ser un recurso válido pero de alguna manera viola una regla de negocios. Aquí hay un par de ejemplos artificiales:

  1. Digamos que el cliente puede proporcionar dos números que deben estar dentro del 20% entre sí, pero de lo contrario podría ser cualquier número.
  2. Digamos que el cliente puede proporcionar un número que pasa por algún cálculo cuyo resultado indica que el número original proporcionado fue incorrecto.

¿Es 400 la respuesta correcta para estas?

    
pregunta FinnNk 28.03.2012 - 18:27

2 respuestas

5

Si existe la posibilidad de que existan enlaces en el futuro, tanto 400 Bad Request como 403 Forbidden serían incorrectos: sus secciones relevantes en RFC 2616 ambos tienen instrucciones de que el cliente NO DEBE repetir la solicitud. La diferencia entre los dos es que, en el caso de 400 Bad Request , el servidor no entendió lo que el cliente intentaba hacer, mientras que con 403 Forbidden el servidor entendió la solicitud, pero se niega a cumplirla (nunca).

Si desea indicar al cliente que se entendió la solicitud, pero no la manejará en el momento de la solicitud (pero no haga ninguna reclamación sobre su manejo en el futuro), 404 Not Found sería la respuesta más adecuada para enviar.

Si desea indicar al cliente que se entendió la solicitud, pero la solicitud no sigue reglas o pautas predeterminadas (como su ejemplo de que un cliente no proporciona dos números dentro del 20% entre sí), desea utilizar < a href="http://tools.ietf.org/html/rfc2616#section-10.4.10"> 409 Conflict , cuyo objetivo es indicar al cliente que la solicitud necesita ser arreglado para ser manejado adecuadamente.

Sin embargo, debe separar la no conformidad de buena fe de la no conformidad de mala fe. Si está tratando de proteger su aplicación de las solicitudes de un mal actor, es casi seguro que no le importará el código de respuesta que envíe: seguirán creando URL hasta que lleguen a algo que les guste.

    
respondido por el user8 28.03.2012 - 18:54
2

Estos códigos siguen el estándar establecido por rfc de HTTP .

Según la sección Definiciones de códigos de estado :

  • 400 Solicitud incorrecta
  

El servidor no pudo entender la solicitud debido a una sintaxis mal formada. El cliente NO DEBE repetir la solicitud sin modificaciones.

  • 403 Prohibido
  

El servidor entendió la solicitud, pero se niega a cumplirla. La autorización no ayudará y la solicitud NO DEBE repetirse. Si el método de solicitud no era HEAD y el servidor desea hacer público el motivo por el cual la solicitud no se ha cumplido, DEBE describir el motivo de la denegación en la entidad. Si el servidor no desea que esta información esté disponible para el cliente, se puede usar el código de estado 404 (No encontrado) en su lugar.

  • 404 No encontrado
  

El servidor no ha encontrado nada que coincida con el URI de solicitud. No se da ninguna indicación de si la condición es temporal o permanente. El código de estado 410 (Desaparecido) DEBERÍA usarse si el servidor sabe, a través de algún mecanismo configurable internamente, que un recurso antiguo no está disponible permanentemente y no tiene una dirección de reenvío. Este código de estado se usa comúnmente cuando el servidor no desea revelar exactamente por qué se rechazó la solicitud o cuando no se aplica ninguna otra respuesta.

En su caso, si el URI construido no lleva a ninguna parte , creo que sería apropiado devolver 404 .

Y si el URI es válido pero los datos pasados (como un documento de json) están dañados , entonces debería devolver 400 .

EDIT :

Respondiendo al comentario OP: Creo que el sistema debería devolver 400 cuando se rompe la sintaxis y también el significado de los datos.

    
respondido por el karlphillip 28.03.2012 - 18:41

Lea otras preguntas en las etiquetas