Referência de configuração do proxy de API

Esta página se aplica à Apigee e à Apigee híbrida.

Confira a documentação da Apigee Edge.

Como um desenvolvedor que trabalha com o Apigee, suas principais atividades de desenvolvimento envolvem a configuração de proxies de API que funcionam como proxies para APIs ou serviços de back-end. Este documento é uma referência de todos os elementos de configuração disponíveis quando você cria proxies de API.

Se você estiver aprendendo a criar proxies de API, é recomendável começar com o tópico Como criar um proxy de API simples.

Edite a configuração do proxy da API usando um dos seguintes métodos:

• Use a IU ou a API da Apigee.
• Faça o download do pacote de configuração de proxy da API, edite-o manualmente e faça o upload da nova configuração para a Apigee, conforme descrito em Como fazer o download e upload de um pacote de configuração de proxy da API.

Estrutura de diretórios da configuração de proxy da API

Veja abaixo a estrutura de diretório de configuração de proxy da API:

Uma configuração de proxy de API consiste no seguinte conteúdo:

Configuração básica

/apiproxy/weatherapi.xml

A configuração básica de um proxy de API, que define o nome do proxy de API. O nome precisa ser exclusivo na organização.

Exemplo de configuração:

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

Elementos de configuração básica

ProxyEndpoint

A imagem a seguir mostra o fluxo de solicitação/resposta:

/apiproxy/proxies/default.xml

A configuração do ProxyEndpoint define a interface de entrada (do cliente) para um proxy de API. Ao configurar um endpoint de proxy, você define uma configuração de rede que define como os aplicativos clientes (apps) precisam invocar a API com proxy.

A seguinte amostra de ProxyEndpoint seria armazenada em /apiproxy/proxies:

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

Os elementos de configuração necessários em um endpoint de proxy básico são:

Elementos de configuração do ProxyEndpoint

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

Como configurar as RouteRules

Um endpoint de destino nomeado se refere a um arquivo de configuração em /apiproxy/targets para onde a RouteRule encaminha uma solicitação após ser processada pelo endpoint do proxy.

Por exemplo, a RouteRule a seguir se refere à configuração /apiproxy/targets/myTarget.xml:

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

Invocação direta de URL

Um endpoint de proxy também pode invocar diretamente um serviço de back-end. A invocação direta de URL ignora qualquer configuração do TargetEndpoint nomeada em /apiproxy/targets. Por isso, o TargetEndpoint é uma configuração opcional de proxy de API, embora, na prática, a invocação direta do endpoint de proxy não seja recomendada.

Por exemplo, a RouteRule a seguir faz uma chamada HTTP para http://api.mycompany.com/v2.

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

Rotas condicionais

É possível encadear rotas para oferecer compatibilidade com o roteamento dinâmico no ambiente de execução. As solicitações de entrada podem ser encaminhadas para configurações nomeadas do TargetEndpoint, diretamente para URLs ou uma combinação dos dois, com base em cabeçalhos HTTP, conteúdo de mensagens, parâmetros de consulta ou informações contextuais, como hora do dia, local etc.

As RouteRules condicionais funcionam como outras instruções condicionais no Apigee. Consulte a Referência de condições e Referência de variáveis de fluxo.

Por exemplo, a combinação da RouteRule a seguir avalia primeiro a solicitação de entrada para verificar o valor de um cabeçalho HTTP. Se o cabeçalho HTTP routeTo tiver o valor TargetEndpoint1, a solicitação será encaminhada para o endpoint de destino chamado TargetEndpoint1. Caso contrário, a solicitação de entrada será encaminhada para 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>

Rotas nulas

Uma RouteRule nula pode ser definida para oferecer suporte a cenários em que a mensagem de solicitação não precisa ser encaminhada para o endpoint de destino. Isso é útil quando o endpoint de proxy executa todo o processamento necessário, por exemplo, usando JavaScript para chamar um serviço externo ou recuperar dados de uma pesquisa para o armazenamento de chave/valor da Apigee.

