Header Ads Widget

Ticker

6/recent/ticker-posts

Mediación de API: por qué necesita una capa de experiencia de API


 La economía de las API ha marcado el comienzo de una nueva era de integración de aplicaciones, lo que ha provocado un cambio radical en la TI empresarial y los proveedores de aplicaciones. Las API brindan acceso a los datos de forma segura a través de firewalls, lo que permite nuevos modelos comerciales y ofrece una plataforma que respalda el desarrollo de nuevos productos digitales.

Una talla no sirve para todos

Como integración API centradas madura, sin embargo, ha quedado muy claro que no todos los consumidores de la API son iguales: los objetos de datos pueden necesitar ser modificado en base al tipo de dispositivo; la orquestación o composición puede ser necesaria dependiendo de la sofisticación del cliente; Es posible que la seguridad deba adaptarse para adaptarse a escenarios móviles, web o de IoT. La lista continua.

Un gran ejemplo de esta diversidad proviene de Netflix , donde su equipo de desarrollo de API aprendió rápidamente que un enfoque de "talla única" para la integración de API no iba a funcionar. El equipo descubrió que diferentes aplicaciones de cliente (como un navegador de escritorio, una aplicación móvil o una televisión inteligente) requerían diferentes funcionalidades al acceder a la API de Netflix, lo que obligaba al equipo de API a crear un número cada vez mayor de funciones para abordar las demandas. Una vez que la actualización continua de esta interfaz única se volvió inmanejable, introdujeron una experiencia de API, o mediación, capa sobre su plataforma de API existente que permitió a cada equipo de IU e incluso a los socios optimizar la experiencia de API para su aplicación o dispositivo específico.

Con cada nueva innovación en dispositivos conectados y cada nueva experiencia de usuario y aplicación que acompaña a estos dispositivos, las organizaciones deben considerar una arquitectura de aplicación y una estrategia de integración que incorpore flexibilidad y agilidad . La mediación de API (en otras palabras: gestión de la experiencia de API) se está convirtiendo en un concepto más familiar a medida que muchas organizaciones comienzan a desarrollar su primera incursión en la economía de API .

¿Qué es API Experience Management?

La gestión de la experiencia de API es una solución para enriquecer o personalizar las interacciones entre aplicaciones distribuidas y componentes de servicio. La clave del modelo de experiencia de API es colocar una nueva capa de abstracción o mediación entre los consumidores de API (aplicaciones, servicios y "cosas") y los proveedores de API (servicios y aplicaciones). Esta capa envuelve la API de backend (la API interna) y expone una API personalizada y administrada (la API externa) a cada grupo definido de consumidores, lo que simplifica la experiencia del desarrollador y al mismo tiempo garantiza un acoplamiento flexible.

La nueva API externa también puede tener como objetivo ofrecer funciones más avanzadas a sus desarrolladores, proporcionando una fachada sobre la API interna para mejorar su funcionalidad o simplemente mantenerse al día con los cambios en las tecnologías API y las mejores prácticas.

Tres áreas funcionales que quizás desee considerar agregar como parte de la gestión de su experiencia API incluyen:

  1. Eventing : existe una creciente demanda de patrones de integración impulsados ​​por eventos entre las API web, sin embargo, el soporte entre las API públicas y privadas sigue siendo muy limitado. Existe una gran preferencia por los webhooks para manejar estos eventos asincrónicos entre servicios de aplicaciones, por lo que ofrecer esta funcionalidad puede ser una valiosa adición para sus desarrolladores. Los webhooks incluso están ganando un lugar dentro de los lenguajes de documentación de API, como la especificación OpenAPI v3.0 .
  2. Operaciones de datos masivos : Las operaciones de carga y descarga masivas son útiles para muchos servicios y aplicaciones centrados en datos, y donde los desarrolladores disponibles a menudo están interesados ​​en aprovechar esta funcionalidad. Si su backend no admite operaciones masivas hoy, su capa de experiencia API se puede utilizar para habilitar esto.
  3. Descubrimiento de API : para ayudar a aliviar parte del dolor de la integración, los proveedores de API ofrecen cada vez más una capacidad conocida como descubrimiento de metadatos , de modo que se puede acceder a los modelos de datos y estructuras de recursos y comprenderlos mediante programación. Los datos vinculados también pueden mejorar la usabilidad y la experiencia de sus API, y nuevamente dentro de OAS v3.0 se describen nuevas capacidades básicas de vinculación, un claro guiño hacia Hypermedia .
Relacionado: Los principios básicos de la gestión de API

