Eliminar un recurso usando http DELETE

Entonces, dado que el verbo DELETE en Http es idempotente, cuando publico la siguiente solicitud, ¿qué debería pasar con el segundo (o tercero, o cuarto, etc.)?

DELETE /person/123

La primera vez, el recurso se elimina y devuelvo un 204 (exitoso, sin contenido). ¿Debo devolver un 204 en llamadas posteriores o un 404 (no encontrado)?

Como las solicitudes HTTP en un sistema sin estado deberían ser independientes, los resultados de una solicitud no deberían depender de una solicitud anterior. Considere lo que debería suceder si dos usuarios hicieron una ELIMINACIÓN en el mismo recurso simultáneamente. Tiene sentido que la segunda solicitud obtenga un 404. Lo mismo debería ser cierto si un usuario realiza dos solicitudes.

Supongo que tener DELETE devolver dos respuestas diferentes no te parece idempotente. Me resulta útil pensar que las solicitudes idempotentes dejan el sistema en el mismo estado y no necesariamente tienen la misma respuesta. Por lo tanto, independientemente de si ELIMINA un recurso existente o si intenta ELIMINAR un recurso que no existe, el estado del recurso del servidor es el mismo.

El libro de cocina de servicios web RESTful es un gran recurso para esto. Por casualidad, su vista previa de Google muestra la página sobre ELIMINAR (página 11):

El método DELETE es idempotente. Esto implica que el servidor debe devolver el código de respuesta 200 (OK) incluso si el servidor eliminó el recurso en una solicitud anterior. Pero en la práctica, la implementación de DELETE como una operación idempotente requiere que el servidor realice un seguimiento de todos los recursos eliminados. De lo contrario, puede devolver un 404 (no encontrado).

Estoy de acuerdo con lo que dice la respuesta elegida actual, que la 2da (y 3ra, 4ta, ...) BORRAR debería obtener un 404 . Y noté que la respuesta tiene 143 votos positivos, pero también tiene un comentario opuesto que tiene 54 votos positivos, por lo que la comunidad se divide en 2 campos en una proporción aproximada de 3: 1. Aquí viene más información para resolver este largo debate.

1. En primer lugar, NO comencemos con lo que "yo" pienso, lo que "tú" piensas o lo que piensa otro autor del libro. Comencemos con las especificaciones HTTP, es decir, RFC 7231.

   • RFC 7231, sección 4.3.5 DELETE solo mencionó que una respuesta exitosa debería ser 2xx, pero no mencionó lo que obtendría un DELETE posterior. Así que profundicemos más.
   • RFC 7231, sección 6.5.4 404 No encontrado dice que la respuesta 404 es para un recurso que no existe. Dado que ningún método http específico (en particular, no ELIMINAR) se llama para ser tratado de otra manera, intuitivamente podemos tener una impresión (y con razón) de que mi solicitud DELETE /some/resource/which/does/not/existdebe dar como resultado un 404. Luego,DELETE /some/resource/which/happened/to/be/removed/by/someone/else/five/days/ago podría devolver un 404 Entonces, ¿por qué debería DELETE /some/resource/i/deleted/five/seconds/agoser diferente? "¡¿Pero qué hay de la idempotencia ?!", puedo escuchar que estás gritando eso. Espera, estamos a punto de entrar en eso.

   • Históricamente, RFC 2616, publicado en 1999, era la especificación HTTP 1.1 más referenciada. Lamentablemente, su descripción sobre la idempotencia fue vaga , lo que deja espacio para todos estos debates. Pero esas especificaciones han sido reemplazadas por RFC 7231. Citado de RFC 7231, sección 4.2.2 Métodos idempotentes , énfasis mío:

     Un método de solicitud se considera "idempotente" si el EFECTO pretendido en el servidor de múltiples solicitudes idénticas con ese método es el mismo que el efecto de una sola solicitud de este tipo. De los métodos de solicitud definidos por esta especificación, PUT, DELETE y los métodos de solicitud seguros son idempotentes .

     Entonces, está escrito en las especificaciones, la idempotencia se trata del efecto en el servidor. El primer DELETE que devuelve un 204 y luego el DELETE posterior que devuelve 404, un código de estado diferente NO hace que el DELETE sea no idempotente. Usar este argumento para justificar un retorno 204 posterior es simplemente irrelevante.

