Referencia de la configuración del proxy de API

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

Como desarrollador que trabaja con Apigee, tus actividades de desarrollo principales implican la configuración de proxies de API que funcionen como proxies para APIs o servicios de backend. Este documento es una referencia de todos los elementos de configuración disponibles para ti a fin de compilar proxies de API.

Si aprendes a compilar proxies de API, te recomendamos que comiences con el tema Compila un proxy de API simple.

Edita la configuración del proxy de API mediante uno de los siguientes métodos:

• Usa la IU o la API de Apigee.
• Descarga el paquete de configuración del proxy de API, edítalo manualmente y sube la configuración nueva a Apigee, como se describe en Descarga y carga un paquete de configuración de proxy de API.

Estructura del directorio de configuración del proxy de API

A continuación, se muestra la estructura del directorio de la configuración del proxy de API:

Una configuración de proxy de API consta de los siguientes contenidos:

Configuración básica

/apiproxy/weatherapi.xml

La configuración base de un proxy de API, que define el nombre del proxy de API. El nombre debe ser único dentro de una organización.

Configuración de ejemplo

<APIProxy name="weatherapi">
</APIProxy>

Elementos de la configuración base

ProxyEndpoint

En la siguiente imagen, se muestra el flujo de solicitud y respuesta:

/apiproxy/proxies/default.xml

La configuración de ProxyEndpoint define la interfaz entrante (dirigida al cliente) para un proxy de API. Cuando configuras un extremo de proxy, estableces una configuración de red que define cómo las aplicaciones cliente (apps) deben invocar la API de proxy.

La siguiente configuración de muestra de ProxyEndpoint se almacenará en /apiproxy/proxies:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Los elementos de configuración necesarios en un extremo de proxy básico son los siguientes

Elementos de configuración de ProxyEndpoint

<Property name= \
"request.queryparams.ignore.content.type.charset">true</>

Cómo configurar RouteRules

Un extremo de destino con nombre hace referencia a un archivo de configuración en /apiproxy/targets al que la RouteRule reenvía una solicitud después de que el extremo de proxy la procesa.

Por ejemplo, la siguiente RouteRule hace referencia a la configuración /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Invocación de URL directa

Un extremo de proxy también puede invocar directamente un servicio de backend. La invocación de URL directa omite cualquier configuración de TargetEndpoint con nombre en /apiproxy/targets. Por este motivo, TargetEndpoint opcional es una configuración de proxy de API, aunque, en la práctica, no se recomienda la invocación directa desde extremo de proxy.

Por ejemplo, la siguiente RouteRule siempre realiza una llamada HTTP a http://api.mycompany.com/v2.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

Rutas condicionales

RouteRules se puede encadenar para admitir el enrutamiento dinámico en el entorno de ejecución. Las solicitudes entrantes se pueden enrutar a las opciones de configuración de TargetEndpoint con nombres, directamente a las URL, o a una combinación de ambas, en función de encabezados HTTP, contenido de mensajes, parámetros de consulta o información contextual, como la hora del día, configuración regional, etcétera.

Las RouteRules condicionales funcionan como otras declaraciones condicionales en Apigee. Consulta la referencia de condiciones y la referencia de variables de flujo.

Por ejemplo, la siguiente combinación de RouteRule evalúa primero la solicitud entrante para verificar el valor de un encabezado HTTP. Si el encabezado HTTP routeTo tiene el valor TargetEndpoint1, la solicitud se reenvía al extremo de destino llamado TargetEndpoint1. De lo contrario, la solicitud se reenvía a http://api.mycompany.com/v2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Rutas nulas

Se puede definir una RouteRule nula para admitir situaciones en las que no sea necesario reenviar el mensaje de solicitud al extremo de destino. Esto es útil cuando el extremo de proxy realiza todo el procesamiento necesario, por ejemplo, mediante el uso de JavaScript para llamar a un servicio externo o la recuperación de datos desde una búsqueda al almacén de clave-valor de Apigee.

Por ejemplo, lo siguiente define una ruta nula:

<RouteRule name="GoNowhere"/>

Las rutas nulas condicionales pueden ser útiles. En el siguiente ejemplo, se configura una ruta nula para ejecutarse cuando un encabezado HTTP request.header.X-DoNothing tenga un valor distinto de null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

Recuerda que RouteRules se puede encadenar, por lo que una ruta nula condicional generalmente sería un componente de un conjunto de RouteRules diseñadas para admitir el enrutamiento condicional.

Un uso práctico de una ruta nula condicional sería compatible con el almacenamiento en caché. Mediante el valor de la variable que establece la política de caché, puedes configurar un proxy de API para ejecutar la ruta nula cuando se entrega una entrada desde la caché.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

