Breve introducción a Apigee

Durante el último año he estado trabajando sobre la plataforma Apigee para el desarrollo de APIs. En el presente artículo recogeré una breve introducción a la plataforma en base a lo consultado para introducirme en esta plataforma así como resúmenes de la documentación existente.

¿Qué es Apigee?

Apigee es una plataforma que nos permite la administración del ciclo de vida completo de las APIs permitiéndonos diseñar, proteger, desplegar, supervisar y escalar estas.

Apigee se ajusta al tráfico de las APIs en tiempo de ejecución y aplica un conjunto de políticas preconfiguradas, como la validación de claves, la administración de cuotas, la transformación, la autorización y el control del acceso.

Apigee permite a los proveedores de las APIs la posibilidad de ofrecer a los desarrolladores un portal personalizable para que les resulte más fácil utilizarlas de forma segura y medir tanto el rendimiento como el uso.

Apigee Edge

Apigee Edge es una plataforma con la que es posible construir API proxies, que son APIs RESTfull basadas en HTTP, que permiten interactuar con los servicios provistos por una organización. Los API proxies proporcionan toda la potencia de la plataforma de APIs de Apigee para añadir seguridad a las llamadas a la API, monitorizar el tráfico, control de los mensajes, manejo de errores, caché, construir portales para el desarrollador, documentar APIs, analizar el tráfico de datos, proteger las APIs y mucho más.

API proxy vs API product

Un API proxy es el endpoint HTTP que los desarrolladores usan para acceder a los servicios de backend. Mientras sea posible, lo normal es que no se hagan accesibles API proxies individuales. En su lugar, se agrupan uno o más API proxies dentro de un API product.

Un API product es un conjunto de API proxies combinados en un plan de servicios. Ese plan de servicio puede establecer limitaciones de acceso en los API proxies, proveer seguridad, permitir monitorización y análisis así como proveer caracterísitcas adicionales. Los API products son también el mecanismo principal de Edge para la autorización y control de acceso a las APIs.

Estructura de un API proxy

Un API proxy se conforma por dos tipos de endpoints:

• ProxyEndpoints: Define la manera en la que las aplicaciones clientes consumen las APIs. Los ProxyEndpoints se configuran como la definición de la URL del API proxy. Los proxy endpoints también determinan si las aplicaciones pueden acceder al API proxy mediante HTTP o HTTPs. Por lo general, se adjuntas las políticas en este punto para incluir las carateristicas comentadas con anterioridad: forzar la seguridad, chequear cuotas, otros tipos de control de acceso, etc...

• TargetEndpoints: Define la manera en la que el API proxy interactua con los servicios provistos por la organización o de terceros. Los TargetEndpoints se configuran para avanzar las peticiones a la API hacia el servicio apropiado, incluyendo la configuración de seguridad, protocolos HTTP o HTTPs y cualquier otra información de conexión necesaria. Es posible adjuntar políticas en este punto para asegurar que los mensajes de respuesta están formateado adecuadamente para la aplicación cliente que realizó la petición inicial.

A continuación se puede visualizar los API proxies de la siguiente manera, incluyendo cómo sería el flujo de las peticiones:

     Fuente: Documentación de Apigee. Qué es un flujo

Políticas

Una política (policy) es un componente de Edge que se pueden adjuntar a diferentes puntos en el flujo del mensaje a través de los API proxies (Preflow, Conditional Flows, PostFlow, PostClientFlow). Las políticas pueden transformar el formato de los mensajes,  forzar procesos de acceso, llamar a servicios remotos, autorizar usuarios, examinar contenido de mensajes en busca de potenciales amenzas y mucho más.

Clasificación de políticas

• Políticas para administración del tráfico: permite configurar cachés, establecer límites de concurrencia, mitigar los efectos de picos en las peticiones, etc...
• Caching policies:
• InvalidateCache policy 
• LookupCache policy 
• PopulateCache policy 
• ResponseCache policy
• ConcurrentRateLimit policy
• Quota policy
• ResetQuota policy
• SpikeArrest policy

• Políticas de mediación: permite realizar transformación de mensajes, análisis y validación así como lanzar errores y alertas.
• AccessEntity policy
• AssignMessage policy
• ExtractVariables policy
• JSONtoXML policy
• KeyValueMapOperations policy
• RaiseFault policy
• SOAPMessageValidation policy
• XMLtoJSON policy
• XSLTransform policy 

• Políticas de seguridad: permite controlar el acceso a las APIs mediante Oauth, validación de claves de acceso a APIs y otras características de protección frente amenazas.
• AccessControl policy
• BasicAuthentication policy
• JSONThreadProtection policy
• JWT policies:
  • DecodeJWT policy
  • GenerateJWT policy
  • VerifyJWTpolicy
• LDAP policy*†
• OAuth v2 policies:
  • DeleteOAuthv2Info policy
  • GetOAuthv2Info policy
  • OAuthv2 policy
  • SetOAuth v2 Info policy
• OAuth v1 policies:
  • DeleteOAuthv1Info policy
  • GetOAuthv1Info policy
  • OAuthv1.0a policy
• RegularExpressionProtection policy
• SAMLAssertion policy
• VerifyAPIKey policy
• XMLThreatProtection policy

• Políticas de extensión: permite definir políticas con funcionalidades personalizada, como llamar a servicios, recolección de datos de mensajes, y llamadas a scripts de Java, JavaScript, y Python.
• FlowCallout policy
• JavaCallout policy
• JavaScript policy
• MessageLogging policy
• PythonScript policy
• ServiceCallout policy
• StatisticsCollector policy

---

* Disponible solo seleccinando un Edge plans

† Solo para instalaciones On-premise

Con esto concluyo mi introducción a Apigee, enfocado en Apigee Edge, para el desarrollo de APIs. En posteriores entradas recogeré casos concretos a los que me he enfrentado o para los que he consultado información en la documentación y foros.

Fuentes y enlaces de interés para complementar esta breve introducción:

• Página de Apigee
• Documentación oficial de Apigee
• Soporte y comunidad de Apigee