Header Ads Widget

Ticker

6/recent/ticker-posts

Revisión de la gestión de API de código abierto Apiman de Red Hat

 apiman_logo

Vea los documentos de Apiman para obtener información específica

No es de extrañar que el crecimiento de la economía de las API haya ido acompañado de una proliferación de soluciones de gestión de API a medida que los proveedores de software se esfuerzan por aprovechar las necesidades de una ola de nuevos proveedores de API que llegan al mercado. API de gestión significa cosas diferentes para personas diferentes (como recientemente hemos discutido ), y hay una gran variedad de soluciones comerciales disponibles en el mercado con una serie de diferentes capacidades que abarcan la gestión básica API para funciones de API de ciclo de vida completo.

Sin embargo, también hay algunas notables soluciones de código abierto que han hecho incursiones en el mercado, tales como WSO2,  Kong  y Tyk.io . En este artículo, echamos un vistazo a una de esas ofertas de código abierto, Apiman de RedHat, para ver qué tiene que ofrecer esta plataforma y cómo la solución podría proporcionar este tipo de características a proveedores de API nuevos y existentes.

En primer lugar, las soluciones de gestión de API de código abierto atraen a los proveedores de API nuevos o existentes por varias razones:

  • Es probable que el costo inicial de una solución de código abierto sea más bajo que el de una solución comercial y el desembolso se centrará en la infraestructura y la mano de obra para aprender, instalar y configurar el producto en lugar de las licencias y los servicios profesionales. Esto puede ser muy importante para los proveedores de API que buscan reducir los costos iniciales al construir un producto mínimo viable;
  • También puede haber beneficios en el otro extremo de la escala, con los proveedores de API más grandes con una huella de gestión de API significativa capaces de ahorrar costos en licencias en una infraestructura implementada con "pozos de dinero" como alta disponibilidad y redundancia;
  • Las soluciones de código abierto tienden a ser "en las instalaciones" (lo que significa que se implementan en las instalaciones en un centro de datos físico o virtual), lo que permite a los proveedores de API utilizar una solución que requiera menos esfuerzo de integración general que las soluciones basadas en la nube. soluciones de gestión de API de servicio ”(ya que a menudo requieren enlaces especiales de“ confianza ”entre el servicio y la plataforma de proveedores de API);
  • Los proveedores de API tienden a tener la libertad de "jugar" más con una solución de código abierto, personalizándola según sus necesidades específicas mediante el desarrollo de nuevos componentes o complementos. Esto puede ser muy útil para los proveedores de API con arquitecturas internas, transportes o protocolos esotéricos que necesitan una solución que no es compatible con un producto comercial y ven una solución de gestión de API personalizada como el mejor camino para satisfacer sus necesidades de manera rentable.

Por lo tanto, para algunos proveedores de API, las soluciones de gestión de API de código abierto pueden ofrecer una serie de ventajas sobre las soluciones comerciales in situ o "como servicio".

Tenga en cuenta que esta publicación será una discusión sobre las características en lugar de un tutorial detallado. Si desea ponerse manos a la obra con Apiman, la documentación que proporcionan es un excelente punto de partida y vale la pena tomarse el tiempo para leer la guía del usuario .

Introducción

Apiman es la solución de gestión de API de código abierto de JBoss y ha estado disponible durante un par de años; actualmente está en desarrollo activo y está alojado en GitHub .

El software se basa en dos componentes principales:

  • Administrador de API : el administrador de API es el componente donde tiene lugar la mayor parte de la actividad de creación y administración de API. Los usuarios pueden definir API e implementar políticas, que son los bloques de construcción fundamentales que definen su comportamiento (que se analizan con más detalle a continuación ). Los usuarios también pueden explorar las API que ya existen y comprender las políticas que implementan, así como sus capacidades. En términos de la taxonomía discutida en nuestra publicación de principios básicos, el Administrador de API cumple en gran medida la función del Registro de API , con algunas capacidades de diseño adicionales;
Administrador de API
  • API Gateway : este es el tiempo de ejecución donde las implementaciones de API se implementan y se exponen a los consumidores, muy similar a nuestra definición de API Gateway . Apiman admite el uso de múltiples API Gateways, lo que permite la separación de API en función de sus características o necesidades; por ejemplo, un proveedor de API puede implementar todas sus API públicas en una instancia de puerta de enlace y sus API privadas en otra, por razones de seguridad o administración del tráfico. Agregar puertas de enlace adicionales a la configuración es una tarea de administración del sistema que se puede realizar mediante el Administrador de API.