Por exemplo, o seguinte define uma rota nula:

<RouteRule name="GoNowhere"/>

Rotas nulas condicionais podem ser úteis. No exemplo a seguir, uma rota nula está configurada para ser executada quando um cabeçalho HTTP request.header.X-DoNothing tem um valor diferente de null.

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

Lembre-se de que RouteRules podem ser encadeadas. Portanto, uma rota nula condicional normalmente seria um componente de um conjunto de RouteRules projetadas para oferecer suporte ao encaminhamento condicional.

O uso prático de uma rota nula condicional seria como suporte ao armazenamento em cache. Usando o valor da variável definido pela política de cache, é possível configurar um proxy de API para executar a rota nula quando uma entrada é veiculada do cache.

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

TargetEndpoint

Um endpoint de destino é o equivalente de saída de um endpoint de proxy. Um endpoint de destino funciona como o cliente de um serviço de back-end ou API: envia solicitações e recebe respostas.

Um proxy de API não precisa ter endpoints de destino. É possível configurar endpoints de destino para chamar URLs diretamente. Um proxy de API sem endpoints de destino geralmente contém um endpoint de destino que chama diretamente um serviço de back-end ou que está configurado para chamar um serviço usando Java ou JavaScript.

Configuração do TargetEndpoint

/targets/default.xml

O endpoint de destino define a conexão de saída do Apigee para outro serviço ou recurso.

Veja um exemplo de configuração do TargetEndpoint:

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

Elementos de configuração do TargetEndpoint

Um endpoint de destino pode chamar um destino de uma das seguintes maneiras:

• HTTPTargetConnection para chamadas HTTP ou HTTPS
• LocalTargetConnection para encadeamento local de proxy para proxy

Configure apenas um deles em um endpoint de destino.

Uso do elemento <Authentication>

Referência de erro do elemento <Authentication>

Se você estiver usando o elemento <Authentication>, poderá encontrar possíveis mensagens de erro e dicas de solução de problemas para erros de implantação e tempo de execução na seção Erros da documentação da política de ServiceCallout.

Exemplos de elementos <Authentication>

O exemplo a seguir mostra como chamar um serviço implantado no Cloud Run como destino usando o elemento Authentication para gerar um token do OpenID Connect necessário para autenticar a chamada:

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

O exemplo a seguir mostra como chamar um TargetService que aponta para o Cloud Run usando o elemento Authentication para gerar um token do OpenID Connect necessário para autenticar a chamada: O elemento HeaderName adiciona o token do portador gerado a um cabeçalho chamado X-Serverless-Authorization que é enviado ao sistema de destino. O cabeçalho Authorization, se presente, não é modificado e também é enviado na solicitação.

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

No exemplo a seguir, veja como chamar um TargetService que aponta para o serviço do Gerenciador de secrets do Google. Neste exemplo, o elemento GoogleAccessToken é configurado para gerar um token de autenticação do Google para autenticar a solicitação 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>

O exemplo a seguir mostra como definir automaticamente o público-alvo do GoogleIDToken. Quando useTargetUrl for true e a variável referenciada não for resolvida como uma variante válida, o URL de destino (exceto os parâmetros de consulta) será usado como público-alvo. Se o caminho da solicitação for /foobar e o URL do servidor de destino for https://xyz.com, o público-alvo do GoogleIDToken será definido automaticamente 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>

Configuração de TargetEndpoint TLS/SSL

Os endpoints de destino geralmente precisam gerenciar conexões HTTPS com a infraestrutura de back-end heterogênea. Por isso, várias configurações de configuração TLS/SSL são compatíveis.

Elementos de configuração do TargetEndpoint 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>

Exemplo do endpoint de destino com a autenticação de cliente de saída ativada

<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 instruções detalhadas, consulte Opções de configuração de TLS.

Como usar variáveis de fluxo para definir valores de TLS/SSL dinamicamente

