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:

1. REST (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.

   
   

2. GraphQL 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.

   
   

3. WebSocket 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.

   
   

4. Webhook 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.

   
   

5. RPC (gRPC) 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.

   
   

6. SOAP 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.

Veamos cada protocolo por separado con todos sus pros, contras y casos de uso.

DESCANSAR

REST 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.

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.

Formato : XML, JSON, HTML, texto sin formato

Protocolo de transporte : HTTP/HTTPS

Conceptos y características clave

• Recurso : 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).

  
  

• Operaciones CRUD : los servicios REST a menudo se asignan directamente a operaciones CRUD (Crear, Leer, Actualizar, Eliminar) en recursos.

  
  

• Métodos HTTP : los sistemas REST utilizan métodos HTTP estándar:

  • OBTENER: Recuperar un recurso.

  • PUBLICAR: Crea un nuevo recurso.

  • PUT/PATCH: actualiza un recurso existente.

  • ELIMINAR: Eliminar un recurso.

    
    

• Códigos de estado : las API REST utilizan códigos de estado HTTP estándar para indicar el éxito o el fracaso de una solicitud de API:

  • 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

      
      

• Sin estado : 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.

  
  

• Cliente-Servidor : 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.

  
  

• Almacenable en caché : el cliente puede almacenar en caché las respuestas del servidor. El servidor debe indicar si una respuesta se puede almacenar en caché o no.

  
  

• Sistema en capas : 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.

  
  

• HATEOAS: 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.

Casos de uso

• Servicios web : muchos servicios web exponen su funcionalidad a través de API REST, lo que permite a los desarrolladores externos integrar y ampliar sus servicios.

• Aplicaciones móviles : las aplicaciones móviles a menudo se comunican con servidores backend mediante API REST para recuperar y enviar datos.

• Aplicaciones de página única (SPA) : las SPA utilizan API REST para cargar contenido dinámicamente sin necesidad de actualizar la página completa.

• Integración entre sistemas: los sistemas dentro de una organización pueden comunicarse y compartir datos mediante API REST.

Ejemplo

Pedido

OBTENER “/usuario/42”

Respuesta

 { "id": 42, "name": "Alex", "links": { "role": "/user/42/role" } }

GrafoQL

GraphQL 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.

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.

Formato : JSON

Protocolo de transporte : HTTP/HTTPS

Conceptos y características clave

• Lenguaje de consulta para API : permite a los clientes solicitar los datos que necesitan, haciendo posible obtener toda la información requerida en una sola solicitud.

• Sistema de tipos : 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.

• Punto final único : 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.

• Resolutores : en el lado del servidor, los resolutores recopilan los datos descritos en una consulta.

• Actualizaciones en tiempo real con suscripciones : más allá de solo consultar datos, GraphQL incluye soporte integrado para actualizaciones en tiempo real mediante suscripciones.

• Introspectivo : 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.

Casos de uso

• Frontends flexibles : para aplicaciones (especialmente móviles) con ancho de banda crucial, desea minimizar los datos obtenidos del servidor.

• Agregación de microservicios : se puede introducir una capa GraphQL para agregar los datos de estos servicios en una API unificada si tiene varios microservicios.

• Aplicaciones en tiempo real : 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.

• API sin versión : 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.

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

WebSockets 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.

Formato : binario

Protocolo de transporte : TCP

Conceptos y características clave

• Conexión persistente : 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.

• Upgrade Handshake : 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".

• Marcos : 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.

• Baja latencia : 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.

• Bidireccional : tanto el cliente como el servidor pueden enviarse mensajes entre sí de forma independiente.

• Menos gastos generales : 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.

• Protocolos y extensiones : WebSockets admite subprotocolos y extensiones, lo que permite protocolos estandarizados y personalizados además del protocolo WebSocket base.

Casos de uso

• Juegos en línea : juegos multijugador en tiempo real donde las acciones de los jugadores deben reflejarse inmediatamente en otros jugadores.

• Herramientas colaborativas : aplicaciones como Google Docs, donde varios usuarios pueden editar un documento simultáneamente y ver los cambios de los demás en tiempo real.

• Aplicaciones financieras : plataformas de negociación de acciones donde los precios de las acciones deben actualizarse en tiempo real.

• Notificaciones : cualquier aplicación donde los usuarios necesiten recibir notificaciones en tiempo real, como plataformas de redes sociales o aplicaciones de mensajería.

• Live Feeds : sitios web de noticias o plataformas de redes sociales donde las nuevas publicaciones o actualizaciones se transmiten en vivo a los usuarios.

Ejemplo

Pedido

OBTENER “ws://sitio:8181”

Respuesta

HTTP/1.1 101 protocolos de conmutación

gancho web

Webhook 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.

Formato : XML, JSON, texto sin formato

Protocolo de transporte : HTTP/HTTPS

Conceptos y características clave

• Basado en eventos : 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.

• Mecanismo de devolución de llamada : 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.

• Carga útil : 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.

• Tiempo real : los webhooks permiten que las aplicaciones obtengan datos en tiempo real, lo que las hace altamente receptivas.