Si no lo entendió, consulte nuestro artículo anterior sobre los principios básicos de la administración de API

Empezando

Apiman proporciona varias formas de ejecutar una instancia, incluida la capacidad de incrustar el motor de políticas dentro de otra aplicación o ejecutarlo dentro de un tiempo de ejecución de la aplicación Java. Sin embargo, el método más simple es iniciar un contenedor Docker :

docker run -p 8080:8080 -p 8443:8443 -d --name apiman apiman/on-wildfly10

Con el contenedor Docker en ejecución, puede iniciar sesión en API Manager y comenzar a crear la configuración que se implementará en API Gateway. Lo que realmente crea en su configuración está determinado en gran medida por el modelo de datos de Apiman.

Modelo de datos

Como ocurre con la mayoría de las soluciones de administración de API, Apiman implementa un modelo interno que ayuda a los proveedores de API a describir su API para que puedan aplicarles administración y gobernanza. El modelo de Apiman es razonablemente rico y permite elementos de reutilización y control organizacional como se describe a continuación.

Organizaciones

Una organización describe el propio proveedor de API y es el contenedor de planes y API, lo que proporciona el contexto de gestión para estas entidades. La estructura de la organización permite que diferentes departamentos o incluso varios proveedores de API coexistan en la misma instancia de Apiman.

Planes

Los planes son la entidad de gobierno que se crea para una organización y se usa para describir un grupo de comportamientos que se pueden aplicar a las API: los planes son, por lo tanto, objetos efectivamente reutilizables que se pueden aplicar en toda una organización. Por ejemplo, si un proveedor de API decide implementar un plan común en todas sus API, puede hacerlo con este objeto. Por lo tanto, los planes incluyen la capacidad de definir políticas como cuotas, autorización, almacenamiento en caché, lista blanca, etc.

API

El papel de una API en el modelo es obvio, pero vale la pena señalar que proporcionan el vínculo entre la Organización y la Aplicación Cliente, regida por Planes. Hay varios aspectos diferentes de la funcionalidad que encapsulan las API:

  • Implementación : permite conectar una definición de API a un backend basado en REST o SOAP;
  • Definición : opcionalmente, permite almacenar un documento de especificación de OpenAPI con la API;
  • Planes : como se describió anteriormente, una API puede hacer referencia a uno o más planes definidos por la organización. Esto hará cumplir las Políticas encapsuladas por el Plan (más sobre esto a continuación);
  • Políticas : las API también pueden implementar políticas directamente; esto se haría cuando el comportamiento requerido para una API determinada sea específico.
Diseñador de API

Aplicaciones de cliente

Como suenan, las aplicaciones cliente son una representación lógica de las aplicaciones que los consumidores de API desarrollaron para consumir API y se utilizan para crear el vínculo contractual entre un consumidor de API y el proveedor de API.

Contratos

Los contratos son el vínculo real entre una API y los consumidores de la API , que se manifiesta mediante una clave de API. Sin un contrato, una aplicación cliente no puede consumir una API a menos que la API se considere pública y, por lo tanto, no requiera una clave de API para acceder.

Políticas

Las entidades descritas anteriormente proporcionan el núcleo de las API que puede crear y publicar en Apiman. Sin embargo, como ya se ha comentado, los planes encapsulan las políticas de API, que son la construcción clave para especificar los comportamientos requeridos de una API.

Las políticas son un concepto común en las soluciones de administración de API y Apiman las usa para hacer cumplir el comportamiento del consumidor de API al exigir seguridad o derechos. Se pueden aplicar a API individuales o planes, lo que brinda al proveedor de API flexibilidad para crear políticas comunes en toda su organización.

Paleta de políticas


Ejemplos de políticas incluidas listas para usar:

  • Política de autorización : restringe el acceso a los recursos de las API a roles específicos;
  • Política de autenticación básica : aplica la autenticación básica contra un proveedor de identidad externo, integrado con Apiman a través de JDBC o LDAP (se puede crear un proveedor local para fines de desarrollo);
  • Política de cuotas : impone un límite en la cantidad de llamadas que se pueden realizar a una API durante un período determinado (durante un día, mes o año);
  • Política de limitación de tarifas : como complemento de la Política de cotizaciones, impone umbrales en la tasa de consumo para los consumidores de API o sus usuarios, hasta el nivel de número de solicitudes por segundo.

