rest - services - possible http status codes
Desactiva el código de estado HTTP si DELETE es imposible (2)
Una respuesta de 409 Conflict es definitivamente errónea si el cliente no puede resolver el conflicto y eliminar la solicitud más adelante. Es decir, a menos que el recurso tenga un estado de seguimiento, ya sea que se pueda eliminar o no, 409 Conflict no es una buena opción.
A 403 Prohibido no significa necesariamente no autorizado:
Sin embargo, una solicitud puede estar prohibida por razones no relacionadas con las credenciales.
- RFC 7231
Sin embargo, la implicación suele estar ahí. Puede usar este código, pero puede causar cierta confusión. Será especialmente difícil si el método realmente requiere autorización también: necesitará un código o algo en la respuesta que indique si la falla estuvo relacionada con la autorización o si el recurso no se puede eliminar.
Creo que el 405 Method Not Allowed es la forma correcta de hacerlo.
El código de estado 405 (Método no permitido) indica que el servidor de origen conoce el método recibido en la línea de solicitud, pero el recurso de destino no lo admite.
- RFC 7231
El método DELETE no es compatible con este recurso. Eso suena exactamente como lo que estás describiendo. La especificación de HTTP realmente no tiene un concepto de un tipo de recurso, solo un recurso. Sucede que las personas agrupan los recursos individuales en el mismo punto final para la cordura, pero eso es solo una conveniencia para los desarrolladores y usuarios. En lo que respecta a la especificación HTTP, /widgets/12 y /widgets/15 y /widgets/3453 son tres recursos diferentes. El hecho de que el mismo objeto represente los tres de esos recursos en el servidor es completamente irrelevante. Creo que ese es el "tipo" que estás pensando, pero para HTTP eso es solo un detalle de la implementación.
Mi pregunta es bastante genérica sobre el código de estado HTTP cuando no es posible DELETE en el recurso (pero no con respecto a los derechos del usuario).
Tenemos una API RESTful en un tipo de recurso.
El método DELETE está autorizado en el recurso, sin embargo, bajo ciertas condiciones, un recurso no se puede eliminar (si hay datos vinculados a este recurso).
¿Cuál es el código de estado HTTP correcto para regresar al cliente en esta situación?
Estas son algunas de las posibilidades que reuní y por qué parece inapropiado en mi caso:
- 403 ( Prohibido ): Parece mayormente relacionado con los derechos del usuario.
- 405 ( Método no permitido ): parece que la API no está diseñada para responder a este método para este tipo de recurso.
- 409 ( Conflicto ): Parece apropiado, pero el cliente debería tener la posibilidad de resolver el conflicto con la API, pero ese no es el caso aquí.
Actualización: el enlace de datos que impide que se elimine el recurso no se puede cambiar a través de la API REST. Sin embargo, el recurso puede ser "liberado" de otra manera, ya que otras aplicaciones que pueden cambiar el estado de un recurso acceden a la base de datos de la que provienen los datos (un SQL DELETE en el DB siempre puede hacerlo).
Yo diría que 409 es el más apropiado, dada su redacción en el RFC:
El código de estado 409 (Conflicto) indica que la solicitud no se pudo completar debido a un conflicto con el estado actual del recurso objetivo . Este código se utiliza en situaciones en las que el usuario puede resolver el conflicto y volver a enviar la solicitud. El servidor DEBERÍA generar una carga útil que incluya suficiente información para que un usuario reconozca el origen del conflicto.
(énfasis mío)
Según mi comprensión de la descripción en la pregunta, la razón por la que ELIMINAR no se permite es exactamente un conflicto con el estado actual del recurso objetivo . Como se indica en la RFC, la carga útil de respuesta puede dar una indicación del motivo y, opcionalmente , el usuario podría resolverlo. No veo nada en la especificación que hace que 409 sea inapropiado solo porque la API no ofrece una posibilidad de resolución de conflictos.