• Personalizable : los usuarios o desarrolladores normalmente pueden definir sobre qué eventos específicos desean recibir notificaciones.

• Seguridad : 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.

Casos de uso

• Integración e implementación continuas (CI/CD) : activación de compilaciones e implementaciones cuando se envía código o se fusiona una solicitud de extracción.

• Sistemas de gestión de contenidos (CMS) : Notifica a los sistemas posteriores cuando se actualiza, publica o elimina contenido.

• Pasarelas de pago : informar a las plataformas de comercio electrónico sobre los resultados de las transacciones, como pagos exitosos, transacciones fallidas o reembolsos.

• Integraciones de redes sociales : recibir notificaciones sobre nuevas publicaciones, menciones u otros eventos relevantes en plataformas de redes sociales.

• IoT (Internet de las cosas) : los dispositivos o sensores pueden activar webhooks para notificar a otros sistemas o servicios sobre eventos específicos o lecturas de datos.

Ejemplo

Pedido

OBTENER " https://sitio-externo/webhooks?url=http://sitio/servicio-h/api&name=nombre "

Respuesta

 { "webhook_id": 12 }

RPC y gRPC

RPC (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.

gRPC (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.

RPC

Formato : JSON, XML, Protobuf, Thrift, FlatBuffers

Protocolo de transporte : Varios

Conceptos y características clave

• Definición : 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.

• Stubs : 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.

• Síncrono de forma predeterminada : 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.

• Idioma neutro : muchos sistemas RPC permiten que diferentes implementaciones de cliente y servidor se comuniquen independientemente del idioma en el que estén escritos.

• Acoplamiento estrecho : RPC a menudo requiere que el cliente y el servidor conozcan el procedimiento que se llama, sus parámetros y su tipo de retorno.

Casos de uso

• Sistemas distribuidos : 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 de archivos de red : NFS (sistema de archivos de red) es un ejemplo de RPC que realiza operaciones de archivos de forma remota.

Ejemplo

Pedido

 { "method": "addUser", "params": [ "Alex" ] }

Respuesta

 { "id": 42, "name": "Alex", "error": null }

gRPC

Formato : Protobuf

Protocolo de transporte : HTTP/2

Conceptos y características clave

• Definición : 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.

• Búfers de protocolo : 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.

• Rendimiento : 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.

• Streaming : 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.

• Plazos/Tiempos de espera : 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.

• Conectable : gRPC está diseñado para admitir autenticación conectable, equilibrio de carga, reintentos, etc.

• Idioma neutral : 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.

Casos de uso

• Microservicios : 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.

• Aplicaciones en tiempo real : 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.

• Clientes móviles : 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.

Ejemplo

 message User { int id = 1 string name = 2 } service UserService { rpc AddUser(User) returns (User); }

JABÓN

SOAP , 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í.

Formato : XML

Protocolo de transporte : HTTP/HTTPS, JMS, SMTP y más

Conceptos y características clave

• Basado en XML : los mensajes SOAP tienen formato XML y contienen los siguientes elementos:

  • Sobre : el elemento raíz de un mensaje SOAP que define el documento XML como un mensaje SOAP.

  
  

  • Encabezado : contiene cualquier atributo opcional del mensaje utilizado en el procesamiento del mensaje, ya sea en un punto intermedio o en el punto final final.

  
  

  • Cuerpo : Contiene los datos XML que componen el mensaje que se envía.

  
  

  • Fallo : elemento de fallo opcional que proporciona información sobre errores durante el procesamiento del mensaje.

    
    

• Neutralidad : SOAP se puede utilizar con cualquier modelo de programación y no está vinculado a uno específico.

• Independencia : Puede ejecutarse en cualquier sistema operativo y en cualquier idioma.

• Sin estado : cada solicitud de un cliente a un servidor debe contener toda la información necesaria para comprender y procesar la solicitud.

• Manejo de errores incorporado : el elemento Fault en un mensaje SOAP se utiliza para informar errores.

• Estandarizado : 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.

Casos de uso

• Aplicaciones empresariales : SOAP se utiliza a menudo en entornos empresariales debido a su solidez, extensibilidad y capacidad para atravesar firewalls y servidores proxy.

• Servicios web : muchos servicios web, especialmente los más antiguos, utilizan SOAP. Esto incluye servicios ofrecidos por grandes empresas como Microsoft e IBM.

• Transacciones financieras : 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.

• Telecomunicaciones : las empresas de telecomunicaciones pueden utilizar SOAP para procesos como la facturación, donde diferentes sistemas deben comunicarse de manera confiable.

Ejemplo

Pedido

 <?xml version="1.0"?> <soap:Envelope> <soap:Body> <m:AddUserRequest> <m:Name>Alex</m:Name> </m:AddUserRequest> </soap:Body> </soap:Envelope>

Respuesta

 <?xml version="1.0"?> <soap:Envelope> <soap:Body> <m:AddUserResponse> <m:Id>42</m:Id> <m:Name>Alex</m:Name> </m:AddUserResponse> </soap:Body> </soap:Envelope>

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.