Header Ads Widget

Ticker

6/recent/ticker-posts

7 protocolos buenos para documentar con AsyncAPI


La documentación es posiblemente la parte más importante de cualquier estrategia de API , ya que a menudo es la ruta directa entre el desarrollador y el usuario, y un conducto directo a través del cual el desarrollador puede informar, educar y contextualizar. En consecuencia, encontrar buenas opciones para documentar su API es de suma importancia.

AsyncAPI es una de esas opciones. AsyncAPI es esencialmente la alternativa del paradigma de mensajería a OpenAPI o RAML. Esas soluciones aún podrían usarse para dicha API, sin embargo, AsyncAPI es simplemente más apropiado para tales situaciones. Esta solución permite la documentación para las API de mensajería , utilizando una especificación potente que es apropiada tanto para la interacción humana como para la máquina. Sin embargo, para hacer esto, AsyncAPI necesita aprovechar uno o más protocolos .

Hoy vamos a hablar exactamente de eso. Tenga en cuenta que esta es una base muy amplia, una descripción general; se puede encontrar más información en los enlaces al final de este artículo.

El creador de AsyncAPI, Fran Méndez, habló en nuestra última Cumbre de Plataformas. Puedes ver su charla aquí:

Primero, ¿qué es AsyncAPI?

AsyncAPI es una especificación que permite a los desarrolladores definir sus API utilizando una variedad de formatos legibles por máquina. Funcionalmente se basa en la idea de utilizar un sistema de mensajería definido generalmente, donde el mensaje contiene un encabezado y una carga útil, y luego utilizar esto para clasificar los mensajes en temas. Son, en líneas generales, análogas a las URL de la pila HTTP clásica.

AsyncAPI es un método mediante el cual una API se puede representar utilizando un lenguaje comúnmente definido y comprendido. El espíritu principal aquí es que, con un lenguaje común, la creación de productos y servicios interoperables se hace más fácil. Esto también se puede ver en el enfoque de la API Async para el código abierto ; AsynAPI ha sido, y aparentemente seguirá siendo, de código abierto.

AsynAPI también le da mucha importancia al hecho de que es legible por humanos y máquinas . Al describir las API mediante JSON y YAML , y al ofrecer una variedad de ganchos para la funcionalidad de la GUI , AsyncAPI ha intentado posicionarse como una oferta apropiada para las funciones de máquina a máquina y la comprensión de persona a máquina.

Finalmente, una gran "venta" para AsyncAPI es que fue diseñado para una situación determinada, en lugar de diseñado y luego utilizado en varios entornos. AsyncAPI se basa completamente en el concepto de interacción API centrada en mensajes , que normalmente se encuentra en IoT y plataformas similares. De hecho, AsyncAPI se basa en las limitaciones que se encuentran en estos sistemas, lo que a su vez creó la demanda de dicho estándar. Este es un maestro de propósito, más que un experto en todos los oficios que intenta manejar una amplia gama de paradigmas y enfoques de desarrollo.

AsyncAPI puede funcionar con una variedad de protocolos. Echemos un vistazo a algunos de estos. Tenga en cuenta que hay protocolos que se consideran compatibles actualmente y protocolos que no son compatibles actualmente, pero que en cambio se están investigando . Presentamos ambos aquí para completar.

Leer más: Revisión de herramientas: AsyncAPI

Soporte actual

Los siguientes protocolos son actualmente (a noviembre de 2018) compatibles con AsyncAPI.

1. AMQP

Estándares AMQP para el protocolo de cola de mensajes avanzado . Fue diseñado originalmente en 2003 por John O'Hara en la sucursal de JPMorgan Chase en Londres y fue creado para funcionar como un esfuerzo abierto para un estándar de comunicación cooperativa. Debido a este enfoque, el grupo de trabajo se ha expandido drásticamente para incluir a algunos de los principales impulsores en varias industrias, incluidos Goldman Sachs, Microsoft, Red Hat y VMware, sin mencionar a JPMorgan Chase, Cisco Systems y Barclays.