La necesidad de mediación

Quizás la forma más simple de mediación es transformar las interfaces SOAP heredadas en API RESTful más amigables para los desarrolladores , pero en el complejo mundo actual de la integración esto no es suficiente para resolver los desafíos que están experimentando los desarrolladores front-end.

En lugar de pensamientos de divorcio o separación que pueda evocar el término mediación , esta evolución se trata en realidad de brindar una experiencia más positiva para cada uno de sus consumidores de API. Hemos aprendido que, con bastante frecuencia, un enfoque único para el diseño y la exposición de API no funciona, y los diferentes tipos de usuarios, desarrolladores y dispositivos tienen diferentes expectativas y requisitos en lo que respecta al consumo de API.

Gestión de la experiencia API en la práctica

Hay varias razones clave por las que su organización obtendrá valor de una capa de experiencia API en su arquitectura de integración:

  • Cambio en los requisitos de integración : creó API para ofrecer un único caso de uso, producto o línea de negocio, pero ahora tiene muchos grupos, cada uno con diferentes casos de uso y requisitos de integración.

Ejemplo: he creado una API diseñada para permitir que los socios B2B revendan mis productos y servicios a través de sus canales. Cuando un nuevo propietario de producto desea crear una aplicación móvil, es probable que esta API no esté optimizada para la web móvil.

  • Respuesta a las necesidades del consumidor : su capa de API existente ha estado en el producto durante varios años y debe mejorarse con la nueva funcionalidad que solicitan sus desarrolladores.

Ejemplo: Mi API es una interfaz RESTful básica que los clientes de hoy deben sondear el punto final cuando buscan datos actualizados. Preferirían una implementación de WebHooks que alerta a su aplicación cuando hay nuevos datos disponibles.

  • Gobernanza de datos : necesita sincronizar datos en una variedad de servicios, incluso si están en dominios diferentes. Dado que muchos departamentos dentro de una organización toman sus propias decisiones de compra de los productos que utilizan, se puede perder el control central y la gobernanza de datos.
Lea también: Montaje del rompecabezas de gestión de API en empresas grandes (y pequeñas)

Ejemplo: si la organización de ventas selecciona Salesforce como su plataforma de CRM y la organización de soporte está usando Jira, ¿estas dos organizaciones y productos comparten datos de manera efectiva? No piense en la gestión de datos maestros, sino en una forma sencilla de compartir y sincronizar campos de datos comunes en cada entorno.

  • Escalabilidad a lo largo del tiempo : se está integrando a un servicio en particular ahora, pero en el futuro deberá cambiarlo por un nuevo producto o conectarse a varios productos.

Ejemplo: si estoy almacenando archivos en Box y uso la API sin procesar de Box para hacerlo, y luego agrego SharePoint o Google Drive en el futuro, o los cambio, he roto todo lo demás, a menos que medie en esas API.

  • Ocultar la complejidad : tiene objetos o recursos que existen en múltiples aplicaciones subyacentes, bases de datos u otras fuentes y desea proporcionar acceso constante a estos como recursos de API para proteger al consumidor del recurso de la complejidad.

Ejemplo: acceder a un objeto de datos que representa un "pedido" abarca varios sistemas, extrayendo datos de la gestión de existencias y las plataformas de comercio electrónico. Los desarrolladores deben abstraerse de esta complejidad, integrándose solo con una única API que orquesta los flujos de integración en segundo plano para construir el objeto de datos.

  • Expectativas de integración de aplicaciones de terceros : está introduciendo una aplicación empresarial digital en el mercado y los clientes de esta aplicación esperarán la integración con las aplicaciones SaaS que utilizan dentro de su organización.

Ejemplo: ha creado una nueva aplicación de pagos digitales y los clientes de este producto deben poder integrarla con sus aplicaciones de contabilidad (como Quickbooks).

Consulte también: API Gateways to Direct Microservices Architecture

Pensamientos finales

Muy a menudo, en cada uno de los casos de uso o escenarios descritos anteriormente, cuando se comienza con una pequeña cantidad de puntos de integración (uno o dos), no hay necesidad de preocuparse por la administración de la experiencia de API, ya que cada consumidor de API puede navegar por cualquier limitación. Pero tenga en cuenta que una vez que comience a integrar más y más servicios, productos o preste servicios a diferentes tipos de consumidores de API y a un número cada vez mayor de desarrolladores, encontrará que las API de talla única se convierten en una barrera, en lugar de una habilitador .

Publicar un comentario

0 Comentarios