Referencia de configuración de proxies de APIs

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 consisten en configurar proxies de API que funcionen como proxies de APIs o servicios de backend. Este documento es una referencia de todos los elementos de configuración que puede usar al crear proxies de APIs.

Si estás aprendiendo a crear proxies de APIs, te recomendamos que empieces por el tema Desarrollar un proxy de APIs sencillo.

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

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

Estructura de directorios de configuración de proxies de APIs

La estructura del directorio de configuración del proxy de API se muestra a continuación:

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

Configuración base

/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 en una organización.

Ejemplo de configuración:

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

Elementos de configuración base

ProxyEndpoint

En la siguiente imagen se muestra el flujo de solicitudes y respuestas:

/apiproxy/proxies/default.xml

La configuración de ProxyEndpoint define la interfaz de entrada (de cara al cliente) de un proxy de API. Cuando configuras un endpoint de proxy, estás configurando una red que define cómo deben invocar las aplicaciones cliente (aplicaciones) a la API proxy.

La siguiente configuración de ProxyEndpoint de ejemplo se almacenaría 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 obligatorios de un endpoint de proxy básico son los siguientes:

Elementos de configuración de ProxyEndpoint

Cómo configurar RouteRules

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

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

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

Invocación directa de URL

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

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

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

Rutas condicionales

Las RouteRules se pueden encadenar para admitir el enrutamiento dinámico en el tiempo de ejecución. Las solicitudes entrantes se pueden enrutar a configuraciones de TargetEndpoint con nombre, directamente a URLs o a una combinación de ambas, en función de los encabezados HTTP, el contenido del mensaje, los parámetros de consulta o la información contextual, como la hora del día o la configuración regional.

Las RouteRules condicionales funcionan como otras instrucciones 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 endpoint de destino llamado TargetEndpoint1. Si no es así, la solicitud entrante 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 un RouteRule nulo para admitir situaciones en las que no sea necesario reenviar el mensaje de solicitud al endpoint de destino. Esto resulta útil cuando el endpoint del proxy realiza todo el procesamiento necesario, por ejemplo, usando JavaScript para llamar a un servicio externo o recuperar datos de una búsqueda en el almacén de clave/valor de Apigee.

Por ejemplo, en el código siguiente se define una ruta nula:

<RouteRule name="GoNowhere"/>

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

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

Recuerda que las RouteRules se pueden encadenar, por lo que una ruta nula condicional suele ser un componente de un conjunto de RouteRules diseñado para admitir el enrutamiento condicional.

Un uso práctico de una ruta nula condicional sería para admitir el almacenamiento en caché. Si usas el valor de la variable definida por la política de caché, puedes configurar un proxy de API para que ejecute la ruta nula cuando se sirva una entrada desde la caché.

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

TargetEndpoint

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

Un proxy de API no tiene por qué tener ningún endpoint de destino. Los endpoints proxy se pueden configurar para llamar a URLs directamente. Un proxy de API sin endpoints de destino suele contener un endpoint de proxy 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 endpoint de destino define la conexión saliente de Apigee a otro servicio o recurso.

A continuación, se muestra un ejemplo de configuración de TargetEndpoint:

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

Elementos de configuración de TargetEndpoint

Un endpoint de destino puede llamar a un destino de una de las siguientes formas:

• HTTPTargetConnection para llamadas HTTP o HTTPS
• LocalTargetConnection para la cadena de proxy a proxy local

Configure solo uno de ellos en un endpoint de destino.

<Properties>
  <Property name="response.payload.parse.limit">15M</Property>
</Properties>

Uso del elemento <Authentication>

Referencia de error del elemento <Authentication>

Si utilizas el elemento <Authentication>, puedes consultar los posibles mensajes de error y los consejos para solucionar problemas de implementación y de tiempo 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 para 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 para generar un token de OpenID Connect necesario para autenticar la llamada. El elemento HeaderName añade el token de portador generado a un encabezado llamado X-Serverless-Authorization que se envía al sistema de destino. El encabezado Authorization, si está presente, no se modifica 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 Secret Manager de Google. En este ejemplo, el elemento GoogleAccessToken se configura para generar un token de autenticación de Google que autentique 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 definir automáticamente la audiencia de GoogleIDToken. Si useTargetUrl es true y la variable a la que se hace referencia no se resuelve en una variable válida, se usa la URL del destino (sin incluir los parámetros de consulta) como audiencia. Supongamos que la ruta de solicitud es /foobar y la URL del servidor de destino es https://xyz.com. En ese caso, la audiencia de GoogleIDToken se definirá 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 endpoints de destino suelen tener que gestionar conexiones HTTPS con una infraestructura de backend heterogénea. Por este motivo, se admiten varios ajustes de configuración de TLS/SSL.

TLS/SSL Elementos de configuración de TargetEndpoint

<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>

Especificar la aplicación de SSL a nivel de entorno

