La hoja de trucos de diseño del sistema: estilos de API: REST, GraphQL, WebSocket, Webhook, RPC/gRPC, SOAP

Esta es una continuación de una serie de artículos en los que cubro brevemente los puntos principales de un tema específico en el diseño de arquitectura de sistemas. El primer artículo se puede leer aquí. La arquitectura API se refiere al conjunto de reglas, protocolos y herramientas que dictan cómo deben interactuar los componentes del software. La arquitectura de una API no se trata sólo de facilitar la comunicación; también se trata de garantizar que esta comunicación sea eficiente, segura y escalable. Una arquitectura API bien diseñada puede mejorar significativamente el rendimiento de un sistema, mientras que una mal diseñada puede provocar cuellos de botella, vulnerabilidades de seguridad y pesadillas de mantenimiento. Diferentes estilos de arquitectura API Los estilos de diseño de API más comunes: (Transferencia de estado representacional) es el estilo más utilizado que utiliza métodos estándar y protocolos HTTP. Se basa en principios como la apatridia, la arquitectura cliente-servidor y la capacidad de caché. A menudo se utiliza entre clientes de front-end y servicios de back-end. REST es un lenguaje de consulta para API. A diferencia de REST, que expone un conjunto fijo de puntos finales para cada recurso, GraphQL permite a los clientes solicitar exactamente los datos que necesitan, lo que reduce la recuperación excesiva. GraphQL es un protocolo que permite la comunicación bidireccional a través de TCP. Los clientes utilizan sockets web para obtener actualizaciones en tiempo real de los sistemas back-end. WebSocket es un mecanismo que permite a un sistema notificar a otro sistema sobre eventos específicos en tiempo real. Es una devolución de llamada HTTP definida por el usuario. Webhook es un protocolo que un servicio puede utilizar para solicitar un procedimiento/método de un servicio ubicado en otra computadora en una red. Por lo general, está diseñado para comunicaciones de alta velocidad y baja latencia. RPC (gRPC) es un protocolo para el intercambio de información estructurada para implementar servicios web. Se basa en XML y es conocido por su solidez y características de seguridad, actualmente considerado un protocolo heredado. SOAP Veamos cada protocolo por separado con todos sus pros, contras y casos de uso. DESCANSAR es un estilo arquitectónico que utiliza convenciones y protocolos estándar, lo que lo hace fácil de entender e implementar. Su naturaleza sin estado y el uso de métodos HTTP estándar lo convierten en una opción popular para crear API basadas en web. REST Si bien REST ha sido el estándar de facto para crear API durante mucho tiempo, han surgido otros estilos como GraphQL, que ofrecen diferentes paradigmas para consultar y manipular datos. : XML, JSON, HTML, texto sin formato Formato : HTTP/HTTPS Protocolo de transporte Conceptos y características clave : En REST, todo es un recurso. Un recurso es un objeto con un tipo, datos asociados, relaciones con otros recursos y un conjunto de métodos que operan sobre él. Los recursos se identifican por sus URI (normalmente una URL). Recurso : los servicios REST a menudo se asignan directamente a operaciones CRUD (Crear, Leer, Actualizar, Eliminar) en recursos. Operaciones CRUD : los sistemas REST utilizan métodos HTTP estándar: Métodos HTTP OBTENER: Recuperar un recurso. PUBLICAR: Crea un nuevo recurso. PUT/PATCH: actualiza un recurso existente. ELIMINAR: Eliminar un recurso. : las API REST utilizan códigos de estado HTTP estándar para indicar el éxito o el fracaso de una solicitud de API: Códigos de estado 2xx - Reconocimiento y Éxito 200-bien 201 - Creado 202 - Aceptado 3xx - Redirección 301 Movido Permanentemente 302 - Encontrado 303 - Ver Otros 4xx - Error del cliente 400 Petición Incorrecta 401 - No autorizado 403 - Prohibido 404 No encontrado 405 - Método no permitido 5xx - Error del servidor Error interno de servidor 500 501 - No implementado 502 Puerta de enlace no válida 503 Servicio no Disponible 504 - Tiempo de espera de puerta de enlace : cada solicitud de un cliente a un servidor debe contener toda la información necesaria para comprender y procesar la solicitud. El servidor no debe almacenar nada sobre el estado del cliente entre solicitudes. Sin estado : REST se basa en el modelo cliente-servidor. El cliente es responsable de la interfaz y la experiencia del usuario, mientras que el servidor es responsable de procesar solicitudes, manejar la lógica empresarial y almacenar datos. Cliente-Servidor : el cliente puede almacenar en caché las respuestas del servidor. El servidor debe indicar si una respuesta se puede almacenar en caché o no. Almacenable en caché : un cliente normalmente no puede saber si está conectado directamente al servidor final o a un intermediario. Los servidores intermediarios pueden mejorar la escalabilidad del sistema al permitir el equilibrio de carga y proporcionar cachés compartidos. Sistema en capas Hypermedia As The Engine Of Application Stat es un principio de servicio web REST que permite a los clientes interactuar y navegar a través de una aplicación web basándose completamente en el hipermedia proporcionado dinámicamente por el servidor en sus respuestas, promoviendo un acoplamiento flexible y la capacidad de descubrimiento. HATEOAS: Casos de uso : muchos servicios web exponen su funcionalidad a través de API REST, lo que permite a los desarrolladores externos integrar y ampliar sus servicios. Servicios web : las aplicaciones móviles a menudo se comunican con servidores backend mediante API REST para recuperar y enviar datos. Aplicaciones móviles : las SPA utilizan API REST para cargar contenido dinámicamente sin necesidad de actualizar la página completa. Aplicaciones de página única (SPA) los sistemas dentro de una organización pueden comunicarse y compartir datos mediante API REST. Integración entre sistemas: Ejemplo Pedido OBTENER “/usuario/42” Respuesta { "id": 42, "name": "Alex", "links": { "role": "/user/42/role" } } GrafoQL ofrece un enfoque más flexible, sólido y eficiente para crear API, especialmente en sistemas complejos o cuando la interfaz necesita una gran flexibilidad. Transfiere parte de la responsabilidad del servidor al cliente, permitiéndole al cliente especificar sus requisitos de datos. GraphQL Si bien no reemplaza a REST en todos los escenarios, ofrece una alternativa convincente en muchas situaciones, particularmente a medida que las aplicaciones se vuelven más conectadas en red y distribuidas. : JSON Formato : HTTP/HTTPS Protocolo de transporte Conceptos y características clave : permite a los clientes solicitar los datos que necesitan, haciendo posible obtener toda la información requerida en una sola solicitud. Lenguaje de consulta para API : las API GraphQL están organizadas en términos de tipos y campos, no de puntos finales. Utiliza un sistema de tipos sólido para definir las capacidades de una API. Todos los tipos expuestos en una API se escriben en un esquema utilizando el lenguaje de definición de esquemas (SDL) GraphQL. Sistema de tipos : a diferencia de REST, donde puede tener múltiples puntos finales para diferentes recursos, en GraphQL, normalmente expone un único punto final que expresa el conjunto completo de capacidades del servicio. Punto final único : en el lado del servidor, los resolutores recopilan los datos descritos en una consulta. Resolutores : más allá de solo consultar datos, GraphQL incluye soporte integrado para actualizaciones en tiempo real mediante suscripciones. Actualizaciones en tiempo real con suscripciones : se puede consultar un servidor GraphQL para conocer los tipos que admite. Esto crea un contrato sólido entre el cliente y el servidor, lo que permite herramientas y una mejor validación. Introspectivo Casos de uso : para aplicaciones (especialmente móviles) con ancho de banda crucial, desea minimizar los datos obtenidos del servidor. Frontends flexibles : se puede introducir una capa GraphQL para agregar los datos de estos servicios en una API unificada si tiene varios microservicios. Agregación de microservicios : con su sistema de suscripción, GraphQL puede ser una excelente opción para aplicaciones que necesitan datos en tiempo real, como aplicaciones de chat, actualizaciones de deportes en vivo, etc. Aplicaciones en tiempo real : con REST, a menudo necesitas versionar tus API una vez que se introducen los cambios. Con GraphQL, los clientes solo solicitan los datos requeridos, por lo que agregar nuevos campos o tipos no crea cambios importantes. API sin versión Ejemplo Pedido OBTENER “/graphql?query=user(id:42){ nombre rol {id nombre } }” Respuesta { "data": { "user": { "id": 42, "name": "Alex", "role": { "id": 1, "name": "admin" } } } } WebSocket proporciona un canal de comunicación full-duplex a través de una única conexión de larga duración, lo que permite el intercambio de datos en tiempo real entre un cliente y un servidor. Esto lo hace ideal para aplicaciones web interactivas y de alto rendimiento. WebSockets : binario Formato : TCP Protocolo de transporte Conceptos y características clave : a diferencia del modelo tradicional de solicitud-respuesta, WebSockets proporciona un canal de comunicación full-duplex que permanece abierto, lo que permite el intercambio de datos en tiempo real. Conexión persistente : los WebSockets comienzan como una solicitud HTTP, que luego se actualiza a una conexión WebSocket si el servidor lo admite. Esto se hace a través del encabezado "Actualizar". Upgrade Handshake : una vez establecida la conexión, los datos se transmiten como marcos. A través de estos marcos se pueden enviar tanto texto como datos binarios. Marcos : WebSockets permite la comunicación directa entre el cliente y el servidor sin la sobrecarga de abrir una nueva conexión para cada intercambio. Esto da como resultado un intercambio de datos más rápido. Baja latencia : tanto el cliente como el servidor pueden enviarse mensajes entre sí de forma independiente. Bidireccional : después de la conexión inicial, las tramas de datos requieren menos bytes para enviarse, lo que genera menos gastos generales y un mejor rendimiento que el establecimiento repetido de conexiones HTTP. Menos gastos generales : WebSockets admite subprotocolos y extensiones, lo que permite protocolos estandarizados y personalizados además del protocolo WebSocket base. Protocolos y extensiones Casos de uso : juegos multijugador en tiempo real donde las acciones de los jugadores deben reflejarse inmediatamente en otros jugadores. Juegos en línea : aplicaciones como Google Docs, donde varios usuarios pueden editar un documento simultáneamente y ver los cambios de los demás en tiempo real. Herramientas colaborativas : plataformas de negociación de acciones donde los precios de las acciones deben actualizarse en tiempo real. Aplicaciones financieras : cualquier aplicación donde los usuarios necesiten recibir notificaciones en tiempo real, como plataformas de redes sociales o aplicaciones de mensajería. Notificaciones : sitios web de noticias o plataformas de redes sociales donde las nuevas publicaciones o actualizaciones se transmiten en vivo a los usuarios. Live Feeds Ejemplo Pedido OBTENER “ws://sitio:8181” Respuesta HTTP/1.1 101 protocolos de conmutación gancho web es una devolución de llamada HTTP definida por el usuario activada por eventos de aplicaciones web específicos, que permite actualizaciones de datos en tiempo real e integraciones entre diferentes sistemas. Webhook : XML, JSON, texto sin formato Formato : HTTP/HTTPS Protocolo de transporte Conceptos y características clave : los webhooks se utilizan normalmente para indicar que ha ocurrido un evento. En lugar de solicitar datos a intervalos regulares, los webhooks proporcionan datos a medida que ocurren, poniendo patas arriba el modelo tradicional de solicitud-respuesta. Basado en eventos : los webhooks son esencialmente un mecanismo de devolución de llamada definido por el usuario. Cuando ocurre un evento específico, el sitio de origen realiza una devolución de llamada HTTP al URI proporcionado por el sitio de destino, que luego realizará una acción específica. Mecanismo de devolución de llamada : cuando se activa el webhook, el sitio de origen enviará datos (carga útil) al sitio de destino. Estos datos suelen estar en formato JSON o XML. Carga útil : los webhooks permiten que las aplicaciones obtengan datos en tiempo real, lo que las hace altamente receptivas. Tiempo real : los usuarios o desarrolladores normalmente pueden definir sobre qué eventos específicos desean recibir notificaciones. Personalizable : dado que los webhooks implican realizar devoluciones de llamadas a puntos finales HTTP definidos por el usuario, pueden plantear desafíos de seguridad. Es fundamental garantizar que el punto final sea seguro, que los datos estén validados y posiblemente cifrados. Seguridad Casos de uso : activación de compilaciones e implementaciones cuando se envía código o se fusiona una solicitud de extracción. Integración e implementación continuas (CI/CD) : Notifica a los sistemas posteriores cuando se actualiza, publica o elimina contenido. Sistemas de gestión de contenidos (CMS) : informar a las plataformas de comercio electrónico sobre los resultados de las transacciones, como pagos exitosos, transacciones fallidas o reembolsos. Pasarelas de pago : recibir notificaciones sobre nuevas publicaciones, menciones u otros eventos relevantes en plataformas de redes sociales. Integraciones de redes sociales : los dispositivos o sensores pueden activar webhooks para notificar a otros sistemas o servicios sobre eventos específicos o lecturas de datos. IoT (Internet de las cosas) Ejemplo Pedido OBTENER " " https://sitio-externo/webhooks?url=http://sitio/servicio-h/api&name=nombre Respuesta { "webhook_id": 12 } RPC y gRPC (llamada a procedimiento remoto) es un protocolo que permite a un programa ejecutar un procedimiento o subrutina en otro espacio de direcciones, lo que permite una comunicación e intercambio de datos fluidos entre sistemas distribuidos. RPC (Google RPC) es un marco moderno de código abierto creado sobre RPC que utiliza HTTP/2 para el transporte y búferes de protocolo como lenguaje de descripción de la interfaz, lo que proporciona características como autenticación, equilibrio de carga y más para facilitar una comunicación eficiente y sólida. entre microservicios. gRPC RPC : JSON, XML, Protobuf, Thrift, FlatBuffers Formato : Varios Protocolo de transporte Conceptos y características clave : RPC permite que un programa haga que un procedimiento (subrutina) se ejecute en otro espacio de direcciones (comúnmente en otra computadora en una red compartida). Es como llamar a una función realizada en una máquina diferente a la de quien llama. Definición : en el contexto de RPC, los stubs son fragmentos de código generados por herramientas que permiten que las llamadas a procedimientos locales y remotos aparezcan iguales. El cliente tiene un código auxiliar que se parece al procedimiento remoto y el servidor tiene un código auxiliar que descomprime los argumentos, llama al procedimiento real y luego empaqueta los resultados para enviarlos de regreso. Stubs : las llamadas RPC tradicionales se bloquean, lo que significa que el cliente envía una solicitud al servidor y se bloquea esperando una respuesta del servidor. Síncrono de forma predeterminada : muchos sistemas RPC permiten que diferentes implementaciones de cliente y servidor se comuniquen independientemente del idioma en el que estén escritos. Idioma neutro : RPC a menudo requiere que el cliente y el servidor conozcan el procedimiento que se llama, sus parámetros y su tipo de retorno. Acoplamiento estrecho Casos de uso : RPC se usa comúnmente en sistemas distribuidos donde partes de un sistema están distribuidas en diferentes máquinas o redes pero necesitan comunicarse como si fueran locales. Sistemas distribuidos : NFS (sistema de archivos de red) es un ejemplo de RPC que realiza operaciones de archivos de forma remota. Sistemas de archivos de red Ejemplo Pedido { "method": "addUser", "params": [ "Alex" ] } Respuesta { "id": 42, "name": "Alex", "error": null } gRPC : Protobuf Formato : HTTP/2 Protocolo de transporte Conceptos y características clave : gRPC es un marco RPC de código abierto desarrollado por Google. Utiliza HTTP/2 para el transporte, Protocol Buffers (Protobuf) como lenguaje de descripción de la interfaz y proporciona autenticación, funciones de equilibrio de carga y más. Definición : este es un mecanismo extensible, neutral en cuanto al idioma y la plataforma para serializar datos estructurados. Con gRPC, usted define métodos de servicio y tipos de mensajes usando Protobuf. Búfers de protocolo : gRPC está diseñado para una comunicación de baja latencia y alto rendimiento. HTTP/2 permite multiplexar múltiples llamadas a través de una sola conexión y reduce la sobrecarga. Rendimiento : gRPC admite solicitudes y respuestas de streaming, lo que permite casos de uso más complejos, como conexiones de larga duración, actualizaciones en tiempo real, etc. Streaming : gRPC permite a los clientes especificar cuánto tiempo esperarán hasta que se complete un RPC. El servidor puede verificar esto y decidir si completar la operación o cancelarla si es probable que demore demasiado. Plazos/Tiempos de espera : gRPC está diseñado para admitir autenticación conectable, equilibrio de carga, reintentos, etc. Conectable : al igual que RPC, gRPC es independiente del idioma. Sin embargo, con Protobuf y las herramientas gRPC, es fácil generar código de cliente y servidor en varios idiomas. Idioma neutral Casos de uso : gRPC se usa comúnmente en arquitecturas de microservicios debido a sus características de rendimiento y su capacidad para definir contratos de servicios fácilmente. Microservicios : dado su soporte para transmisión, gRPC es adecuado para aplicaciones en tiempo real donde los servidores envían datos a los clientes en tiempo real. Aplicaciones en tiempo real : los beneficios de rendimiento y las capacidades de transmisión de gRPC lo convierten en una buena opción para los clientes móviles que se comunican con servicios backend. Clientes móviles Ejemplo message User { int id = 1 string name = 2 } service UserService { rpc AddUser(User) returns (User); } JABÓN , que significa Protocolo Simple de Acceso a Objetos, es un protocolo para intercambiar información estructurada para implementar servicios web en redes informáticas. Es un protocolo basado en XML que permite que los programas que se ejecutan en sistemas operativos diferentes se comuniquen entre sí. SOAP : XML Formato : HTTP/HTTPS, JMS, SMTP y más Protocolo de transporte Conceptos y características clave : los mensajes SOAP tienen formato XML y contienen los siguientes elementos: Basado en XML : el elemento raíz de un mensaje SOAP que define el documento XML como un mensaje SOAP. Sobre : contiene cualquier atributo opcional del mensaje utilizado en el procesamiento del mensaje, ya sea en un punto intermedio o en el punto final final. Encabezado : Contiene los datos XML que componen el mensaje que se envía. Cuerpo : elemento de fallo opcional que proporciona información sobre errores durante el procesamiento del mensaje. Fallo : SOAP se puede utilizar con cualquier modelo de programación y no está vinculado a uno específico. Neutralidad : Puede ejecutarse en cualquier sistema operativo y en cualquier idioma. Independencia : cada solicitud de un cliente a un servidor debe contener toda la información necesaria para comprender y procesar la solicitud. Sin estado : el elemento Fault en un mensaje SOAP se utiliza para informar errores. Manejo de errores incorporado : funciona según estándares bien definidos, incluida la propia especificación SOAP, así como estándares relacionados como WS-ReliableMessaging para garantizar la entrega de mensajes, WS-Security para la seguridad de los mensajes y más. Estandarizado Casos de uso : SOAP se utiliza a menudo en entornos empresariales debido a su solidez, extensibilidad y capacidad para atravesar firewalls y servidores proxy. Aplicaciones empresariales : muchos servicios web, especialmente los más antiguos, utilizan SOAP. Esto incluye servicios ofrecidos por grandes empresas como Microsoft e IBM. Servicios web : la seguridad y extensibilidad integradas de SOAP lo convierten en una buena opción para transacciones financieras, donde la integridad y seguridad de los datos son primordiales. Transacciones financieras : las empresas de telecomunicaciones pueden utilizar SOAP para procesos como la facturación, donde diferentes sistemas deben comunicarse de manera confiable. Telecomunicaciones Ejemplo Pedido Alex Respuesta 42 Alex Conclusión El panorama de los estilos de arquitectura API es diverso y ofrece varios enfoques como REST, SOAP, RPC y más, cada uno con fortalezas y casos de uso únicos, lo que permite a los desarrolladores elegir el paradigma más adecuado para crear integraciones escalables, eficientes y sólidas entre diferentes software. componentes y sistemas.