- Tendencias de protocolos de API y sus ventajas/desventajas, recopiladas por Postman a partir de una encuesta a 40 mil desarrolladores
- REST, WebHooks, GraphQL, SOAP, WebSocket, gRPC, etc.
REST
- Sigue siendo el más utilizado. Bajó del 92% al 86% en los últimos 2 años
- Simplicidad, escalabilidad y facilidad de integración con servicios web
- Ventajas de REST
- Simplicidad y estandarización: al usar métodos HTTP estándar, los desarrolladores que ya conocen HTTP pueden adoptarlo fácilmente. Su simplicidad acelera el aprendizaje y la integración
- Escalabilidad: por la naturaleza sin estado de REST, el servidor no necesita guardar datos de sesión entre solicitudes. Facilita el escalado horizontal agregando instancias sin necesidad de un servidor compartido
- Rendimiento: las respuestas sin estado y cacheables mejoran la velocidad de ejecución y reducen la cantidad de solicitudes
- Modularidad: los servicios RESTful pueden desarrollarse como componentes modulares. Esto permite actualizaciones independientes y mejora el mantenimiento
- Independencia de plataforma: puede usarse con diversos clientes. La interoperabilidad facilita la integración de APIs en todo el sistema
- Herramientas maduras y soporte comunitario: hay muchas herramientas, librerías, buenas prácticas, guías de resolución de problemas y recursos de la comunidad
- Retos de REST
- Over-fetching y under-fetching: el cliente podría necesitar solo parte de la información, por lo que puede traer demasiados o muy pocos datos. Esto puede causar problemas de rendimiento y desperdiciar ancho de banda
- Múltiples interfaces: para obtener datos relacionados pueden requerirse varias solicitudes, lo que aumenta la latencia. Esta cadena de llamadas se vuelve problemática a medida que la aplicación escala
- Problemas de versionado: crear nuevas versiones de una API REST puede ser engorroso, especialmente cuando cambian la estructura de datos o las funciones del servicio. Esto suele generar problemas de compatibilidad con versiones anteriores
- Sobrecarga del modelo sin estado: aunque ser stateless favorece la escalabilidad, también implica que cada solicitud debe incluir todo el contexto necesario. Esto puede generar sobrecarga, especialmente cuando el cliente debe enviar grandes volúmenes de datos repetitivos
- Falta de capacidades en tiempo real: REST no está optimizado para apps en tiempo real como chats o feeds en vivo. WebSocket y SSE se adaptan mejor a esos casos de uso
WebHooks
- Los webhooks son callbacks HTTP personalizados que se disparan por eventos en la aplicación de origen
- Cuando ocurre un evento, la aplicación de origen envía una solicitud HTTP (generalmente POST) al URI especificado por la aplicación de destino, lo que permite una comunicación basada en eventos casi en tiempo real sin necesidad de polling repetitivo
- Los webhooks están ganando popularidad y el 36% de los desarrolladores los usa para una integración fluida entre distintos sistemas
- Ventajas de WebHooks
- Comunicación en tiempo real: los webhooks permiten transmitir datos en tiempo real. Cuando ocurre un evento, se envían los datos correspondientes, garantizando sincronización actualizada entre sistemas
- Eficiencia: los webhooks eliminan el polling intensivo en recursos, ahorrando capacidad de cómputo y ancho de banda
- Flexibilidad: los webhooks pueden configurarse para responder a eventos específicos, por lo que es posible personalizar qué acciones o disparadores de una aplicación enviarán datos a otra
- Integración simplificada: al usar métodos HTTP, pueden utilizarse fácilmente en la mayoría de las aplicaciones
- Soporte para arquitecturas desacopladas: como funcionan con base en eventos, los webhooks favorecen de forma natural arquitecturas orientadas a eventos o desacopladas, mejorando la modularidad y la escalabilidad
- Retos de WebHooks
- Manejo de errores: si el receptor del webhook está caído o hay errores al procesar el callback, existe riesgo de pérdida de datos. Los sistemas que usan webhooks deben contar con mecanismos sólidos de manejo de errores, incluidos reintentos o logs
- Problemas de seguridad: como los webhooks transmiten datos por internet, son vulnerables a la interceptación o a ataques maliciosos. Son esenciales medidas de seguridad de API como HTTPS y firmas del payload
- Gestión de múltiples webhooks: administrar y monitorear webhooks puede ser complejo, especialmente cuando la aplicación crece y empieza a depender de varios webhooks. Hace falta cuidado para asegurar que todos funcionen correctamente y para rastrear distintos endpoints
- Posible sobrecarga: un gran volumen de callbacks simultáneos puede sobrecargar la recepción de la aplicación, aunque el rate limiting o el procesamiento por lotes pueden ayudar a manejar los picos
GraphQL
- GraphQL es un lenguaje de consultas para APIs y un runtime del lado del servidor para ejecutar consultas usando un sistema de tipos definido sobre los datos
- Desarrollado por Facebook en 2012 y lanzado como proyecto open source en 2015, GraphQL ofrece una alternativa más flexible y eficiente a las APIs REST tradicionales
- GraphQL está aumentando su adopción entre desarrolladores hasta el 29%, lo que refleja su importancia en el panorama actual de APIs
- A diferencia de REST, que puede requerir pasar por múltiples endpoints para obtener datos relacionados, GraphQL permite obtener todos los datos necesarios en una sola consulta
- Esto resulta especialmente útil para desarrolladores frontend, ya que les da más control sobre el proceso de obtención de datos y facilita crear interfaces de usuario más dinámicas y responsivas
- Ventajas de GraphQL
- Esquema fuertemente tipado: una API GraphQL tiene un esquema fuertemente tipado, por lo que los desarrolladores pueden saber exactamente qué datos y tipos están disponibles para las consultas
- Obtención precisa de datos: los clientes pueden solicitar exactamente los datos que necesitan, lo que resuelve los problemas de over-fetching y under-fetching, mejora el rendimiento y además reduce costos
- Complejidad de consultas y recursos diversos: GraphQL permite consultar múltiples tipos de datos en una sola solicitud, lo que reduce el número de peticiones de red para datos complejos e interrelacionados
- Actualizaciones en tiempo real mediante suscripciones: GraphQL soporta sincronización en tiempo real a través de suscripciones, de modo que los clientes se actualizan en tiempo real
- Introspección: el esquema autodocumentado de GraphQL facilita el desarrollo mediante inspección automática
- Retos de GraphQL
- Complejidad de consultas: la flexibilidad que GraphQL ofrece al cliente también tiene desventajas. Consultas demasiado complejas o anidadas pueden afectar negativamente el rendimiento
- Curva de aprendizaje: GraphQL tiene una curva de aprendizaje más pronunciada que REST debido a conceptos nuevos como mutaciones y suscripciones
- Versionado: la naturaleza flexible de las consultas implica que cambios en el esquema pueden romper consultas existentes y complicar el versionado
- Posible uso excesivo de recursos: como los clientes pueden solicitar múltiples recursos en una sola consulta, existe el riesgo de traer más datos de los necesarios y sobrecargar el servidor
- Problemas de seguridad: usuarios maliciosos podrían explotar la flexibilidad de GraphQL para sobrecargar el servidor con consultas complejas
SOAP
- SOAP (Simple Object Access Protocol) es un protocolo para intercambiar información estructurada al implementar servicios web
- Usa XML como formato de mensajes y normalmente HTTP o SMTP como capa de negociación y transporte de mensajes
- A diferencia de REST y GraphQL, SOAP tiene estándares estrictos y capacidades integradas como transacciones compatibles con ACID, seguridad y patrones de mensajería
- A pesar de la disminución de uso, con solo el 26% de los desarrolladores, SOAP sigue siendo una opción confiable para ciertas aplicaciones
- Ventajas de SOAP
- Tipado fuerte y contrato: tiene tipado fuerte y contratos estrictos definidos en documentos WDSL (Web Services Description Language)
- Capacidades de seguridad integradas: SOAP ofrece seguridad integral mediante autenticación, autorización y cifrado implementados con el estándar WS-Security. Por eso es una opción preferida en aplicaciones empresariales
- Transacciones ACID: SOAP soporta transacciones ACID, esenciales para aplicaciones donde la integridad de los datos es crítica, como sistemas financieros o de salud
- Mensajería confiable: SOAP garantiza la entrega confiable de mensajes y maneja bien los errores, por lo que es muy adecuado para sistemas donde garantizar la entrega es importante
- Neutralidad respecto a lenguaje, plataforma y transporte: al igual que REST, los servicios SOAP pueden ser usados por cualquier cliente que entienda XML, sin importar el lenguaje de programación, la plataforma o el protocolo de transporte subyacente
- Retos de SOAP
- Complejidad y curva de aprendizaje: SOAP puede ser más complejo de implementar debido a sus estándares estrictos y al uso de XML, por lo que tiene una curva de aprendizaje más pronunciada que alternativas como REST o GraphQL
- Mensajes verbosos: los encabezados de mensajes SOAP añaden mucho overhead, por lo que el payload es mayor que el JSON de REST y GraphQL. Esto puede afectar el rendimiento y el uso de ancho de banda
- Soporte comunitario limitado: SOAP está perdiendo terreno, lo que significa menos soporte de la comunidad y menos librerías disponibles
- Menor flexibilidad: si cambia el contrato, tanto el cliente como el servidor podrían tener que actualizar sus respectivas implementaciones, lo que puede ser una desventaja
- Problemas con firewalls: SOAP puede usar protocolos de transporte distintos de HTTP/HTTPS, lo que implica posibles restricciones de firewall. Esto hace que SOAP sea menos versátil en algunos entornos de despliegue
WebSocket
- WebSocket proporciona una conexión bidireccional persistente y de baja latencia entre cliente y servidor, permitiendo transferencia de datos en tiempo real
- A diferencia del ciclo solicitud-respuesta de HTTP, con WebSocket el servidor puede enviar datos al cliente en cualquier momento después del handshake inicial
- Facilita actualizaciones inmediatas de datos para aplicaciones de chat, juegos en línea, plataformas de trading, etc.
- Según la encuesta, el 25% de los desarrolladores usa WebSocket
- Ventajas de WebSocket
- Comunicación bidireccional en tiempo real: esta comunicación bidireccional en tiempo real tiene menor latencia que una conexión HTTP que debe restablecerse en cada intercambio
- Menor sobrecarga: después del handshake inicial, la conexión permanece abierta, por lo que se reduce el overhead de headers típico de las solicitudes HTTP tradicionales
- Uso eficiente de recursos: las conexiones persistentes usan los recursos del servidor de forma más eficiente que el long polling
- Retos de WebSocket
- Complejidad de implementación: implementar WebSocket puede ser más complejo y tomar más tiempo que otras arquitecturas de API, especialmente al considerar la necesidad de alternativas en entornos donde no se soporta WebSocket
- Falta de capacidades integradas: a diferencia de SOAP, que incorpora funciones de seguridad y transacciones, WebSocket es más básico, por lo que los desarrolladores deben implementar esas capacidades por su cuenta
- Consumo de recursos: aunque las conexiones WebSocket abiertas suelen ser más eficientes que el long polling, siguen consumiendo recursos del servidor y pueden volverse problemáticas a gran escala
- Restricciones de red: algunos proxies y firewalls no soportan WebSocket, lo que puede causar problemas potenciales de conexión en ciertos entornos de red
gRPC
- gRPC, que significa "Google Remote Procedure Call", es un protocolo moderno de alto rendimiento que facilita la comunicación entre servicios
- Está construido sobre HTTP/2 y utiliza Protocol Buffers para definir métodos de servicio y formatos de mensaje
- A diferencia de las APIs REST, que usan verbos HTTP estándar como GET y POST, gRPC permite exponer métodos personalizados en el servicio, similares a funciones de un lenguaje de programación
- Ventajas de gRPC
- Rendimiento: al usar HTTP/2 y Protocol Buffers, gRPC puede lograr baja latencia y alto throughput
- Tipado fuerte: al igual que SOAP y GraphQL, gRPC es fuertemente tipado. Como resultado, los tipos se validan en tiempo de compilación, reduciendo bugs
- Soporte multilenguaje: gRPC ofrece excelente soporte para varios lenguajes de programación, incluidos Go, Java, C# y Node.js
- Streaming: gRPC maneja solicitudes y respuestas en streaming, por lo que puede aplicarse a casos de uso complejos como conexiones de larga duración y actualizaciones en tiempo real
- Baterías incluidas: gRPC ofrece soporte directo para funciones importantes como balanceo de carga, reintentos y timeouts
- Retos de gRPC
- Soporte en navegadores: el soporte nativo de gRPC en navegadores sigue siendo limitado, por lo que no es adecuado para comunicación directa cliente-servidor en aplicaciones web
- Curva de aprendizaje: los desarrolladores deben aprender a usar Protocol Buffers, definiciones de servicio personalizadas y otras funciones de gRPC, lo que puede reducir la productividad inicial
- Complejidad de depuración: como Protocol Buffers no es legible por humanos, depurar y probar una API gRPC es más difícil que con APIs JSON
Otros protocolos de API
- MQTT: protocolo ligero de mensajería optimizado para redes de bajo ancho de banda, como IoT. Permite a los clientes publicar y suscribirse a mensajes mediante un broker, aunque carece de algunas capacidades de seguridad y escalabilidad
- AMQP: estándar de mensajería empresarial más robusto que garantiza entrega confiable de mensajes y routing flexible, aunque puede ser más complejo y tener más overhead que protocolos ligeros
- SSE: permite comunicación unidireccional servidor-cliente a través de HTTP; es adecuado para actualizaciones en tiempo real, pero carece de capacidades bidireccionales
- EDI: automatiza la comunicación B2B al estandarizar documentos electrónicos como órdenes de compra y facturas, pero requiere altos costos iniciales e infraestructura compleja
- EDA: promueve una arquitectura orientada a eventos donde los componentes reaccionan a eventos, habilitando sistemas en tiempo real escalables pero complejos de depurar
Conclusión
- El panorama de las APIs sigue evolucionando a medida que los desarrolladores adoptan nuevas arquitecturas, protocolos y herramientas
- REST sigue dominando por su simplicidad y ubicuidad, pero alternativas como GraphQL y gRPC están ganando interés al resolver puntos débiles como el over-fetching y las interfaces demasiado verbosas
- Además, los desarrolladores están dando cada vez más importancia a WebHooks y WebSocket por la necesidad de comunicación en tiempo real
- Para muchos casos de uso comunes de APIs, REST sigue siendo un enfoque base sólido por su escalabilidad, interoperabilidad y facilidad de adopción. También tiene la ventaja de la madurez de su comunidad
- Aun así, todos los protocolos tienen ventajas y desventajas, y a medida que las aplicaciones se vuelven más complejas, los desarrolladores están ampliando con criterio su toolkit de protocolos de API para incluir soluciones especializadas como GraphQL y gRPC
- Más que una solución universal que aplique a todos los casos, lo mejor para los desarrolladores de API es entender las fortalezas y debilidades de varios protocolos
- Al diseñar sistemas que combinan REST, WebHook, WebSocket, GraphQL y otros enfoques con ventajas propias, los desarrolladores pueden construir APIs robustas, eficientes y mantenibles
- Aunque la popularidad de cada protocolo seguirá fluctuando, la tendencia más importante en el panorama de APIs es el aumento de la diversidad
- Los desarrolladores deben adoptar esta filosofía multiprotocolo para crear soluciones de API óptimas
3 comentarios
Lo vi muy bien.
Si no es una tarea de consulta simple que termina con una sola acción, ¿no son indispensables las transacciones? (También coincido con la parte irónica de que, aunque son indispensables, recién ahora se esté apuntando a REST jaja)