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

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

• 400 funcionaría, junto con alguna información en el cuerpo de respuesta: esto es lo que estamos haciendo actualmente
• 403 Supongo que estaría mal, ya que implica que la solicitud nunca podría funcionar, pero potencialmente el enlace puede estar 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 resultan, por ejemplo, en 412), pero esta es una situación ligeramente diferente.

Actualizar:

Bien, ahora veo que la respuesta correcta para este tipo de operaciones no válidas sería un 404. ¿Qué tal si la sintaxis de una solicitud es correcta, va a un recurso válido pero de alguna manera está violando 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 era incorrecto.

¿400 es la respuesta correcta para estos?

Si existe la posibilidad de que los enlaces existan en el futuro, tanto 400 Bad Request como 403 Forbidden serían incorrectos: sus secciones relevantes en RFC 2616 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 (alguna vez).

Si desea indicarle al cliente que la solicitud fue entendida, pero no la manejará en el momento de la solicitud (pero no haga ningún reclamo sobre su manejo en el futuro), 404 No encontrado sería la respuesta más adecuada mandar.

Si desea indicarle al cliente que la solicitud se entendió, pero la solicitud no sigue reglas o pautas predeterminadas (como su ejemplo de un cliente que no proporciona dos números dentro del 20% entre sí), desea utilizar 409 Conflict , que está destinado a indicar al cliente que la solicitud debe corregirse para que se maneje correctamente.

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, seguramente no les importará qué código de respuesta envíe: simplemente seguirán construyendo URL hasta que encuentren algo que les guste.

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

De acuerdo con la sección Definiciones del código de estado :

• 400 Solicitud incorrecta

El servidor no pudo entender la solicitud debido a una sintaxis incorrecta. 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 por qué la solicitud no se ha cumplido, DEBERÍA describir el motivo del rechazo 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).

• 404 no encontrado

El servidor no ha encontrado nada que coincida con el URI de solicitud. No se indica si la condición es temporal o permanente. El código de estado 410 (Desaparecido) DEBE usarse si el servidor sabe, a través de algún mecanismo internamente configurable, que un recurso antiguo no está disponible permanentemente y no tiene 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 conduce a ninguna parte , creo que sería apropiado devolver 404 .

Y si el URI es válido pero los datos pasados ​​(como un documento json) están rotos , debe devolver 400 .

EDITAR :

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