Também é possível definir detalhes de TLS/SSL dinamicamente para oferecer suporte aos requisitos de ambiente de execução flexível. Por exemplo, se o proxy se conectar a dois destinos potencialmente diferentes (um destino de teste e um destino de produção), será possível fazer com que o proxy de API detecte de forma programática qual ambiente está chamando e defina referências ao keystore e ao truststore apropriados dinamicamente. O artigo Dynamic SSLInfo for TargetEndpoint using variable reference (em inglês) da comunidade Apigee explica esse cenário em mais detalhes e fornece exemplos de proxy da API implantáveis.

No exemplo a seguir de como a tag <SSLInfo> seria definida em uma configuração de TargetEndpoint, os valores podem ser fornecidos no ambiente de execução, por exemplo, por uma chamada de Java, uma política JavaScript ou uma política AssignMessage. Use as variáveis de mensagem que contenham os valores que você quer definir.

As variáveis são permitidas somente nos elementos a seguir.

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

Como usar referências para definir valores de TLS/SSL dinamicamente

Ao configurar um endpoint de destino que usa HTTPS, é preciso considerar o caso quando o certificado TLS/SSL expira ou uma alteração na configuração do sistema exige a atualização do certificado.

Para mais informações, consulte Como lidar com certificados expirados.

No entanto, você tem a opção de configurar o endpoint de destino para usar uma referência ao keystore ou truststore. A vantagem de usar uma referência é poder atualizá-la para apontar para um keystore ou truststore diferente para atualizar o certificado TLS/SSL sem precisar reiniciar o processador de mensagens.

Por exemplo, abaixo é mostrado um endpoint de destino que usa uma referência ao keystore:

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

Use a seguinte chamada POST API para criar a referência chamada 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>'

Em que $TOKEN está definido como seu token de acesso OAuth 2.0, conforme descrito em Como receber um token de acesso OAuth 2.0. Para informações sobre as opções de curl usadas neste exemplo, consulte Como usar curl. Para uma descrição das variáveis de ambiente usadas, consulte Como configurar variáveis de ambiente para solicitações da API Apigee.

A referência especifica o nome e o tipo do keystore.

Use a chamada GET API a seguir para visualizar a referência:

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

Em que $TOKEN está definido como seu token de acesso OAuth 2.0, conforme descrito em Como receber um token de acesso OAuth 2.0. Para informações sobre as opções de curl usadas neste exemplo, consulte Como usar curl. Para uma descrição das variáveis de ambiente usadas, consulte Como definir variáveis de ambiente para solicitações de API da Apigee.

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

Em que $TOKEN está definido como seu token de acesso OAuth 2.0, conforme descrito em Como receber um token de acesso OAuth 2.0. Para informações sobre as opções de curl usadas neste exemplo, consulte Como usar curl. Para uma descrição das variáveis de ambiente usadas, consulte Como configurar variáveis de ambiente para solicitações da API Apigee.

Posteriormente, para alterar a referência e apontar para um keystore diferente, verifique se o alias tem o mesmo nome e use a seguinte chamada 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>'

Em que $TOKEN está definido como seu token de acesso OAuth 2.0, conforme descrito em Como receber um token de acesso OAuth 2.0. Para informações sobre as opções de curl usadas neste exemplo, consulte Como usar curl. Para uma descrição das variáveis de ambiente usadas, consulte Como definir variáveis de ambiente para solicitações de API da Apigee.

TargetEndpoint com balanceamento de carga de destino

Os endpoints de destino são compatíveis com balanceamento de carga em vários servidores de destino nomeados usando três algoritmos de balanceamento de carga.

Para instruções detalhadas, consulte Balanceamento de carga entre servidores de back-end.

IntegrationEndpoint

Um IntegrationEndpoint é um endpoint de destino que executa especificamente integrações da Apigee. Se você configurou um IntegrationEndpoint, a Apigee envia o objeto request à plataforma de integração da Apigee para execução. Para executar a integração, além de configurar a IntegrationEndpoint, você também precisa adicionar a política SetIntegrationRequest no fluxo de proxy.