Un extremo de destino es el equivalente saliente de un extremo de proxy. Un extremo de destino funciona como el cliente de un servicio de backend o una API: envía solicitudes y recibe respuestas.

Un proxy de API no necesita tener extremos de destino. Los extremos de proxy se pueden configurar para que llame a las URLs directamente. Por lo general, un proxy de API sin extremos de destino contiene un extremo de destino que llama directamente a un servicio de backend o que está configurado para llamar a un servicio mediante Java o JavaScript.

Configuración de TargetEndpoint

/targets/default.xml

El extremo de destino define la conexión saliente de Apigee a otro servicio o recurso.

Esta es una muestra de configuración del TargetEndpoint:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
    <Authentication/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

Elementos de configuración de TargetEndpoint

Un extremo de destino puede llamar a un destino de una de las siguientes maneras:

• HTTPTargetConnection para las llamadas HTTP o HTTPS
• LocalTargetConnection para el encadenamiento de proxy a proxy

Configura solo una de estas opciones en un extremo de destino.

Uso del elemento <Authentication>

Referencia de error del elemento <Authentication>

Si usas el elemento <Authentication>, puedes encontrar posibles mensajes de error y sugerencias para solucionar problemas de errores de implementación y entorno de ejecución en la sección Errores de la documentación de la política ServiceCallout.

Ejemplos de elementos <Authentication>

En el siguiente ejemplo, se muestra cómo llamar a un servicio implementado en Cloud Run como destino mediante el elemento Authentication a fin de generar un token de OpenID Connect necesario para autenticar la llamada:

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
      <Properties/>
      <URL>https://cloudrun-hostname.a.run.app/test</URL>
      <Authentication>
          <GoogleIDToken>
             <Audience>https://cloudrun-hostname.a.run.app/test</Audience>
          </GoogleIDToken>
     </Authentication>
  </HTTPTargetConnection>
</TargetEndpoint>

En el siguiente ejemplo, se muestra cómo llamar a un TargetService que apunta a Cloud Run mediante el elemento Authentication a fin de generar un token de OpenID Connect necesario para autenticar la llamada. El elemento HeaderName agrega el token del portador generado a un encabezado llamado X-Serverless-Authorization que se envía al sistema de destino. El encabezado Authorization, si está presente, se deja sin modificar y también se envía en la solicitud.

<TargetEndpoint name="TargetEndpoint-1">
   <HTTPTargetConnection>
     <Authentication>
        <HeaderName>X-Serverless-Authorization</HeaderName>
        <GoogleIDToken>
            <Audience ref="flow.variable.audience">https://cloudrun-hostname.a.run.app</Audience>
        </GoogleIDToken>
     </Authentication>
      <LoadBalancer>
         <Server name="cloud-run-target" />
      </LoadBalancer>
   </HTTPTargetConnection>
</TargetEndpoint>

En el siguiente ejemplo, se muestra cómo llamar a un TargetService que apunta al servicio de Secret Manager de Google. En este ejemplo, el elemento GoogleAccessToken está configurado para generar un token de autenticación de Google a fin de autenticar la solicitud de destino:

<HTTPTargetConnection>
   <Authentication>
      <GoogleAccessToken>
        <Scopes>
          <Scope>https://www.googleapis.com/auth/cloud-platform</Scope>
        </Scopes>
      </GoogleAccessToken>
    </Authentication>
    <URL>
      https://secretmanager.googleapis.com/v1/projects/project-id/secrets/secret-id
    </URL>
</HTTPTargetConnection>

En el siguiente ejemplo, se muestra cómo configurar automáticamente el público del GoogleIDToken. Cuando useTargetUrl es true y la variable a la que se hace referencia no se resuelve como una variable válida, se usa la URL del destino (sin incluir los parámetros de consulta) como el público. Supongamos que la ruta de la solicitud es /foobar y la URL de servidor de destino es https://xyz.com; el público del GoogleIDToken se configurará automáticamente como https://xyz.com/foobar.

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
    <Authentication>
      <GoogleIDToken>
        <Audience ref='myvariable' useTargetUrl="true"/>
      </GoogleIDToken>
    </Authentication>
    <LoadBalancer>
      <Server name="TS" />
    </LoadBalancer>
  </HTTPTargetConnection>
</TargetEndpoint>

Configuración de TargetEndpoint de TLS/SSL

Los extremos de destino a menudo necesita administrar conexiones HTTPS con infraestructura de backend heterogénea. Por este motivo, se admiten varios parámetros de configuración de TLS/SSL.