Si SSLInfo.Enforce se define como true o false, el valor especificado anula cualquier opción de aplicación granular especificada en los bloques <SSLInfo> de las configuraciones de TargetEndpoint o TargetServer.

Si SSLInfo.Enforce no se ha definido, la aplicación de SSL se determina mediante los valores especificados con el elemento <Enforce> en bloques <SSLInfo> individuales. Para obtener más información, consulta la sección TLS/SSL TargetEndpoint configuration (Configuración de TargetEndpoint de TLS/SSL).

En el siguiente ejemplo, SSLInfo.Enforce se ha definido como true. En el resultado, puede ver que se ha aplicado SSL en el entorno especificado.

VALUE=true
curl -Ss -v -X PUT \
    "https://apigee.googleapis.com/v1/organizations/MYORG/environments/MYENV" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer TOKEN" \
    -d '{
        "name": "MYENV",
        "properties": {
            "property": [{
                "name": "features.SSLInfo.Enforce",
                "value": "'"$VALUE"'"
            }]
        }
    }'
  

Resultado:

{
  ...
  "properties": {
    "property": [
      {
        "name": "features.SSLInfo.Enforce",
        "value": "true"
      }
    ]
  },
  ...
}

Endpoint de destino de ejemplo 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.

Usar variables de flujo para definir valores de TLS/SSL de forma dinámica

También puedes definir dinámicamente los detalles de TLS/SSL para admitir requisitos de tiempo de ejecución flexibles. Por ejemplo, si tu proxy se conecta a dos destinos potencialmente diferentes (un destino de prueba y un destino de producción), puedes hacer que tu proxy de API detecte mediante programación a qué entorno está llamando y que defina dinámicamente las referencias al almacén de claves y al almacén de confianza adecuados. En el artículo de la comunidad de Apigee Dynamic SSLInfo for TargetEndpoint using variable reference se explica este caso práctico con más detalle y se proporcionan ejemplos de proxies de API que se pueden implementar.

En el siguiente ejemplo de cómo se definiría la etiqueta <SSLInfo> en una configuración de TargetEndpoint, los valores se pueden proporcionar en tiempo de ejecución, por ejemplo, mediante una llamada Java, una política de JavaScript o una política AssignMessage. Usa las variables de mensaje que contengan los valores que quieras definir.

Las variables solo se pueden usar 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>

Usar referencias para definir valores de TLS/SSL de forma dinámica

Al configurar un endpoint de destino que usa HTTPS, debes tener en cuenta el caso en el que caduque el certificado TLS/SSL o en el que un cambio en la configuración del sistema requiera que actualices el certificado.

Para obtener más información, consulta Gestionar certificados caducados.

Sin embargo, puede configurar el endpoint de destino para que use una referencia al almacén de claves o al almacén de confianza. La ventaja de usar una referencia es que puedes actualizarla para que apunte a otro almacén de claves o de confianza y, de esta forma, actualizar el certificado TLS/SSL sin tener que reiniciar los procesadores de mensajes.

Por ejemplo, a continuación se muestra un endpoint 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 POST para crear la referencia llamada keystoreref:

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

Donde $TOKEN es tu token de acceso OAuth 2.0, tal como se describe en Obtener un token de acceso OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usar curl. Para ver una descripción de las variables de entorno que puedes usar, consulta Definir variables de entorno para solicitudes a la API de Apigee.

La referencia especifica el nombre del almacén de claves y su tipo.

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

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

Donde $TOKEN es tu token de acceso OAuth 2.0, tal como se describe en Obtener un token de acceso OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usar curl. Para ver una descripción de las variables de entorno que puedes usar, consulta Definir variables de entorno para solicitudes a la API de Apigee.

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

Donde $TOKEN es tu token de acceso OAuth 2.0, tal como se describe en Obtener un token de acceso OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usar curl. Para ver una descripción de las variables de entorno que puedes usar, consulta Definir variables de entorno para solicitudes a la API de Apigee.

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

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

Donde $TOKEN es tu token de acceso OAuth 2.0, tal como se describe en Obtener un token de acceso OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usar curl. Para ver una descripción de las variables de entorno que puedes usar, consulta Definir variables de entorno para solicitudes a la API de Apigee.

TargetEndpoint con balanceo de carga de destino

Los endpoints de destino admiten el balanceo de carga en varios servidores de destino con nombre mediante tres algoritmos de balanceo de carga.

Para obtener instrucciones detalladas, consulta el artículo sobre el balanceo de carga en servidores de backend.

IntegrationEndpoint

Un IntegrationEndpoint es un endpoint de destino que ejecuta específicamente integraciones de Apigee. Si has configurado un IntegrationEndpoint, Apigee envía el objeto request a la plataforma de integración de Apigee para que se ejecute. Para ejecutar la integración, además de configurar el IntegrationEndpoint, también debes añadir la política SetIntegrationRequest al flujo de tu proxy.

