8.2.2. API de Websocket

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.

8.2.3. API de GraphQL

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.

8.2.4. API de SOAP

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.

8.2.5. API de REST

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.