É possível configurar a integração para ser executada de maneira síncrona ou assíncrona. Basta definir o elemento <AsyncExecution> na integração IntegrationEndpoint. Para mais informações, consulte Execução síncrona versus assíncrona. Depois de executar a integração, a Apigee salva a resposta na mensagem de resposta.

Como configurar IntegrationEndpoint

Para configurar um endpoint de integração como o endpoint de destino, adicione o elemento IntegrationEndpoint à configuração do ProxyEndpoint. Veja a seguir uma amostra de configuração 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>

Na configuração ProxyEndpoint de amostra, a Apigee executa as seguintes tarefas:

1. No PreFlow, executa a política chamada my-set-integration-request-policy, que define o objeto da solicitação de integração e as variáveis de fluxo de integração.
2. Usa my-int-endpoint como o endpoint de destino, conforme especificado em RouteRule.
3. Lê o objeto de solicitação de integração criado pelo my-set-integration-request-policy.
4. Envia a solicitação para a plataforma de integração da Apigee usando o objeto da solicitação e as variáveis de fluxo definidas pela política SetIntegrationRequest.
5. Salva a resposta da integração na mensagem de resposta.

O arquivo XML que contém a declaração <IntegrationEndpoint> estará disponível no diretório APIGEE_BUNDLE_DIRECTORY/apiproxy/integration-endpoints/. Se você criar seu proxy de API usando a opção Develop > API Proxies > CREATE NEW > Integration target, a Apigee armazena a declaração no arquivo /apiproxy/integration-endpoints/default.xml. Se você criar o XML do endpoint de integração a partir da IU, poderá fornecer um nome personalizado para o arquivo XML.

O exemplo a seguir mostra a declaração do elemento <IntegrationEndpoint> no arquivo XML:

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

Elementos de configuração de IntegrationEndpoint

Execução síncrona versus assíncrona

Você pode configurar a integração para ser executada em modo síncrono ou assíncrono. Para entender a diferença entre os modos de execução síncrono e assíncrono, consulte <AsyncExecution>.

Use o elemento <AsyncExecution> em </IntegrationEndpoint> para especificar a execução síncrona ou assíncrona. Se <AsyncExecution> for definido como true, a integração será executada de maneira assíncrona. Se você a definir como false, a integração será executada de maneira síncrona.

O exemplo a seguir define a AsyncExecution como true:

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

Políticas

O diretório /policies em um proxy de API contém todas as políticas disponíveis para serem anexadas aos fluxos no proxy de API.

Elementos de configuração da política

Anexo da política

A imagem a seguir mostra a sequência de execução do fluxo da API:

Como mostrado acima:

As políticas são anexadas como etapas de processamento para Fluxos. O nome da política é usado para referenciar a política a ser aplicada como uma etapa de processamento. Este é o formato de um anexo de política:

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

As políticas são aplicadas na ordem em que são anexadas a um fluxo. Por exemplo:

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

Elementos de configuração do anexo de política

Fluxos

ProxyEndpoint e TargetEndpoint definem um pipeline para processamento de mensagens de solicitação e resposta. Um pipeline de processamento consiste em um fluxo de solicitação e um fluxo de resposta. Cada fluxo de solicitação e de resposta é subdividido em um PreFlow, um ou mais fluxos condicionais ou nomeados opcionais e um PostFlow.

• PreFlow: sempre executado. Executado antes de qualquer fluxo condicional.
• PostFlow: sempre é executado. Executado após qualquer fluxo condicional.

Além disso, é possível adicionar um PostClientFlow ao endpoint de proxy, que é executado depois que a resposta é retornada ao app cliente solicitante. Somente a política MessageLogging pode ser anexada a esse fluxo. O PostClientFlow reduz a latência do proxy de API e disponibiliza informações para a geração de registros que não são calculadas até que a resposta seja retornada ao cliente, como client.sent.start.timestamp e client.sent.end.timestamp O fluxo de trabalho é usado principalmente para medir o intervalo de tempo entre os carimbos de data/hora de início e término da mensagem de resposta.

