API Strategy – La guía definitiva (Parte II)

Continuamos con la guía definitiva de API Strategy, en esta segunda parte hablaremos sobre los marketplaces y ecosistemas de partners, la herramienta de sandbox, seguridad y anti hacking, capa de orquestación, monitorización y monetización, integración y despliegue continuo.

 

Marketplaces y ecosistemas de partners

La mayor parte de las plataformas de integración ofrecen la capacidad de construir portales de APIs, ya sea internos o externos. Cuando estos portales están construidos sobre un CMS ampliamente utilizado – como por ejemplo Joomla o Drupal – es más sencillo dotarlo no solo de un look & feel a medida, sino también de lógica de backend a medida.

A partir del Portal de APIs que ofrece de serie la plataforma de integración, es común añadir componentes adicionales hasta conseguir crear un potente marketplace, por ejemplo:

  • Páginas adicionales de documentación, así como wizards o vídeos que faciliten el consumo de los productos digitales
  • Páginas diseñadas a medida, particularmente en la home page, para atraer desarrolladores y usuarios de negocio.
  • Foros y blogs para generar más tráfico al portal
  • Soporte online, incluyendo chatbots, FAQs, formularios de contacto.
  • Buscadores y recomendadores
  • Información de consumo y tarificación.

 

El concepto de Developer Experience (DX) se refiere al conjunto de técnicas que se pueden aplicar para conseguir que los desarrolladores que aterrizan en una landing page del portal pasen más tiempo en el portal, que se den de alta en el, que empiecen a consumir APIs, etc. El Developer Advocate se constituye como un rol fundamental para conseguir maximizar el DX del marketplace.

 

La herramienta de sandbox

En otro tipo de tecnologías es habitual construir mocks efímeros que son desechados una vez que se construye la lógica de negocio real. Sin embargo, en el caso de las APIs, los mocks que constituyen la sandbox no se consideran efímeros, sino que son artefactos de Producción que tienen un ciclo de vida independiente.

Es común involucrar a negocio en la definición de estos mocks, ya que habitualmente se suele construir un mock por cada caso de uso que se considera relevante. Así, en una API de cuentas para un banco, existirán mocks para simular una cuenta normal, pero también para simular una cuenta en números rojos, una cuenta multidivisa, una cuenta bloqueada, etc.

Las plataformas de APIs suelen incluir de serie una sandbox básica, la cual en ocasiones no ofrece toda la funcionalidad que necesita Negocio, de tal manera que esta se extiende o se reemplaza para soportar estas funcionalidades:

  • Capacidades para simular operaciones CRUD
  • Capacidad para ofrecer un juego de datos diferente por cada aplicación consumidora
  • Posibilidad de dar de alta nuevos juegos de prueba
  • Generación de esqueletos de micro-servicios a partir de la definición de la API
  • Integración con el API Portal

 

Seguridad y anti hacking

La mayor parte de las APIs están protegidas utilizando el protocolo de autorización OAuth2. Es también común utilizar capacidades de autenticación, para lo cual es frecuente utilizar una extensión del protocolo OAuth2 que se conoce como OpenID Connect (OIDC).

El protocolo OAuth2 es muy versátil y no solo ofrece diferentes flujos de autorización (usuario / contraseña, authorization code, etc) sino que puede ser extendido para por ejemplo evitar ataques de aplicaciones maliciosas instaladas en el móvil (PKCE), incluir metadata del servidor de autorización, soportar flujos de autorización basados en JWT, etc.

En caso de que se arranque un programa global de APIs Comunes un requisito adicional puede ser que los API Gateways puedan funcionar en modo federado, de tal manera que los tokens de autorización se puedan utilizar a la hora de invocar a APIs de filiales desde un API Gateway corporativo.

Los API Gateway incluyen también de serie multitud de políticas para evitar ataques. Así, es habitual que tengan filtros para evitar ataques de inyección de SQL, denegación de servicio, etc. Es también habitual extender las capacidades anti hacking de los API Gateway colocando filtros avanzados basados en modelos de machine learning que aprenden cuales son los patrones aceptables de consumo de las APIs y que levantan alertas cuando detectan anomalías en las llamadas entrantes.

 

Capa de orquestación

Los API Gateways de primera generación no incluían funcionalidades de orquestación de tal manera que eran utilizados en combinación de un ESB tradicional o de una capa de micro-servicios.

Las modernas plataformas de integración ofrecen capacidades de integración ligeras, escapando del modelo tradicional del ESB monolítico. Estas capacidades de integración se ofrecen como sistemas independientes, facilitando su escalado y limitando los problemas en caso de bloqueos.

En el caso de que se esté utilizando un service mesh por debajo de la capa de APIs, es habitual que la plataforma de APIs ofrezca capacidades de integración con Istio, ofreciendo adaptadores que se conectan con Istio Mixer.
 

Monitorización y monetización

Otra de las capacidades de las plataformas de integración es que ofrecen funcionalidades para monitorizar el consumo de las APIs, tanto desde un punto de vista funcional (APIs más consumidas, partners más activos, etc) como técnico (tiempo de respuesta, errores producidos, etc)

Las capacidades de monetización se apoyan en la información recolectada en la capa de monitorización. Las plataformas de APIs más sofisticadas permiten definir reglas complejas de tarificación, permitiendo la definición de diferentes tramos, el uso de bonos, etc.

No todas las estrategias de monetización pasan por cobrar por el uso de las APIs. Existen otras estrategias indirectas, donde incluso las aplicaciones consumidoras son premiadas, cuando por ejemplo por el consumo de la API se ha traído un nuevo cliente o por ejemplo se ha vendido un nuevo producto financiero.
 

Integración y despliegue continuo

Es común construir pipelines en Jenkins que automaticen el despliegue de APIs. De esta manera se automatiza la publicación de las APIs, su aparición en el Portal de APIs, etc.

Dentro de estos pipelines es común la ejecución de pruebas automáticas. Hay diferentes herramientas que permiten definir colecciones de tests, donde tras cada ejecución se comprueba que el resultado obtenido es el esperado.
 

Conclusiones

Definir una API Strategy implica una serie de acciones técnicas (elegir una plataforma, construir piezas de seguridad, etc) pero también una serie de acciones de negocio como puede ser el nombramiento de API Product Owners, la definición de un roadmap de productos digitales que realmente aporten valor a las áreas de negocio, etc.

Solo cuando las áreas de negocio están implicadas en el API Program es posible construir un marketplace que pueda ser utilizado por un ecosistema de partners para construir aplicaciones innovadoras de transformación digital.

Everis dispone de consultores especializados en integración que pueden ayudar en la definición de una API Strategy.

 

Si has llegado a este artículo sin leer la primera parte de la guía definitiva API Strategy, te recomendamos que no te la pierdas, ya que en él te hablamos de la importancia de una API Strategy, roles y responsabilidades, elegir una plataforma de API, gobierno y buenas prácticas.

Seguir leyendo… API Strategy – La guía definitiva (Parte I)

 

Guía de Posibilidades Profesionales en el Ecosistema de Java