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étodo | Uso común | Seguro |
GET | Obtener recursos | Sí |
POST | Agregar recursos | No |
PUT | Modificar recursos | No |
PATCH | Modificar recursos | No |
DELETE | Eliminar recursos | No |
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 devolver412 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 devolver412 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.
Para comentar debe estar registrado.