Elementos de configuración de TargetEndpoint de TLS/SSL

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.2</Protocol>
 <Protocol>TLSv1.3</Protocol>
</Protocols>

El extremo de destino de muestra con la autenticación de cliente saliente habilitada

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <Enforce>true</Enforce>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Para obtener instrucciones detalladas, consulta Opciones para configurar TLS.

Usa variables de flujo para configurar valores TLS/SSL de forma dinámica

También puedes establecer de forma dinámica los detalles de TLS/SSL para admitir requisitos de entorno de ejecución flexibles. Por ejemplo, si tu proxy se conecta a dos objetivos potencialmente diferentes (un destino de prueba y uno de producción), puedes hacer que tu proxy de API detecte de manera programática a qué entorno llama y configure referencias de forma dinámica para el almacén de claves y el almacén de confianza adecuados. En el artículo de la comunidad de Apigee SSLInfo dinámico para TargetEndpoint mediante referencia de variable, se explica esta situación con más detalle y se proporcionan ejemplos de proxy de API que se pueden implementar.

En el siguiente ejemplo de cómo se configuraría la etiqueta <SSLInfo> en una configuración de TargetEndpoint, los valores se pueden proporcionar en el entorno de ejecución, por ejemplo, a través de un texto destacado de Java, una política de JavaScript o una política AssignMessage. Usa las variables de mensajes que contengan los valores que deseas establecer.

Las variables solo se permiten en los siguientes elementos.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Usa referencias para establecer valores TLS/SSL de forma dinámica

Cuando configuras un extremo de destino que usa HTTPS, debes tener en cuenta el caso cuando el certificado TLS/SSL vence o un cambio en la configuración del sistema requiere que actualices el certificado.

Para obtener más información, consulta Controla los certificados vencidos.

Sin embargo, puedes configurar el extremo de destino de forma opcional para usar una referencia al almacén de claves o almacén de certificados confianza. La ventaja de usar una referencia es que puedes actualizar la referencia para que apunte a un almacén de claves o almacén de confianza diferente a fin de actualizar el certificado TLS/SSL sin tener que reiniciar Message Processors.

Por ejemplo, a continuación se muestra un extremo de destino que usa una referencia al almacén de claves:

<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>false</ClientAuthEnabled>
  <KeyStore>ref://keystoreref</KeyStore>
  <KeyAlias>myKeyAlias</KeyAlias>
</SSLInfo>

Usa la siguiente llamada a la API de POST para crear la referencia llamada keystoreref:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>'

En el ejemplo anterior, $TOKEN está configurado como tu token de acceso de OAuth 2.0, como se describe en Obtén un token de acceso de OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usa curl. Para obtener una descripción de las variables de entorno utilizadas, consulta Configura variables de entorno para solicitudes a la API de Apigee.

En la referencia, se especifica el nombre del almacén de claves y su tipo.

Usa la siguiente llamada a la API de GET para ver la referencia:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

En el ejemplo anterior, $TOKEN está configurado como tu token de acceso de OAuth 2.0, como se describe en Obtén un token de acceso de OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usa curl. Para obtener una descripción de las variables de entorno utilizadas, consulta Configura variables de entorno para solicitudes a la API de Apigee.

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

En el ejemplo anterior, $TOKEN está configurado como tu token de acceso de OAuth 2.0, como se describe en Obtén un token de acceso de OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usa curl. Para obtener una descripción de las variables de entorno utilizadas, consulta Configura variables de entorno para solicitudes a la API de Apigee.

Para cambiar más adelante la referencia a fin de que apunte a un almacén de claves diferente, asegúrate de que el alias tenga el mismo nombre, usa la siguiente llamada PUT:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -X PUT \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'

En el ejemplo anterior, $TOKEN está configurado como tu token de acceso de OAuth 2.0, como se describe en Obtén un token de acceso de OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usa curl. Para obtener una descripción de las variables de entorno utilizadas, consulta Configura variables de entorno para solicitudes a la API de Apigee.

TargetEndpoint con balanceo de cargas objetivo

Los extremos de destino admiten el balanceo de cargas en varios servidores de destino con nombres mediante tres algoritmos de balanceo de cargas.

Para obtener instrucciones detalladas, consulta Balanceo de cargas en los servidores de backend.

IntegrationEndpoint

Un extremo de integración es un extremo de destino que ejecuta específicamente integraciones de Apigee. Si configuraste un IntegrationEndpoint, Apigee envía el objeto de solicitud a la plataforma de integración de Apigee para su ejecución. Para ejecutar la integración, además de configurar el IntegrationEndpoint, también debes agregar la política SetIntegrationRequest en tu flujo de proxy.

