Puede que se de el caso de que halles algún fallo en tu código o proyecto, recuerda probar siempre en un entorno de testing antes aplicar el código al proyecto final.
Solución:
¿Qué es la idempotencia en los métodos HTTP?
idempotencia es una propiedad de los métodos HTTP.
Se considera un método de solicitud idempotente si la intención efecto en el servidor de múltiples solicitudes idénticas con ese método es el mismo que el efecto para una sola solicitud de este tipo. Y vale la pena mencionar que la idempotencia se trata de la efecto producido en el estado del recurso en el servidor y no sobre el código de estado de respuesta recibido por el cliente.
Para ilustrar esto, considere la DELETE método, que se define como idempotente. Ahora considere que un cliente realiza una DELETE solicitud para eliminar un recurso del servidor. El servidor procesa la solicitud, el recurso se elimina y el servidor regresa 204. Luego el cliente repite lo mismo DELETE solicitud y, como el recurso ya ha sido eliminado, el servidor devuelve 404.
A pesar del código de estado diferente recibido por el cliente, el efecto producido por un solo DELETE solicitud es el mismo efecto de múltiples DELETE solicitudes a la misma URI.
Finalmente, las solicitudes con métodos idempotentes pueden repetirse automáticamente si ocurre una falla de comunicación antes de que el cliente pueda leer la respuesta del servidor. El cliente sabe que repetir la solicitud tendrá la mismo efecto deseadoincluso si la solicitud original tuvo éxito, aunque la respuesta puede ser diferente.
RFC 7231
Echemos un vistazo al RFC 7231, el documento define la semántica y el contenido del protocolo HTTP/1.1. Vea las citas a continuación (las más destacadas son mías).
Los métodos HTTP pueden ser a salvo:
4.2.1. Métodos seguros
Los métodos de solicitud se consideran “seguros” si su semántica definida es esencialmente de solo lectura; es decir, el cliente no solicita ni espera ningún cambio de estado en el servidor de origen como resultado de aplicar un método seguro a un recurso de destino. […]
Esta definición de métodos seguros no impide que una implementación incluya un comportamiento que sea potencialmente dañino, que no sea completamente de solo lectura o que cause efectos secundarios al invocar un método seguro. Sin embargo, lo importante es que el cliente no solicitó ese comportamiento adicional y no puede ser considerado responsable por ello. […]
De los métodos de solicitud definidos por esta especificación, el
GET,HEAD,OPTIONSyTRACElos métodos se definen como seguros. […]
y/o idempotente:
4.2.2. Métodos idempotentes
Un método de solicitud se considera “idempotente” si el efecto previsto en el servidor de varias 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,DELETEy los métodos de solicitud seguros son idempotentes. […]Al igual que la definición de caja fuerte, la propiedad idempotente solo se aplica a lo solicitado por el usuario; un servidor es libre de registrar cada solicitud por separado, conservar un historial de control de revisiones o implementar otros efectos secundarios no idempotentes para cada solicitud idempotente. […]
Resumiendo, los métodos HTTP se clasifican de la siguiente manera:
+---------+------+------------+
| Method | Safe | Idempotent |
+---------+------+------------+
| CONNECT | no | no |
| DELETE | no | yes |
| GET | yes | yes |
| HEAD | yes | yes |
| OPTIONS | yes | yes |
| POST | no | no |
| PUT | no | yes |
| TRACE | yes | yes |
+---------+------+------------+
RFC 5789
El RFC 5789 define el PATCH método, que es ni seguro ni idempotente. Sin embargo, para evitar colisiones, PATCH las solicitudes se pueden emitir de tal manera que sean idempotentes, como se cita a continuación:
A
PATCHLa solicitud se puede emitir de tal manera que sea idempotente, lo que también ayuda a evitar malos resultados de colisiones entre dosPATCHsolicitudes en el mismo recurso en un marco de tiempo similar. Colisiones de múltiplesPATCHlas solicitudes pueden ser más peligrosas quePUTcolisiones porque algunos formatos de parche necesitan operar desde un punto base conocido o, de lo contrario, corromperán el recurso. Los clientes que usan este tipo de aplicación de parche DEBERÍAN usar una solicitud condicional de modo que la solicitud falle si el recurso se actualizó desde la última vez que el cliente accedió al recurso. Por ejemplo, el cliente puede utilizar un fuerteETagen unIf-Matchencabezado en elPATCHsolicitud.
Según tengo entendido, la idempotencia no tiene nada que ver con el resultado (= Respuesta del servidor), sino con el estado del servidor después de una o varias llamadas.
Digamos que desea eliminar un recurso en el servidor llamando
DELETE /resource/123
La llamada mayo volver con una respuesta HTTP 200 OK y el recurso eliminado como carga útil en primer lugar. En una segunda llamada, la Respuesta será 204 NO_CONTENT ya que el recurso ya ha sido eliminado por la primera llamada.
Después de cada solicitud, el estado del servidor es el mismo, por lo tanto, se cumple la idempotencia. El HTTP/1.1 no dice nada sobre la respuesta.
Un método de solicitud se considera “idempotente” si el efecto previsto en el servidor de varias solicitudes idénticas con ese método es el mismo que el efecto de una sola solicitud de este tipo.
Sección de Reseñas y Valoraciones
Si piensas que te ha sido de provecho este post, sería de mucha ayuda si lo compartes con el resto desarrolladores de esta manera contrubuyes a dar difusión a nuestra información.