¿Cuál es la forma correcta de ver idempotencia en términos de HTTP DELETE?

Question

He pasado mucho tiempo leyendo recientemente la especificación HTTP 1.1 y relacionándola con REST. He encontrado que hay dos interpretaciones del método HTTP DELETE con respecto a su "idempotencia" y seguridad. Estos son los dos campos:

1. Si elimina un recurso con DELETE HTTP, y tiene éxito (200 OK), y luego intenta eliminar esa cantidad de recursos N de veces, usted debe volver un mensaje de éxito (200 OK) para todas y cada una de esas llamadas de eliminación. Esta es su "idempotencia".

2. Si elimina un recurso con HTTP DELETE, y lo logra (200 OK), y luego intenta eliminar ese recurso nuevamente, debe recuperar un mensaje de error (410 Gone) porque se eliminó el recurso.

La especificación dice BORRAR es idempotente, claro, pero también dice que las secuencias de eventos idempotent todavía pueden producir efectos secundarios. Realmente siento que el segundo campamento es correcto, y el primero es engañoso. ¿Qué "seguridad" hemos introducido al permitir que los clientes piensen que fueron la causa de la eliminación de un recurso previamente eliminado?

Hay un montón de personas en el primer campamento, entre ellas varios autores sobre el tema, por lo que quería comprobar si había alguna razón de peso además de las emociones que llevan a las personas al primer campamento.

Answer 1

Ser idempotente no significa que una solicitud no puede tener efectos secundarios (eso es lo que describe la propiedad 'segura'). Simplemente significa que emitir la misma solicitud varias veces no dará lugar a efectos secundarios diferentes o adicionales.

En mi opinión, la solicitud DELETE posterior debería devolver un error; sigue siendo idempotente porque el estado del servidor es el mismo que si solo se hubiera realizado una solicitud DELETE. Entonces, devolver nuevamente el estado de 200 OK también debería estar bien - No creo que ser idempotente requiera la devolución de un código de error para las siguientes solicitudes DELETE - es solo que devolver el estado del error parece tener más sentido para mí.

Answer 2

@MichaelBurr tiene razón acerca de la idempotencia y los efectos secundarios.

Mi opinión es que hay 2 estados involucrados en una determinada solicitud REST, el estado del cliente y el estado del servidor. REST tiene que ver con la transferencia de estos estados entre el servidor y el cliente, de modo que el estado del cliente se correlaciona con un subconjunto del estado del servidor, en otras palabras, el subconjunto se mantiene coherente con el servidor. Debido a esa idempotencia, esto debería significar que las solicitudes idempotentes subsiguientes no darán como resultado que ninguno de los dos estados sea diferente de lo que sería hacerlo solo una vez. Con el primer DELETE, imagina que el servidor borra el recurso y le informa al cliente que también puede eliminar el recurso (ya que el recurso "ya no existe"). Ahora ambos estados deberían ser idénticos a before con menos el elemento que se eliminó. Para que el cliente haga algo diferente cuando intenta eliminar el elemento una vez que ya ha sido eliminado, el estado que se transfiere del servidor al cliente debe contener información diferente. El servidor puede hacer las cosas de forma ligeramente diferente con la información de que el recurso ya fue eliminado, pero una vez que responde con algo diferente, la idempotencia de los métodos está esencialmente rota.

Para la función idempotente:

delete(client_state) -> client_state - {item} 
delete(delete(client_state)) -> client_state - {item} 
delete(client_state) = delete(delete(client_state)) 

La mejor manera de garantizar este idempotencia es si la respuesta del servidor es idéntico, eso significa que la única manera de que el estado del cliente para romper el idempotencia es para que haya no determinación o efectos secundarios en el manejo de la respuesta por parte del cliente (lo que probablemente apunta a una implementación incorrecta del manejo de la respuesta).

Si existe un acuerdo entre el cliente y el servidor de que los códigos de estado existen fuera de la representación del estado que se transfiere (REST), es posible informar al cliente que el elemento "ya no existe" (como lo haría en la primera solicitud) con el comentario adicional de que se había eliminado previamente. Lo que el cliente hace con esta información no está claro, pero no debería afectar el estado del cliente resultante. Pero entonces el código de estado no se puede usar para comunicar el estado, o más bien si también comunica el estado en otras situaciones (como quizás "no tienes permiso para eliminar este elemento" o "el elemento no se eliminó"), luego hay alguna ambigüedad o confusión introducida. Por lo tanto, al menos necesita una buena razón para introducir más confusión en la comunicación si quiere decir que DELETE es idempotente y aún tienen la respuesta del servidor depende de las solicitudes DELETE anteriores que son idénticas.

peticiones HTTP implican eliminar métodos, por lo que la función podría parecerse

delete(client_state) = send_delete(client_state) -> receive_delete(client_state) 
               -> respond_to_delete(informative_state) 
               -> handle_response(informative_state) 
               -> client_state - {item} 

Answer 3

Wikipedia define idempotencia como una operación que:

se puede aplicar varias veces sin cambiar el resultado más allá de la aplicación inicial.

Tenga en cuenta que hablan sobre el result de la operación. Para mí, esto incluye ambos el estado del servidor y el código de respuesta.

La especificación HTTP es un poco más vaga al respecto. Es defines it especifica que los métodos HTTP son Idempotentes:

si el efecto deseado de varias solicitudes idénticas es el mismo que para una sola solicitud.

Si usted interpreta como effectresult en la definición de Wikipedia entonces ellos significan lo mismo. En cualquier caso, cuestiono el beneficio práctico de decirle a los clientes que el recurso ya se ha eliminado.

Punto final: Idempotence se define en términos de un único cliente. Una vez que comience a presentar solicitudes simultáneas de otros clientes, todas las apuestas están desactivadas. Se supone que debes utilizar encabezados de actualización condicional (como If-Match-ETag) para tratar estos casos.

Para reiterar: debe devolver el mismo código de retorno, si el recurso acaba de ser eliminado, fue eliminado por una solicitud anterior, o nunca existió en absoluto.