En las primeras impresiones, la gama de políticas se centra principalmente en la autenticación, la autorización y el control de acceso (con control de acceso que incluye derechos como cuotas y límites de tarifas). Sin embargo, los proveedores de API también pueden crear los suyos propios utilizando complementos y algunas políticas adicionales, como la conversión de XML a JSON, están disponibles en el registro de complementos de Apiman Apiman proporciona una guía detallada sobre la creación de complementos en Java, que también se pueden contribuir al repositorio de complementos de Apiman. Los proveedores de API pueden contribuir opcionalmente al repositorio público.

En las primeras impresiones, el punto óptimo para Apiman es probablemente para los proveedores de API que usan Java y están felices de invertir tiempo en personalizar la plataforma según sus requisitos mediante el desarrollo de sus propios complementos. Como se mencionó anteriormente, los proveedores de API pueden ver la necesidad de personalizar Apiman directamente usando complementos por una variedad de razones, y los desarrolladores apreciarán la capacidad de realizar esta personalización usando un lenguaje que entienden con un gran control al alcance de la mano. Dicho esto, las políticas proporcionadas de forma inmediata proporcionan una gran cantidad de funciones y muchos proveedores de API no necesitarán personalizar la plataforma en absoluto.

Consulte nuestros consejos sobre seguridad API para obtener más información sobre el control de acceso e identidad.

Control de versiones y control

Con la excepción de Organizaciones, prácticamente todo en Apiman está versionado y controlado, y muchos de los objetos admiten la capacidad de ejecutar múltiples versiones simultáneamente. Las API, los planes y las aplicaciones cliente no solo se pueden versionar sino que también se pueden bloquear, lo que las hace inmutables y requiere la creación de una nueva versión para entregar cambios a una entidad determinada. De hecho, los planes deben estar bloqueados para que estén disponibles para su inclusión en las API.

Esta implementación es buena desde la perspectiva de la gobernanza, ya que el control de versiones debe estar implícito en todo lo que hace un proveedor de API al crear nuevas API o planes. Sin embargo, los proveedores de API deben asegurarse de elaborar sus mejores prácticas para el control de versiones antes de usar Apiman con enojo: la capacidad de versionar todo podría generar muchas versiones innecesarias o no utilizadas de API o planes que en realidad pueden dificultar la administración de API.

Conclusiones

En general, Apiman parece ser una solución de administración de API muy capaz con un buen soporte para el tipo de funcionalidad que uno esperaría encontrar en cualquier implementación rica en funciones. Es fácil familiarizarse con la funcionalidad principal y se puede crear una API en cuestión de minutos. El software también es extensible con soporte de complementos, por lo que se puede adaptar a las necesidades de un proveedor de API con relativa facilidad.

Los proveedores de API que busquen una funcionalidad completa de gestión del ciclo de vida de la API, incluido el diseño de la API, la integración de facturación y la compatibilidad con un conjunto de especificaciones de descripción de la API, probablemente necesitarán buscar en otra parte al momento de escribir este artículo. Curiosamente, la facturación y el soporte adicional de descripción de API están en la hoja de ruta para Apiman igual que otras características útiles como la importación de Swagger o WADL para crear una API, la capacidad de activar eventos basados ​​en la ejecución de políticas y herramientas de tipo Portal de desarrollador como foros y API. calificaciones.

Sin embargo, el enfoque en la funcionalidad central de administración de API no contradice el hecho de que Apiman proporciona la capacidad para que un proveedor de API cree un conjunto razonablemente complejo de planes y API. Junto con la capacidad de implementar en múltiples puertas de enlace de API y permitir que los proveedores de API creen una topología más compleja, Apiman puede proporcionar una cantidad significativa de funcionalidad de administración de API y podría proporcionar una alternativa muy atractiva a las soluciones comerciales de administración de API.

¡Apiman / Red Hat no patrocinó esta publicación! Pensamos que sería una buena tecnología para revisar

Publicar un comentario

0 Comentarios