2. Bien, entonces no se trata de idempotencia. Pero entonces una pregunta de seguimiento puede ser, ¿qué pasa si todavía elegimos usar 204 en la SUPRIMACIÓN posterior? ¿Está bien?

   Buena pregunta. La motivación es comprensible: permitir que el cliente alcance el resultado deseado, sin preocuparse por el manejo de errores. Yo diría que devolver 204 en DELETE posterior, es una "mentira piadosa" del lado del servidor en gran parte inofensiva, que el lado del cliente no notará inmediatamente una diferencia. Es por eso que hay ~ 25% de personas haciendo eso en la naturaleza y aparentemente todavía funciona. Solo tenga en cuenta que dicha mentira puede considerarse semánticamente extraña, porque GET /non-existdevuelve 404 pero DELETE /non-existda 204, en ese momento el cliente descubriría que su servicio no cumple completamente con la sección 6.5.4 404 No encontrado .

   Pero quiero señalar que, la forma prevista por RFC 7231, es decir, devolver 404 en DELETE posterior, no debería ser un problema en primer lugar. Tres veces más desarrolladores decidieron hacer eso, ¿alguna vez escuchaste un incidente importante o una queja causada por un cliente que no puede manejar 404? Presumiblemente, no, y eso se debe a que cualquier cliente decente que implemente HTTP DELETE (o cualquier método HTTP, para el caso), no asumiría ciegamente que el resultado siempre sería exitoso 2xx. Y luego, una vez que el desarrollador comience a considerar el manejo de errores, 404 Not Found sería uno de los primeros errores que se le ocurra. En ese punto, él / ella probablemente sacaría una conclusión de que, es semánticamente seguro para una operación DELETE HTTP ignorar un error 404. Y lo hicieron así.

Problema resuelto.

Primer BORRAR : 200 o 204.

DELETES posteriores : 200 o 204.

Justificación : ELIMINAR debe ser idempotente. Si devuelve 404 en un segundo DELETE, su respuesta cambiará de un código de éxito a un código de error . El programa cliente puede tomar acciones incorrectas en base a la suposición de que DELETE falló.

Ejemplo :

• Suponga que su operación DELETE es parte de una operación de varios pasos (o una "saga") ejecutada por el programa cliente.
• El programa cliente puede ser una aplicación móvil que realice una transacción bancaria, por ejemplo.
• Digamos que el programa cliente tiene un reintento automático para una operación DELETE (tiene sentido, porque DELETE se supone que es idempotente).
• Digamos que el primer DELETE se ejecutó con éxito, pero la respuesta 200 se perdió en su camino hacia el programa cliente.
• El programa cliente reintentará ELIMINAR.
• Si el segundo intento devuelve 404, el programa cliente puede cancelar la operación general debido a este código de error.
• Pero debido a que el primer DELETE se ejecutó con éxito en el servidor, el sistema puede quedar en un estado inconsistente .
• Si el segundo intento devuelve 200 o 204, el programa cliente continuará como se esperaba.

Solo para ilustrar el uso de este enfoque, la guía de estilo HTTP API para PayPal tiene la siguiente directriz:

ELIMINAR: Este método DEBE devolver el código de estado 204 ya que no hay necesidad de devolver ningún contenido en la mayoría de los casos, ya que la solicitud es eliminar un recurso y se eliminó con éxito.

Como el método DELETE también DEBE ser idempotente, DEBE devolver 204, incluso si el recurso ya se ha eliminado. Por lo general, al consumidor de API no le importa si el recurso se eliminó como parte de esta operación o antes. Esta es también la razón por la cual 204 en lugar de 404 deben ser devueltos.