Uno de los mayores beneficios de AMQP es el hecho de que permite anotar datos mecanografiados , y esto, combinado con su sistema de codificación "autodescriptivo" , permite una mayor comprensión y compatibilidad entre una amplia variedad de clientes y usuarios. AMQP considera que cada función de datos básica es un "marco" y la considera parte de nueve cuerpos de marco AMQP (abrir, comenzar, adjuntar, transferir, fluir, disponer, separar, finalizar y cerrar).

2. MQTT

MQTT , o Message Queueing Telemetry Transport , fue creado por primera vez en 1999 por Andy Stanford-Clark y Arlen Nipper, ambos parte de IBM y Cirrus Link respectivamente. Posteriormente, el protocolo se agregó como estándar ISO bajo ISO / IEC PRF 20922 . Funciona como una capa en la parte superior de la pila de TCP / IP : este protocolo se basa en Publicar / Suscribir y está diseñado específicamente para dispositivos IoT y otros sistemas que tienen un ancho de banda bajo y una latencia alta , así como en redes que no lo son. no fidedigno. Ha sido diseñado específicamente para la comunicación de máquina a máquina.

MQTT tiene tres tipos de mensajes generales. Connect espera a que se establezca una conexión con el servidor y facilita la creación de este enlace. Disconnect espera a que el cliente finalice su sincronización y transferencia, y luego desconecta la sesión TCP / IP. Luego, Publish regresa al hilo de la aplicación y devuelve los datos al cliente.

3. WebSocket

WebSocket es un protocolo que ha sido estandarizado por el Grupo de trabajo de ingeniería de Internet como RFC 6455 junto con la inclusión de la API de WebSocket en Web IDL bajo el W3C . El protocolo está diseñado para funcionar como intermediario en la relación cliente-servidor y se basa principalmente en TC con funcionalidad HTTP adicional incorporada.

WebSocket fue diseñado desde cero para admitir la comunicación estandarizada con una sobrecarga baja y un rendimiento optimizado . Esto se ve agravado por la utilización de puertos de tráfico web estándar, lo que significa que a menudo es útil en entornos donde los sistemas de comunicación no tradicionales no basados ​​en web están bloqueados o limitados.

Más importante aún, debe mencionarse que WebSocket es compatible de forma nativa con todos los navegadores principales , un gran punto de venta para cualquier API web.

4. Kafka

Kafka es un protocolo de código abierto que fue diseñado y lanzado en 2011 por Apache Software Foundation. Está escrito principalmente en Scala y Java, y está diseñado para proporcionar una metodología de alto rendimiento , alta eficiencia y baja latencia para manejar e integrar fuentes de fuentes de datos en tiempo real . Originalmente fue diseñado para LinkedIn, pero rápidamente se convirtió en código abierto.

Kafka es en realidad cuatro API disfrazadas de una: la API de productor publica un flujo de registros en Kafka Cluster. La API de consumidor permite a los consumidores suscribirse a temas y procesa los registros para su utilización y distribución. La API del conector en realidad vincula los temas a las aplicaciones existentes. La API de Streams convierte los flujos de entrada en un flujo de salida y proporciona este resultado a las distintas API y sus clientes.

El caso de uso principal de Kafka en su documentación es como un reemplazo de lo que ellos consideran “intermediarios de mensajes más tradicionales”. Al manejar esta metodología de comunicación para lo que es esencialmente una relación pub-sub glorificada, Kafka puede presumir de un alto rendimiento y una comunicación efectiva. Desafortunadamente, esto también (por su propia admisión) requiere una latencia baja de extremo a extremo y, en algunos casos (especialmente aplicaciones de IoT), esto puede ser un factor limitante.

Otros incluyen JMS, STOMP y… HTTP

Además de los cuatro anteriores, Fran también señala que bajo el conjunto de protocolos ya soportados, AsyncAPI también tiene JMS , STOMP y HTTP . Como describe, "una de las características menos conocidas de AsyncAPI es su capacidad para definir API de transmisión HTTP, con soporte para eventos enviados por el servidor y codificación fragmentada".

Bajo consideración

ASyncAPI está investigando actualmente los siguientes protocolos para su inclusión. Además de estos varios, Fran también señala que también están investigando protobufs y Avro ; protocolos que AsyncAPI está considerando debido a solicitudes de la comunidad.

