Idempotencia en el diseño de APIs

Share on facebook
Share on twitter
Share on linkedin

Dada la versatilidad y escalabilidad que ofrecen, la web de hoy en día está dotada de APIs. Casi cualquier cosa puede volverse una API, puesto que este mecanismo de comunicación da a los desarrolladores web reconocimiento. Sin embargo, existen diversas habilidades cruciales al desarrollar, no es únicamente poder programar una API, también es poder darle una arquitectura apropiada.

La medida de una buena API no sólo se basa en la tecnología, sino en lo que las personas pueden construir con ella

De todos los aspectos que debe de tener un buen diseño de una API, la fiabilidad y la seguridad son la clave; una API no fiable es una API inservible. Muy a menudo, la medida de una buena API no sólo se basa en la tecnología, sino en lo que las personas pueden construir con ella.

Entonces, ¿qué aspecto tienen la fiabilidad y la seguridad a nivel arquitectónico?

Idempotencia y seguridad

Las APIs basadas en REST sirven información por medio de peticiones HTTP que el cliente hace. Estas peticiones HTTP tienen un atributo denominado “seguridad”. Una petición HTTP es considerada segura si no modifica el estado de la aplicación cuando es llamado.

MétodoUso comúnSeguro
GETObtener recursos
POSTAgregar recursosNo
PUTModificar recursosNo
PATCHModificar recursosNo
DELETEEliminar recursosNo

A este punto puede que estés cuestionándote la importancia de estos atributos. Pues bien, considera el siguiente escenario: Imagina que estás navegando en el sitio web de tu institución bancaria, estás realizando una transferencia con una suma importante de dinero, pero por algún motivo tienes un fallo con tu conexión de internet, entonces presionas miles veces el botón de Enviar. Una vez restablecida la conexión, en el peor de los casos puedes llegar a ver tu cuenta en 0. Aquí es cuando entra en juego la idempotencia ¿Y qué es?

La idempotencia en el contexto de las APIs REST, quiere decir que cuando se realizan múltiples solicitudes idénticas, tiene el mismo efecto que hacer una sola solicitud. Para entender un poco mejor este concepto, imagina un método de tu API como una función matemática:

f(x) = x^2 + x

Si decimos que x = 2 tenemos que el resultado de f(x) es 6, si volvemos a realizar la operación con el mismo valor de x, el resultado seguirá siendo 6. Si se sigue los principios de REST en el diseño de la API, automáticamente se vuelven idempotentes los métodos GET, PUT y DELETE. Únicamente POST no lo será.

Implementación

Existen infinidad de maneras para hacer idempotentes nuestros métodos de la API, HTTP tiene incorporado funcionalidades que nos permite implementar y darle soporte de una manera sencilla (siempre y cuando sigamos al pie de la letra la arquitectura REST).

Algunas de estas funcionalidades son:

  • De lado del cliente darle soporte a la cabecera If-None-Match: * al momento de crear recursos, esto para evitar colisiones de identificadores y que el servidor pueda devolver 412 Precondition failed si la operación falla.
  • De lado del servidor darle soporte a la cabecera ETag: {etag-hash} en las respuestas de los métodos GET.
  • De lado del cliente darle soporte a la cabecera If-None-Match: * al momento de actualizar recursos, esto para evitar colisiones de contenido y que el servidor pueda devolver 412 Precondition failed si la operación falla.

Por otra parte, si nuestro proyecto requiere que hagamos nuestra propia implementación, uno de los mejores ejemplos del cual nos podemos guiar, es la forma de implementación que usa Stripe. Básicamente consiste en que nuestros clientes generen un set aleatorio de caracteres (o un identificador único como un UUID) y lo añadan a una cabecera en la petición al servidor, en el caso de Stripe, esta cabecera se llama Idempotency-Key.

Conclusiones

Muchas APIs REST no utilizan la idempotencia y esto no las vuelve inútiles, puesto que a veces la misma lógica de negocios no demanda hacerlo. Usualmente se usa en peticiones que modifiquen el estado de algo o cuando quieres tener certeza de que no se realice una acción dos veces por accidente. Casos de uso de implementación de estos atributos, donde son más que necesarios, es en APIs críticas, como lo son las bancarias, de cobro, etc.

Aunque nuestros proyectos actuales no demanden estas características, nunca está demás conocer y entender estos conceptos para siempre mejorar y poder aplicarlos en proyectos futuros.

Share on facebook
Share on twitter
Share on linkedin

No hay comentarios

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

¡Conozcámonos mejor!

Te haremos llegar las novedades de SoldAI, ofertas exclusivas, notificaciones, y mucho más.

¡Deja tu correo, tenemos mucho que contarte!