Interfaces de Programación de Aplicaciones (API)
Interfaces de Programación de Aplicaciones (API)
Una de las principales amenazas para la seguridad de las Interfaces de Programación de Aplicaciones (APIs, por sus siglas en inglés) es la filtración de datos. La cual representa un desafío crítico a las posibles pérdidas de información, el riesgo de daño a la reputación y las consecuencias regulatorias asociadas. Estas filtraciones se producen cuando los datos sensibles, como la información personal, se expone involuntariamente a los usuarios no autorizados. Según International Business Machines, IBM por sus siglas en inglés (2023), una filtración de datos se refiere específicamente a violaciones de seguridad que comprometen la confidencialidad de la información. Por otro lado, el Instituto Ponemon (2022) define una filtración de datos como un incidente que puede involucrar a empleados o contratistas descuidados o negligentes, criminales o insiders maliciosos, o ladrones de credenciales.
Para entender que es una API, se explica por medio de cliente y servidor. De acuerdo con Reyes (2023), un cliente es un dispositivo o programa que accede a un recurso proporcionado por un servidor. El cliente puede ser una aplicación, una IA (Inteligencia Artificial), el IoT (Internet of Things) o cualquier otro tipo de sistema o componente que utiliza la API para acceder a sus recursos. La API recibe la petición y la procesa, y luego envía una respuesta al cliente. El cliente regularmente está relacionado con la interfaz del usuario y su interacción.
El servidor es la aplicación que proporciona los recursos que la API expone. Puede ser una aplicación, una base de datos, la nube, una IA o cualquier otro tipo de sistema o componente que proporciona acceso a sus recursos. Postman (2023) se refiere al servidor como el que recibe peticiones de los clientes de la API y responde a esas peticiones proporcionando los datos o realizando las operaciones que el cliente solicita.
Según RedHat (2023), los Webhooks (también conocidos como APIs inversas o APIs push) en esta arquitectura el que se encarga de la comunicación es el servidor, en vez del cliente. El servidor envía al cliente una solicitud única de HTTP cuando los datos están disponibles, en lugar de que el cliente le envíe solicitudes HTTP hasta que responda. Es un patrón de diseño que permite la comunicación entre dos aplicaciones a través de eventos. Singh (2021), destaca que los Webhooks suelen actuar como mensajeros de datos más pequeños. Un Webhook ayuda a enviar/extraer actualizaciones en tiempo real. La Figura 1 representa la interacción que tiene un Webhook con el servidor y el cliente.
Figura 1 Webhook
Fuente: Elaboración propia (Álvarez, 2024)
De acuerdo con MDN Web Docs (2023), la API de WebSocket es una tecnología avanzada que permite abrir una sesión de comunicación interactiva bidireccional entre el cliente y el servidor. Es un protocolo de comunicación bidireccional que permite a los clientes y servidores intercambiar datos en tiempo real. Se basa en el protocolo HTTP, pero utiliza un subprotocolo especial para negociar una conexión persistente entre el cliente y el servidor. Ionos (2020), destaca que el cliente debe establecer una conexión con el servidor, que se confirma mediante el llamado apretón de manos o WebSocket Protocol Handshake.
La arquitectura WebSocket puede entenderse como un canal de comunicación abierto, en el cual queda abierta una conexión activa tras el handshake inicial entre el cliente y el servidor. Así, el servidor también puede enviar información nueva al cliente sin que este tenga que solicitarlo previamente cada vez. Las conexiones WebSocket son bidireccionales, lo que significa que los clientes y los servidores pueden enviar mensajes entre sí en cualquier momento. Esto permite a los clientes y servidores intercambiar datos en tiempo real, sin tener que esperar a que el servidor responda a una solicitud. La Figura 2 muestra la arquitectura WebSocket.
Figura 2 Websocket
Fuente: Elaboración propia (Álvarez, 2024)
Según la documentación oficial de GraphQL (2024), GraphQL es un lenguaje de consulta para la API y un tiempo de ejecución del lado del servidor para ejecutar consultas mediante un sistema de tipos que es definido para los datos. GraphQL se utiliza para diseñar y construir APIs que proporcionan una forma más precisa y eficiente de solicitar y entregar datos en comparación con las arquitecturas tradicionales. El cliente envía una consulta a la API, la consulta especifica los datos que el cliente necesita, así como la estructura en la que se deben devolver los datos. El servidor de la API utiliza el esquema de GraphQL para interpretar la consulta y devolver los datos solicitados. La Figura 3 muestra la arquitectura de GraphQL.
Figura 3 GraphQL
Fuente: Elaboración propia (Álvarez, 2024)
Amazon (2023), señala que SOAP (Simple Object Access Protocol) es un protocolo que define reglas de comunicación rígidas. Tiene varios estándares asociados que controlan todos los aspectos del intercambio de datos. Es un protocolo de mensajería que se utiliza para intercambiar información entre sistemas. Se basa en XML (eXtensible Markup Language) para el intercambio de datos y utiliza HTTP como protocolo de transporte. De acuerdo con el W3C (2007), SOAP utiliza tecnologías XML para definir un marco de mensajería que proporciona una construcción de mensajes que pueden ser intercambiados a través de una variedad de protocolos subyacentes. SOAP utiliza un mensaje para intercambiar información entre dos sistemas. El mensaje consta de los siguientes elementos:
1. Sobre: Es el elemento raíz del mensaje. Contiene información, como el emisor, el receptor, y el tipo de mensaje.
2. Encabezado: Es una sección opcional del mensaje. Se utiliza para transmitir información adicional, como información de seguridad o información de control de flujo.
3. Cuerpo o Contenido: Es la sección principal del mensaje. Contiene los datos que se están intercambiando entre los sistemas.
La arquitectura REST (Representational State Transfer) fue desarrollada por Roy Fielding en su tesis doctoral en el año 2000 y se ha convertido en un enfoque ampliamente utilizado para diseñar sistemas web escalables y flexibles. Es un conjunto de guías para diseñar APIs. Comúnmente se denomina arquitectura y con base en Fielding (2000), esta arquitectura se basa en 6 restricciones:
1. Cliente-Servidor: Separación de responsabilidades, la API debe estar separada del cliente.
2. Sin Estado: Cada petición contiene toda la información necesaria para que el servidor la procese. El estado de sesión del usuario se mantiene en el cliente.
3. Cache: Las respuestas de la API se pueden almacenar en caché de forma implícita, explícita y/o negociable.
4. Interfaz Uniforme: La petición deberá identificar los recursos que está buscando (a través de una URL). La manipulación de recursos a través de la representación. Un cliente REST necesita poco o ningún conocimiento previo sobre cómo interactuar con una API.
5. Sistema de Capas: Los servicios REST están orientados a la escalabilidad y el cliente no sabe si la petición se realiza directamente a un servidor, un sistema de cachés, o un balanceador que se encarga de redirigirlo hacía un servidor final. El cliente solo envía una petición y recibe una respuesta.
6. Código Bajo Demanda: El servidor puede extender o personalizar temporalmente la funcionalidad del cliente mediante la transferencia de lógica.
Aunque las APIs funcionan a través de internet, no es obligatorio que funcionen con el protocolo HTTP. Se denominan RESTful cuando además de adherirse a las restricciones REST también funcionan con el protocolo HTTP. La Figura 4 muestra la arquitectura de REST.
Figura 4 REST
Fuente: Elaboración propia (Álvarez, 2024)
Las API (Interfaces de Programación de Aplicaciones) han revolucionado la forma en que las aplicaciones y sistemas se comunican entre sí, convirtiéndose en componentes esenciales en la arquitectura de software moderna. Su capacidad para conectar datos y servicios de manera estandarizada y modular ha impulsado la innovación digital en diversos sectores, desde el comercio electrónico y las finanzas hasta la atención médica y la fabricación.
Reyes, D. J. M. (2023, marzo 26). Todo lo que necesitas saber sobre API Rest: Glosario de términos esenciales y más. DEV Community. https://dev.to/dennysjmarquez/todo-lo-que-necesitas-saber-sobre-api-rest-glosario-de-terminos-esenciales-y-mas-29pc
Dindi, S. (2021, julio 7). 6 tipos de arquitecturas API y cómo funcionan. io-max. https://io-max.one/6-tipos-de-arquitecturas-api-y-como-funcionan/
2023 State of the API report. (s/f). Postman API Platform. Recuperado el 19 de enero de 2024, de https://www.postman.com/state-of-api/
Singh, G. (2021, noviembre 11). Webhooks or an API - A complete Webhook vs API guide with examples. Verloop.Io. https://verloop.io/blog/webhook-or-an-api/
The WebSocket API (WebSockets). (s/f). MDN Web Docs. Recuperado el 19 de enero de 2024, de https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
¿Qué es WebSocket? (2020, agosto 7). IONOS Digital Guide; IONOS. https://www.ionos.mx/digitalguide/paginas-web/desarrollo-web/que-es-websocket/
GraphQL. (s/f). Graphql.org. Recuperado el 14 de diciembre de 2023, de https://graphql.org/
Introduction to GraphQL. (s/f). Graphql.org. Recuperado el 19 de enero de 2024, de https://graphql.org/learn/
(S/f-c). Amazon.com. Recuperado el 19 de enero de 2024, de https://aws.amazon.com/es/compare/the-difference-between-soap-rest/
SOAP version 1.2 part 1: Messaging framework (second edition). (s/f). Www.w3.org. Recuperado el 19 de enero de 2024, de https://www.w3.org/TR/soap12-part1/
Fielding Dissertation: Abstract. (s/f). Uci.edu. Recuperado el 30 de junio de 2023, de https://www.ics.uci.edu/~fielding/pubs/dissertation/abstract.htm
What is a REST API? Examples, uses & challenges. (2023, junio 28). Postman Blog; Postman. https://blog.postman.com/rest-api-examples/