5. NATS

NATS es un protocolo de aplicación pub-sub clásico Originalmente desarrollado como el sistema de control de mensajería para Cloud Foundry, NATS fue diseñado como un sistema centrado en mensajería basado en Ruby para compartir mensajes publicados con clientes conectados. Más tarde, se transfirió a Go y luego se lanzó a la comunidad de código abierto.

Es interesante el hecho de que NATS ha sido diseñado desde cero para ser lo que los desarrolladores consideran nativo de la nube . Esto se aleja de los métodos tradicionales, que están más orientados localmente y luego se trasladan a la nube.

Una gran venta de NATS es que es modular y que estos módulos son de código abierto. Esto significa que la aplicación de este protocolo puede ser altamente escalable, modular y exactamente específica para su circunstancia dada. El pedigrí de las empresas que utilizan NATS habla de esto, con Ericsson, HTC, Siemens y Pivotal que utilizan NATS.

6. Google Cloud Pub / Sub

Anteriormente conocido simplemente como "Google Pubsub", Google Cloud Pub / Sub es parte de la oferta de Google Cloud Platform de Google. Se lanzó inicialmente en 2008 y cuenta con una amplia variedad de soporte de lenguaje , con el código base escrito en Java, C ++, Python, Go y Ruby.

Google considera que su oferta de Pub / Sub es de nivel empresarial y está orientada a los mensajes, con un sistema que proporciona " mensajería asincrónica de muchos a muchos que disocia a remitentes y receptores ". Si bien la oferta de Google es ciertamente tentadora, especialmente cuando se considera un caso de uso como enviar datos desde un solo nodo a un servidor, por supuesto, existen preocupaciones cuando se usa una parte de una suite completa. Pub / Sub aún se puede usar de forma independiente, pero para muchos, el argumento para usar una parte de una suite en lugar de la suite en sí es difícil de vender.

Dicho esto, hay muchos proyectos de código abierto que hacen posible la utilización de este único componente, con un conector Kafka , un marco de pruebas de carga y más que ofrecen una alta funcionalidad.

7. CoAP

CoAP , o el Protocolo de aplicación restringida , se parece mucho a MQTT, ya que fue diseñado para funcionar en Internet de las cosas y otras situaciones de red restringida. Se está desarrollando como parte de RFC 7252 como estándar web y utiliza llamadas muy " similares a HTTP ". Por esta razón, se considera que es más fácil para muchos desarrolladores comenzar a utilizarlo, ya que se siente muy familiar.

Un gran argumento de venta para CoAP es la idea de que, con costos de "nodos" más bajos, se pueden crear más "nodos"; en Internet de las cosas, donde miles de nodos pueden constituir un segmento de red, este menor gasto de datos puede permitir dispositivos más pequeños, requisitos computacionales que requieren menos recursos y menos desperdicio.

CoAP también se considera independiente del modelo en términos de su integración de datos: se jacta de que el código base "se integra con XML, JSON, CBOR o cualquier formato de datos de su elección ".

Conclusión

Hay una amplia variedad de protocolos que se pueden usar aquí, pero en última instancia, el protocolo adecuado dependerá en gran medida de su caso de uso específico y su base de código. Si bien aquí solo hemos discutido brevemente estos protocolos, los analizaremos con mayor profundidad en una fecha posterior. Por ahora, tenga en cuenta que para su uso con AsyncAPI, estos protocolos se separan en dos categorías amplias entre los implementados actualmente y los que están programados para ser investigados. En algunos casos, esta investigación podría significar que la adopción está a la vuelta de la esquina, y en otros casos, podría estar muy lejos en el futuro.

Recursos adicionales

Para obtener más información, consulte los siguientes enlaces:

  • Especificación AsyncAPI
  • Página de destino de AMQP
  • Página de inicio de MQTT
  • Artículo de Wikipedia sobre WebSockets
  • Documentación de Kafka
  • Página de inicio de NATS
  • Documentación de Google Cloud Pub / Sub
  • Página de inicio de documentación de CoAP


Publicar un comentario

0 Comentarios