http - type - status code 500 web api
El código de estado HTTP que se devolverá cuando la operación DELETE no esté permitida por una razón particular (2)
Supongamos que tengo un recurso (por ejemplo: /api/shipments/100 ) que admite el método HTTP DELETE. Como puede comprender a partir de la propia URI, si se realiza una solicitud DELETE contra esta URI, este recurso se eliminará.
En mi escenario actual, la solicitud DELETE solo se puede realizar con éxito si se cumple una determinada condición de la siguiente manera:
- Si el estado de envío no se establece en Ineafacto o Entregado.
Si hay una solicitud DELETE contra ese URI y no se cumple la condición anterior, ¿qué código de estado HTTP sería más apropiado devolver en ese caso? He pensado en los de abajo, pero no pude decidir cuál es más semántico:
- Método 405 no permitido
- 403 Prohibido
- 409 Conflicto
Iría con 409: Conflict , porque lo que tienes es una violación del estado del recurso.
405: Method Not Allowed también funcionaría. Si desea usar un 405 , deberá enviar un encabezado Allow para indicar los métodos admitidos, y los métodos admitidos variarán dependiendo del estado del recurso. En mi opinión, este código de respuesta se adapta bien a los recursos de solo lectura, los recursos que no se pueden eliminar, etc., pero los comentarios de Darrel a esta publicación son válidos. La especificación es ambigua:
El método especificado en la línea de solicitud no está permitido para el recurso identificado por el URI de solicitud. La respuesta DEBE incluir un encabezado Permitir que contenga una lista de métodos válidos para el recurso solicitado.
En cualquier caso, debe proporcionar información en el cuerpo de la respuesta para que el cliente entienda la fuente del error.
Respecto a los otros dos métodos mencionados:
403: Forbidden debe usarse cuando no tiene los privilegios adecuados para modificar el recurso, es decir, si tiene que ser un administrador para eliminar ese recurso y no lo es.
412: Precondition Failed se usa principalmente para solicitudes condicionales donde las condiciones previas se especifican explícitamente en los encabezados de solicitud. Por ejemplo, puede tener solicitudes PUT condicionales que deben llevarse a cabo solo cuando el encabezado If-Match es válido. Si no especifica nada en los encabezados de solicitud, todavía elegiría 409 sobre 412. Aquí está la especificación para 412:
La condición previa dada en uno o más de los campos del encabezado de la solicitud se evaluó como falso cuando se probó en el servidor. Este código de respuesta permite al cliente establecer condiciones previas en la metainformación del recurso actual (datos del campo del encabezado) y, por lo tanto, evitar que el método solicitado se aplique a un recurso diferente al previsto.
Yo usaría 412: Condición fallida.
Por favor vea esto para códigos de estado HTTP