Puedes configurar la integración para que se ejecute de forma síncrona o asíncrona. Para ello, configura el elemento <AsyncExecution> en la configuración de IntegrationEndpoint. Para obtener más información, consulta La ejecución síncrona frente a la asíncrona. Después de ejecutar la integración, Apigee guarda la respuesta en el mensaje de respuesta.

Configura IntegrationEndpoint

Para configurar un extremo de integración como tu extremo de destino, agrega el elemento IntegrationEndpoint a tu configuración de ProxyEndpoint. La siguiente es una configuración de ProxyEndpoint de muestra:

<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>my-set-integration-request-policy</Name>
            </Step>
        </Request>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow"/>
    <HTTPProxyConnection>
        <BasePath>/integration-endpoint-test</BasePath>
        <Properties/>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <IntegrationEndpoint>my-int-endpoint</IntegrationEndpoint>
    </RouteRule>
</ProxyEndpoint>

En la configuración de ProxyEndpoint de muestra, Apigee realiza las siguientes tareas:

1. En el PreFlow, ejecuta la política llamada my-set-integration-request-policy, que establece el objeto de la solicitud de integración y las variables de flujo de integración.
2. Usa my-int-endpoint como el extremo de destino, como se especifica en la RouteRule.
3. Lee el objeto de solicitud de integración que my-set-integration-request-policy creó.
4. Envía la solicitud a la plataforma de integración de Apigee mediante el objeto de solicitud y las variables de flujo establecidas por la política SetIntegrationRequest.
5. Guarda la respuesta de la integración en el mensaje de respuesta.

El archivo XML que contiene la declaración <IntegrationEndpoint> estará disponible en el directorio APIGEE_BUNDLE_DIRECTORY/apiproxy/integration-endpoints/. Si creas el proxy de API con la opción Develop > API Proxies > CREATE NEW > Integration target, Apigee almacena la declaración en el archivo /apiproxy/integration-endpoints/default.xml. Si creas el XML de extremo de integración desde la IU, puedes proporcionar un nombre personalizado para el archivo XML.

En el siguiente ejemplo, se muestra la declaración del elemento <IntegrationEndpoint> en el archivo XML:

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>false</AsyncExecution>
</IntegrationEndpoint>

Elementos de configuración de IntegrationEndpoint

La ejecución síncrona frente a la asíncrona

Puedes configurar la integración para que se ejecute en modo síncrono o asíncrono. Para comprender la diferencia entre los modos de ejecución síncrono y asíncrono, consulta <AsyncExecution>.

Usa el elemento <AsyncExecution> dentro de </IntegrationEndpoint> para especificar la ejecución síncrona o asíncrona. Si <AsyncExecution> se configura como true, la integración se ejecuta de forma asíncrona. Si lo configuras como false, la integración se ejecuta de forma síncrona.

En el siguiente ejemplo, se establece true en AsyncExecution:

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>true</AsyncExecution>
</IntegrationEndpoint>

Políticas

El directorio /policies en un proxy de API contiene todas las políticas disponibles para adjuntar a flujos en el proxy de API.

Elementos de configuración de la política

Política adjunta

En la siguiente imagen, se muestra la secuencia de ejecución de flujos del proxy de API:

Como se mostró antes:

Las políticas se adjuntan como pasos de procesamiento a Flujos. El nombre de la política se usa para hacer referencia a la política que se aplicará como un paso de procesamiento. El formato de un adjunto de política es el siguiente:

<Step><Name>MyPolicy</Name></Step>

Las políticas se aplican en el orden en que se adjuntan a un flujo. Por ejemplo:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Elementos de configuración del adjunto de política

Flujos

ProxyEndpoint y TargetEndpoint definen una canalización para el procesamiento de mensajes de solicitud y respuesta. Una canalización de procesamiento consiste en un flujo de solicitud y un flujo de respuesta. Cada flujo de solicitud y respuesta se subdivide en un PreFlow, uno o más flujos condicionales o con nombre opcionales, y un PostFlow.

• PreFlow: Siempre se ejecuta. Se ejecuta antes de cualquier flujo condicional.
• PostFlow: Siempre se ejecuta. Se ejecuta después de cualquier flujo condicional.

Además, puedes agregar un PostClientFlow al extremo de destino, que se ejecuta después de que la respuesta se muestra a la app cliente solicitante. Solo se puede adjuntar la política de MessageLogging a este flujo. PostClientFlow reduce la latencia del proxy de API y pone a disposición la información para el registro que no se calcula hasta después de que se muestra la respuesta al cliente, como en client.sent.start.timestamp y client.sent.end.timestamp. El flujo se usa principalmente para medir el intervalo de tiempo entre las marcas de tiempo de inicio y de finalización del mensaje de respuesta.

