Header Ads Widget

Ticker

6/recent/ticker-posts

Qué debe esperar de un catálogo de administración de API





En estos días, API Management es una parte esencial de cualquier solución de integración de API, mientras que el catálogo de API es una parte integral de cualquier herramienta de gestión de API. En este artículo, hablaré sobre algunas capacidades específicas, que a menudo se pasan por alto, de un catálogo de API al seleccionar productos de administración de API. También enfatizaré el valor único y práctico de esas capacidades.

¿Qué tan flexible es la estructura de un catálogo de API?

Es bastante común ver a los proveedores de administración de API que ofrecen catálogos de API como una lista "plana" de API. Esta es la estructura más primitiva y limitada porque no permite agrupar fácilmente las API según algunos criterios significativos. Una presentación mucho más práctica es una estructura de árbol jerárquica . Con tal estructura, las API en un catálogo se organizan en "carpetas" en forma de árbol, donde cada carpeta puede designar cualquier criterio de agrupación significativo, como el proyecto, subproyecto, entorno o propósito de uso de su empresa (como público vs. API internas). Aunque la agrupación todavía se puede lograr mediante el etiquetado de API, tener API en una estructura en forma de árbol ofrece una mejor visualización. También proporciona un control de acceso más flexible a diferentes ramas de árbol de su catálogo de API por parte de diferentes usuarios de gestión de API.

Consideremos un ejemplo práctico. Una organización que utiliza la gestión de API crea dos carpetas para sus API: una carpeta para las API que se exponen públicamente ( carpeta de API públicas ) y otra carpeta para las API que se utilizan para integrar aplicaciones internas ( carpeta de API internas ). Cada carpeta puede tener subcarpetas para definir API que pertenecen a diferentes proyectos empresariales o de TI. Si la organización tiene equipos separados que trabajan en varios proyectos de API, a los miembros de estos equipos se les puede otorgar acceso y visibilidad solo a una jerarquía de subárbol en particular. Por el contrario, los administradores aún pueden acceder, monitorear y administrar todo el catálogo de API desde el mismo portal de administración de API.

¿Puede administrar las API de backend (físicas) y las API virtuales (alojadas en puertas de enlace de API) de forma independiente?

Muchos productos de gestión de API ofrecen el catálogo de API como una lista de API virtuales únicamente, aquellas que están alojadas en API Gateways. Las API de backend (o físicas), en este caso, no están registradas como entidades independientes en el catálogo y solo se pueden ver "detrás" de las configuraciones de sus API virtuales. Esto crea varias limitaciones importantes en el catálogo de API:

  1. Es difícil identificar las API de backend que tiene bajo administración porque no forman parte directamente de un catálogo de API (solo lo son las API virtuales). Las API de backend siguen siendo sus "activos" de software. Si se registra y mantiene en su catálogo de API como "ciudadanos de primera clase", las API proporcionan un medio invaluable para saber lo que ha desarrollado como parte de sus proyectos.
  2. Los metadatos (Swagger / OpenAPI Spec / WSDL) y la documentación del backend y las API virtuales pueden ser diferentes . Suponga que su servicio virtual transforma los mensajes mientras vuelan a través de una puerta de enlace API. En este caso, los consumidores de API virtuales deben recibir metadatos y documentación, que pueden ser diferentes de sus API de backend originales. Pero aún así, desarrolló solo la API de backend (no virtual) y desea saber, al menos por su propio bien, sus metadatos y documentación.
  3. Esfuerzo duplicado en la creación de múltiples API virtuales para la misma API de backendSuponga que desea crear dos API virtuales para la misma API de backend (tal vez una API virtual para uso interno con puntos finales internos y políticas de seguridad, y otra para uso público a través del punto final público y sus políticas de seguridad). Con la ausencia de una API de backend registrada de forma independiente, tendría que volver a ingresar la misma configuración de la API de backend cada vez que cree una nueva API virtual. Ahora, si su catálogo de API permite el registro independiente de sus API de backend, puede simplemente hacer referencia (o vincular) una nueva API virtual a la misma API de backend existente. Además, si cambia algo en su API de backend (por ejemplo, cambia su dirección de punto final), puede hacerlo una vez, y todas las API virtuales dependientes serán notificadas y actualizadas automáticamente.
  4. Surgen preocupaciones aún más sustanciales cuando se trata de la arquitectura de microservicios . Puede crear una única API virtual alojada en una puerta de enlace de API que virtualiza (mediante agregación) varios microservicios de backend. Las cosas se complican aún más cuando el mismo microservicio también forma parte de diferentes servicios virtuales. Por ejemplo, la API virtual V1 virtualiza los microservicios M1 y M2 , mientras que la API virtual V2 virtualiza los microservicios M2 y M3 . 
    Si tiene M1 , M2 y M3 registrados en un catálogo de API como entidades independientes, entonces puede hacer referencia a ellos mediante API virtualesV1 y V2 en lugar de configurar V1 y V2 una y otra vez con la misma información de las API de backend.
  5. No hay seguimiento de la dependencia ni análisis de impacto . Puede tener diagramas de seguimiento de dependencias interactivos y muy prácticos integrados en su producto de gestión de API si permite el registro independiente de API virtuales y de backend. El seguimiento de dependencias también le ayuda a identificar los impactos de cualquier cambio (por ejemplo, si cambio una API de backend, ¿qué API virtuales se verán afectadas y cómo?).

¿Es un catálogo de API solo para API?

Es mucho más práctico y beneficioso si un catálogo de API puede tratar otros tipos de artefactos relacionados con API como "ciudadanos de primera clase". Pueden ser políticas de seguridad, reglas de control de acceso (lógica de autorización), comportamientos de API personalizados, acuerdos de nivel de servicio, etc. Con estos datos a mano, puede identificar las dependencias entre las API y estos artefactos, minimizar las configuraciones requeridas y los esfuerzos de administración asociados, promover reutilización y coherencia, e implementar controles de conformidad.

Conclusión y notas finales

La implementación de las capacidades descritas en un producto de administración de API aumenta el valor de los datos que almacena, lo que a su vez brinda más información y más poder al personal de TI y de negocios. La capacidad de detección de la API de backend, la reutilización de la configuración, la notificación de cambios y el seguimiento de dependencias son algunos de los beneficios adicionales que ofrece un catálogo de API diseñado correctamente.

Si un catálogo de administración de API incluye las capacidades enumeradas anteriormente, su interfaz de usuario se puede transformar fácilmente en una herramienta muy intuitiva y útil, con arrastrar y soltar, diagramas interactivos y búsquedas efectivas en el catálogo.

Publicar un comentario

0 Comentarios