Veja um exemplo de PostClientFlow com política de registro de mensagens anexada.

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

O pipeline de processamento do proxy de API executa fluxos na seguinte sequência:

Solicitar pipeline:

1. PreFlow da solicitação de proxy
2. Fluxos condicionais de solicitação de proxy (opcional)
3. PostFlow de solicitação de proxy
4. PreFlow da solicitação de destino
5. Fluxos condicionais de solicitação de destino (opcional)
6. PostFlow da solicitação de destino

Pipeline de resposta:

1. PreFlow de resposta de destino
2. Fluxos condicionais de resposta desejada (opcional)
3. PostFlow de resposta de destino
4. PreFlow de resposta do proxy
5. Fluxos condicionais de resposta de proxy (opcional)
6. PostFlow de resposta de proxy
7. Resposta de PostClientFlow (opcional)

Somente fluxos com anexos de política precisam ser configurados nas configurações de ProxyEndpoint ou TargetEndpoint. O PreFlow e o PostFlow só precisam ser especificados em uma configuração de ProxyEndpoint ou TargetEndpoint quando uma política precisa ser aplicada durante o processamento do PreFlow ou PostFlow.

Ao contrário dos fluxos condicionais, a ordem dos elementos de PreFlow e PostFlow não é importante. O proxy de API sempre será executado no ponto adequado do pipeline, independentemente de onde eles aparecem na configuração do endpoint.

Fluxos condicionais

Os endpoints de proxy e de destino são compatíveis com um número ilimitado de fluxos condicionais (também conhecidos como fluxos nomeados).

O proxy de API testa a condição especificada no fluxo condicional e, se a condição for atendida, as etapas de processamento no fluxo condicional são executadas pelo proxy de API. Se a condição não for atendida, as etapas de processamento no fluxo condicional serão ignoradas. Os fluxos condicionais são avaliados na ordem definida no proxy de API e no primeiro local em que a condição é atendida.

Ao definir fluxos condicionais, você ganha a capacidade de aplicar etapas de processamento em um proxy de API com base em:

• URI de solicitação
• Verbo HTTP (GET/PUT/POST/DELETE)
• Valor de um parâmetro de consulta, cabeçalho e parâmetro de formulário
• Muitos outros tipos de condições

Por exemplo, o fluxo condicional a seguir especifica que ele é executado somente quando o caminho do recurso da solicitação é /accesstoken. Qualquer solicitação de entrada com o caminho /accesstoken faz com que esse fluxo seja executado com todas as políticas anexadas ao fluxo. Se o caminho da solicitação não incluir o sufixo /accesstoken, o fluxo não será executado (embora outro fluxo condicional possa ser).

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

Elementos da configuração de fluxo

Processamento de etapas

A ordem sequencial dos fluxos condicionais é aplicada pela Apigee. Os fluxos condicionais são executados de cima para baixo. O primeiro fluxo condicional com condição avaliada como true é executado e apenas um fluxo condicional é executado.

Por exemplo, na configuração de fluxo a seguir, qualquer solicitação de entrada que não inclua o sufixo de caminho /first ou /second fará com que o ThirdFlow seja executado, aplicando a política chamada 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

"Recursos" (arquivos de recursos para uso em proxies de API) são scripts, código e transformações XSL que podem ser anexadas a fluxos usando políticas. Elas aparecem na seção Scripts do editor de proxy de API na IU da Apigee.

Consulte Como gerenciar recursos para saber os tipos de recurso compatíveis.

Os recursos podem ser armazenados em um proxy de API, um ambiente ou uma organização. Em cada caso, um recurso é referenciado pelo nome em uma política. A Apigee resolve o nome mudando do proxy de API para o ambiente, até o nível da organização.

Um recurso armazenado no nível da organização pode ser referenciado por políticas em qualquer ambiente. Um recurso armazenado no nível do ambiente pode ser referenciado por políticas nesse ambiente. Um recurso armazenado no nível do proxy de API só pode ser referenciado por políticas nesse proxy de API.