Este es un ejemplo de un PostClientFlow con una política de registro de mensajes adjunta.

...
  <PostFlow name="PostFlow">
      <Request/>
      <Response/>
  </PostFlow>
  <PostClientFlow>
      <Request/>
      <Response>
          <Step>
              <Name>Message-Logging-1</Name>
          </Step>
      </Response>
  </PostClientFlow>
  ...

La canalización de procesamiento del proxy de API ejecuta flujos en la siguiente secuencia:

Canalización de solicitud:

1. PreFlow de solicitud de proxy
2. Flujos condicionales de solicitud de proxy (opcional)
3. PostFlow de solicitud de proxy
4. PreFlow de solicitudes de destino
5. Flujos condicionales de solicitudes de destino (opcional)
6. PostFlow de solicitud de destino

Canalización de respuesta:

1. PreFlow de la respuesta de destino
2. Flujos condicionales de respuesta de destino (opcional)
3. PostFlow de respuesta de destino
4. PreFlow de respuesta de proxy
5. Flujos condicionales de respuesta del proxy (opcional)
6. PostFlow de respuesta del proxy
7. Respuesta de PostClientFlow (opcional)

Solo los flujos con adjuntos de política deben configurarse en ProxyEndpoint o TargetEndpoint. Solo es necesario especificar PreFlow y PostFlow en una configuración ProxyEndpoint o TargetEndpoint cuando una política debe aplicarse durante el procesamiento de PreFlow o PostFlow.

A diferencia de los flujos condicionales, el orden de los elementos PreFlow y PostFlow no es importante; el proxy de la API siempre se ejecutará cada uno en el punto apropiado de la canalización, sin importar dónde aparezcan en la configuración del extremo.

Flujos condicionales

Los extremos de proxy y los extremos de destino admiten una cantidad ilimitada de flujos condicionales (también conocidos como flujos con nombre).

El proxy de API prueba la condición especificada en el flujo condicional y, si se cumple la condición, el proxy de API ejecuta los pasos de procesamiento. Si no se cumple la condición, se omiten los pasos de procesamiento del flujo condicional. Los flujos condicionales se evalúan en el orden definido en el proxy de API y se ejecuta el primero cuya condición se cumple.

Cuando defines flujos condicionales, obtienes la capacidad de aplicar pasos de procesamiento en un proxy de API en función de lo siguiente:

• URI de solicitud
• Verbo HTTP (GET/PUT/POST/DELETE)
• Valor de un parámetro de búsqueda, un encabezado y un parámetro de forma
• Muchos otros tipos de condiciones

Por ejemplo, en el siguiente flujo condicional, se especifica que se ejecuta solo cuando la ruta del recurso de solicitud es /accesstoken. Cualquier solicitud entrante con la ruta de acceso /accesstoken hace que este flujo se ejecute, junto con cualquier política que esté conectada al flujo. Si la ruta de acceso de la solicitud no incluye el sufijo /accesstoken, el flujo no se ejecuta (aunque otro flujo condicional podría hacerlo).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

Elementos de configuración del flujo

Procesamiento por pasos

Apigee aplica el orden secuencial de flujos condicionales. Los flujos condicionales se ejecutan de arriba abajo. Se ejecuta el primer flujo condicional cuya condición se evalúa como true y solo se ejecuta un flujo condicional.

Por ejemplo, en la siguiente configuración de flujo, cualquier solicitud entrante que no incluya el sufijo de ruta /first o /second hará que se ejecute ThirdFlow, y que se aplique la política llamada Return404.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Recursos

Los “recursos” (archivos de recursos para usar en proxies de API) son secuencias de comandos, código y transformaciones XSL que se pueden adjuntar a flujos mediante políticas. Estos aparecen en la sección Secuencias de comandos del editor de proxy de API en la IU de Apigee.

Consulta Administra recursos para conocer los tipos de recursos compatibles.

Los recursos se pueden almacenar en un proxy de API, un entorno o una organización. En cada caso, se hace referencia a un recurso por nombre en una política. Apigee resuelve el nombre mediante el cambio del proxy de API al entorno, al nivel de la organización.

Se puede hacer referencia a un recurso almacenado en el nivel de la organización mediante las políticas en cualquier entorno. Se puede hacer referencia a un recurso almacenado en el nivel del entorno mediante las políticas en ese entorno. Solo puede hacer referencia a un recurso almacenado en el nivel del proxy de API mediante las políticas en ese proxy de API.