Puede configurar su integración para que se ejecute de forma síncrona o asíncrona definiendo el elemento <AsyncExecution> en la configuración de IntegrationEndpoint. Para obtener más información, consulta Ejecución síncrona y asíncrona. Después de ejecutar la integración, Apigee guarda la respuesta en el mensaje de respuesta.

Configurar IntegrationEndpoint

Para configurar un endpoint de integración como endpoint de destino, añade el elemento IntegrationEndpoint a la configuración de ProxyEndpoint. A continuación, se muestra un ejemplo de configuración de ProxyEndpoint:

<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 ejemplo, Apigee realiza las siguientes tareas:

1. En PreFlow, ejecuta la política llamada my-set-integration-request-policy, que define el objeto de solicitud de integración y las variables de flujo de integración.
2. Usa my-int-endpoint como endpoint de destino, tal como se especifica en RouteRule.
3. Lee el objeto de solicitud de integración creado por my-set-integration-request-policy.
4. Envía la solicitud a la plataforma de integración de Apigee mediante el objeto de solicitud y las variables de flujo definidas 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 tu 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 archivo XML del endpoint de integración desde la interfaz de usuario, puedes darle un nombre personalizado.

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

Ejecución síncrona y asíncrona

Puedes configurar la integración para que se ejecute en modo síncrono o asíncrono. Para entender 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 asignas el valor true a <AsyncExecution>, 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 asigna el valor true a AsyncExecution:

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

Políticas

El directorio /policies de un proxy de API contiene todas las políticas que se pueden adjuntar a los flujos del proxy de API.

Elementos de configuración de políticas

Adjunto de política

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

Como se muestra arriba:

Las políticas se adjuntan como pasos de procesamiento a los flujos de trabajo. El nombre de la política se usa para hacer referencia a la política que se va a aplicar como paso de procesamiento. El formato de un archivo adjunto de una política es el siguiente:

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

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

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

Elementos de configuración de archivos adjuntos de políticas

Flows

ProxyEndpoint y TargetEndpoint definen un flujo de procesamiento de mensajes de solicitud y respuesta. Una canalización de procesamiento consta de un flujo de solicitudes y un flujo de respuestas. Cada flujo de solicitud y cada flujo de respuesta se dividen en un PreFlow, uno o varios 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 añadir un PostClientFlow al endpoint del proxy, que se ejecuta después de que se devuelva la respuesta a la aplicación cliente que ha enviado la solicitud. Solo se puede adjuntar la política MessageLogging a este flujo. PostClientFlow reduce la latencia del proxy de API y hace que la información esté disponible para el registro, que no se calcula hasta que se devuelve la respuesta al cliente, como 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 fin del mensaje de respuesta.

A continuación, se muestra un ejemplo de 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>
  ...

El flujo de procesamiento del proxy de API ejecuta los flujos en la siguiente secuencia:

Request Pipeline:

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

Flujo de procesamiento de respuestas:

1. Target Response PreFlow
2. Flujos condicionales de respuesta objetivo (opcional)
3. Target Response PostFlow
4. PreFlow de respuesta de proxy
5. Flujos condicionales de respuesta de proxy (opcional)
6. Proxy Response PostFlow
7. Respuesta de PostClientFlow (opcional)

Solo los flujos con políticas adjuntas deben configurarse en las configuraciones de ProxyEndpoint o TargetEndpoint. PreFlow y PostFlow solo deben especificarse en una configuración de ProxyEndpoint o TargetEndpoint cuando se deba aplicar una política 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 API siempre ejecutará cada uno en el punto adecuado de la canalización, independientemente de dónde aparezcan en la configuración de Endpoint.

Flujos condicionales

Los endpoints de proxy y los endpoints de destino admiten un número ilimitado de flujos condicionales (también conocidos como flujos con nombre).

El proxy de API comprueba la condición especificada en el flujo condicional y, si se cumple, el proxy de API ejecuta los pasos de procesamiento del flujo condicional. 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 cumpla.

Al definir flujos condicionales, puedes 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 consulta, un encabezado y un parámetro de formulario
• Muchos otros tipos de condiciones

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

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

Elementos de configuración de flujo

Procesamiento de pasos

Apigee aplica el orden secuencial de los 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, lo que aplicará 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 que se usan en proxies de API) son secuencias de comandos, código y transformaciones XSL que se pueden adjuntar a flujos mediante políticas. Aparecen en la sección Secuencias de comandos del editor de proxy de la API en la interfaz de Apigee.

Consulta los tipos de recursos admitidos en el artículo sobre gestión de recursos.

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 su nombre en una política. Apigee resuelve el nombre pasando del proxy de API al entorno y, por último, al nivel de organización.

Se puede hacer referencia a un recurso almacenado a nivel de organización desde las políticas de cualquier entorno. Las políticas de un entorno pueden hacer referencia a los recursos almacenados en ese entorno. Un recurso almacenado a nivel de proxy de API solo puede hacer referencia a las políticas de ese proxy de API.