Cuando realiza un pago en línea, espera que se procese sin tener que cargar su tarjeta dos veces. Si te cobra el doble, creará una experiencia de cliente negativa que podría alejarte del negocio para siempre. – calcular el valor de por vida de la empresa como cliente.
Si está del otro lado de esta transacción al crear una API de procesamiento de pagos, puede usar la idempotencia de la API para evitar tales problemas en primer lugar.
En este artículo, analizaremos las API idempotentes y por qué son importantes en la creación de una API REST. Si no sabe qué es la idempotencia cuando se trata de API, este artículo le brindará una gran perspectiva que puede ayudarlo a crear un mejor servicio al cliente en su sitio.
Introducción a la API REST idempotente
Como desarrollador, desea estar seguro de que cuando se envía una solicitud idéntica al servidor, se logra el resultado deseado sin cambiar el resultado final. La idea es construir API resilientes que puedan recuperarse efectivamente de un desastre. Eche un vistazo al proceso de llamada de API de ejemplo.
En el ejemplo anterior, el cliente realiza una llamada API al servidor. Cuando un cliente llama a la API «crear pago», podemos obtener una variedad de respuestas posibles, como éxito, falla, problemas de dependencia o ninguna respuesta. En este caso, recibimos un mensaje de «sin respuesta».
La solución natural al problema de «sin respuesta» es volver a intentar la llamada a la API. Por lo general, esta es una buena manera de darle al servidor algo de tiempo para solucionar problemas, como tratar con varias solicitudes simultáneamente. Pero, ¿cómo sabemos que la solicitud original para «crear un pago» no tuvo éxito en la oficina administrativa?
Cuando intentamos volver a llamar a la API y no obtenemos una respuesta, es posible que tengamos dos pagos diferentes cuando solo queríamos uno. Esto puede causar un problema. Queremos crear API sólidas que admitan el concepto de reintento automático. Para hacer esto, necesitamos hacer que nuestras API sean idempotentes.
¿Qué es una API idempotente?
Idempotente significa que la operación especificada se puede aplicar varias veces sin cambiar el resultado. Básicamente, es multiplicar un número por cero. No importa cuántas veces multipliques el número, el resultado seguirá siendo cero. Necesita cambiar la operación para cambiar el resultado.
En el ejemplo anterior, si llama repetidamente a «crear pago», aún debería recibir un pago. Este es el tipo de comportamiento que admite la operación idempotente.
¿Qué es una API REST idempotente?
Cuando el método HTTP es idempotente en la API REST, significa que si envía varias solicitudes idénticas, solo la solicitud inicial hará un cambio. Por lo tanto, los resultados devueltos al usuario no dependerán de cuántas veces se haya llamado al método.
Métodos HTTP idempotentes
Algunas API REST son naturalmente idempotentes mientras que otras no lo son. Para ser considerado idempotente, solo se considera el estado de back-end del servidor. La siguiente tabla muestra los métodos HTTP y su estado de idempotencia.
Como puede verse en la tabla API, POST y PATCH no son idempotentes. Por otro lado, HEAD, OPTIONS, GET, PUT, TRACE y DELETE son idempotentes. Echemos un vistazo más de cerca a cada uno de estos métodos para determinar la causa de su estado idempotente.
DESCARGAR | CABEZA | OPCIONES | APUNTAR
GET es idempotente porque es una operación de solo lectura y no provoca ningún cambio de estado en el backend. Si el punto final GET/Pago se activa por varias solicitudes idénticas, obtendrá la misma respuesta cada vez, como la primera vez.
El mismo principio se aplica a HEAD, OPTIONS y TRACE, ya que se utilizan para recuperar datos. Nunca cambian el estado de los recursos en el servidor.
OFICINA DE CORREOS
POST no es un método idempotente, ya que llamarlo repetidamente puede generar actualizaciones incorrectas. Normalmente, las API POST crean nuevos recursos en el servidor. Si se llama al extremo POST/Pago con un cuerpo de solicitud idéntico, creará varios registros. Para evitar esto, debe tener su propia lógica personalizada para evitar registros duplicados.
PONER
PUT es idempotente porque actualiza un registro. Si el extremo PUT/Pago se invoca con una solicitud idéntica, no provocará un cambio de estado más allá de la primera solicitud.
ELIMINAR
DELETE es idempotente porque las solicitudes similares posteriores no cambiarán el estado de eliminación. La primera llamada DELETE puede devolver 200 (ok), pero las llamadas DELETE adicionales probablemente devolverán 404 (Not Found). La respuesta es diferente después de la primera solicitud, pero no hay cambio de estado.
AÑOS
Patch no es un método idempotente, porque si realiza otra serie de operaciones de movimiento en un árbol JSON con la misma carga útil, por ejemplo, {«op»: «move», «from»: «/ tags / main», «path»: «/tags/sub ”}, el primero provocará la operación de movimiento, y el siguiente dará como resultado errores. A diferencia de PUT, que actualiza un registro completo, PATCH solo se puede usar para actualizar ciertos campos en un registro.
¿Por qué son importantes las API idempotentes?
Es importante que las API REST sigan pautas idempotentes, ya que se trata de un estándar industrial común. El usuario de sus API asumirá que sus puntos finales se comportan como estándar. Las API admiten la idempotencia para volver a intentar las solicitudes de forma segura sin realizar accidentalmente la misma operación dos veces. Ahora, si sus compañeros dicen que necesita crear un punto final idempotente, sabrá exactamente de lo que están hablando.
