Ciclo de vida del desarrollo de API

Estás viendo la documentación de Apigee Edge.
Ve a la documentación de Apigee X. info

Cada organización tiene un ciclo de vida de desarrollo de software (SDLC) único. Por lo general, es necesario sincronizar y alinear la implementación del proxy de API con los mismos procesos que usas en la actualidad para desarrollar, implementar y probar otras aplicaciones.

Los servicios de API proporcionan herramientas y API de RESTful que te permiten integrar la implementación y administración del proxy de API en la SDLC de tu organización. Un uso común de la API de RESTful es escribir secuencias de comandos o códigos que implementan proxies de API de manera programática, o que migran proxies de API de un entorno a otro, como parte de un proceso automatizado más grande que también implementa o migra otras aplicaciones. Los servicios de API no realizan suposiciones acerca de tu SDLC (ni de nadie más). En cambio, exponen funciones atómicas que puede coordinar tu equipo de desarrollo para automatizar y optimizar el ciclo de vida de desarrollo de la API.

Las API de servicios de API se documentan en la referencia de la API. Consulta la Comienza a usar la referencia de la API.

Entornos

Todas las organizaciones en Apigee Edge tienen al menos dos entornos de implementación que están disponibles para proxies de API: “prueba” y “producción”. La distinción entre los dos entornos es arbitraria: cada uno solo se identifica con un conjunto diferente de direcciones de red (URL). El objetivo es proporcionarte un dominio en el que puedas compilar y verificar los proxies de API antes de que la API se exponga a desarrolladores externos.

Puedes aprovechar estos entornos para sincronizar el desarrollo del proxy de API procesado con tu SDLC. Cada entorno se define mediante una dirección de red, que te permite segregar el tráfico entre los proxies de API en los que trabajas y los que acceden a las apps en el entorno de ejecución. Las direcciones de red disponibles para cada entorno se definen en el conjunto de VirtualHosts disponibles en ese entorno.

Entrante, el servidor TLS/SSL se habilita de forma automática para cada entorno. Dos VirtualHosts están predefinidos en cada entorno: default y secure. El valor predeterminado define una dirección HTTP, mientras que el seguro define una dirección HTTP/S, con TLS/SSL del servidor preconfigurado. En una configuración de proxy de API, debes indicar que VirtualHosts debe escuchar el ProxyEndpoint. Por lo general, cuando realizas una promoción a producción, debes inhabilitar HTTP. Para ello, quita el VirtualHost default de la configuración del proxy de API.

Por ejemplo, el siguiente ProxyEndpoint escucha en HTTP y HTTPS.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Cuando borras el VirtualHost default de la configuración de ProxyEndpoint, creas un proxy de API que solo escucha en HTTPS y no en HTTP.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Puedes ver los VirtualHosts disponibles en un entorno mediante la selección de Entornos en el menú principal de la IU de administración.

Los entornos también proporcionan segregación de datos y recursos. Por ejemplo, puedes configurar diferentes cachés en prueba y producción, a las que solo pueden acceder los proxies de API que se ejecuten en ese entorno. Además, las claves de API que se emiten en el entorno de prueba no son válidas en el entorno de producción y viceversa.

Implementa proxies de API en entornos

Cuando crees un proxy de API, deberás decidir en qué entorno trabajarás. Puedes elegir crear un proxy de API nuevo en producción, pero no se recomienda, ya que puedes exponer una API a los desarrolladores antes de que esté lista. En general, primero crea un proxy de API en test que, después de realizar la prueba, promueve a prod.

Para obtener más información, consulta Información sobre la implementación.

Desarrollo iterativo en las pruebas

Cuando trabajas en un proxy de API, los servicios de API guardan iteraciones de tu configuración como revisiones. Cuando implementas un proxy de API, eliges una revisión específica para implementar. Por lo general, implementarás la revisión más reciente y, si es necesario, regresarás al número de revisión anterior. Puedes elegir dónde implementar esas revisiones. Por ejemplo, puedes promover una revisión para producción con el fin de permitir que los desarrolladores comiencen a trabajar con tu API. Al mismo tiempo, es posible que iteres varias revisiones en la prueba, en la que agregas funciones o mejoras. Luego, cuando estés listo, puedes implementar la revisión nueva para producción, y reemplazar la revisión existente en ese entorno. Mediante este método, siempre puedes tener una revisión en vivo de tu API disponible para los desarrolladores mientras estás desarrollas.

Promoción de producción

Cuando un proxy de API se implementa y se prueba por completo, está listo para que se promueva a producción. La revisión del proxy de API en prueba se usará para reemplazar la revisión del proxy de API que se implementó en producción.

Los servicios de API proporcionan capacidades para garantizar una implementación continua de los proxies de API, lo que minimiza el impacto en las aplicaciones y los usuarios finales durante el procedimiento de implementación.

Implementa secuencias de comandos

La IU de administración de Apigee Edge te permite implementar proxies de API para producirlos directamente desde el compilador de proxy de API. Sin embargo, en muchas situaciones, los requisitos de seguridad, confiabilidad y coherencia exigen los procedimientos de implementación de secuencias de comandos de los equipos de desarrollo. Para hacerlo, puedes escribir el código y las secuencias de comandos que invoquen la API de RESTful que los servicios de API exponen.

Recursos del entorno

Para obtener un control adicional durante la promoción, te recomendamos que solo iteres los proxies de API en la fase de prueba y realices la menor cantidad posible de cambios en los proxies de API implementados en producción.

Para ello, debes asegurarte de que determinados recursos asociados con cada entorno estén configurados de tal manera que puedan permanecer estáticos en una configuración de proxy de API.

• URL de destino: es común que los proxies de API llamen a diferentes URL de backend durante las pruebas y la producción. Puedes usar las configuraciones de TargetServer para crear parámetros de configuración de TargetEndpoint independientes del entorno. Consulta Balanceo de cargas entre servidores de backend.
• Mapas de caché y de clave-valor: los recursos de persistencia tienen un alcance por entorno. Debes asegurarte de que las convenciones de nombres se usen para permitir que los proxies de API almacenen datos sin requerir cambios de configuración durante la promoción. Consulta Crea y edita una caché de entorno.
• Objetivos de ServiceCallout: los textos de servicio pueden usar diferentes objetivos según el entorno, por ejemplo, si un ServiceCallout en el entorno de prueba consume un servicio de demostración. Consulta Política de texto destacado de servicio.

Para hacer que las configuraciones de proxy de API sean independientes del entorno, también puedes usar declaraciones condicionales. La declaración condicional creada con la variable environment.name se puede usar para evaluar el entorno actual antes de aplicar una política o antes de enrutar a una URL en el backend.

Para obtener más información, consulta Información sobre la implementación.