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

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Enquanto programador que trabalha com o Apigee, as 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 cria proxies de API.

Se estiver a aprender a criar proxies de API, recomendamos que comece pelo tópico Criar um proxy de API simples.

Edite a configuração do proxy de API através de um dos seguintes métodos:

• Use a IU do Apigee ou a API.
• Transfira o pacote de configuração do proxy de API, edite-o manualmente e carregue a nova configuração para o Apigee, conforme descrito em Transferir e carregar um pacote de configuração do proxy de API.

Estrutura do diretório de configuração do proxy de API

A estrutura do diretório de configuração do proxy de API é apresentada abaixo:

Uma configuração de proxy de API consiste nos seguintes conteúdos:

Configuração base

/apiproxy/weatherapi.xml

A configuração base de um proxy de API, que define o nome do proxy de API. O nome tem de ser exclusivo numa organização.

Configuração de exemplo:

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

Elementos de configuração base

ProxyEndpoint

A imagem seguinte mostra o fluxo de pedido/resposta:

/apiproxy/proxies/default.xml

A configuração ProxyEndpoint define a interface de entrada (orientada para o cliente) de um proxy de API. Quando configura um ponto final do proxy, está a configurar uma configuração de rede que define como as aplicações cliente (apps) devem invocar a API com proxy.

A seguinte configuração de ProxyEndpoint de exemplo 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 num ponto final de proxy básico são:

Elementos de configuração do ProxyEndpoint

Como configurar RouteRules

Um ponto final de destino com nome refere-se a um ficheiro de configuração em /apiproxy/targets para o qual a RouteRule encaminha um pedido após o processamento pelo ponto final de proxy.

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

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

Invocações de URLs diretos

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

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

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

Trajetos condicionais

As RouteRules podem ser encadeadas para suportar o encaminhamento dinâmico em tempo de execução. Os pedidos de entrada podem ser encaminhados para configurações de TargetEndpoint com nomes, diretamente para URLs ou para uma combinação dos dois, com base em cabeçalhos HTTP, conteúdo de mensagens, parâmetros de consulta ou informações contextuais, como a hora do dia, a localização, etc.

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

Por exemplo, a seguinte combinação RouteRule avalia primeiro o pedido de entrada para verificar o valor de um cabeçalho HTTP. Se o cabeçalho HTTP routeTo tiver o valor TargetEndpoint1, o pedido é encaminhado para o ponto final de destino denominado TargetEndpoint1. Caso contrário, o pedido de entrada é encaminhado 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>

Encaminhamentos nulos

Pode definir uma RouteRule nula para suportar cenários em que a mensagem de pedido não precisa de ser encaminhada para o ponto final de destino. Isto é útil quando o ponto final do proxy realiza todo o processamento necessário, por exemplo, usando JavaScript para chamar um serviço externo ou obter dados de uma pesquisa na loja de valores/chaves do Apigee.

Por exemplo, o seguinte define um Route nulo:

<RouteRule name="GoNowhere"/>

As rotas nulas condicionais podem ser úteis. No exemplo seguinte, é configurada uma rota nula para ser executada quando um cabeçalho HTTP request.header.X-DoNothing tiver um valor diferente de null.

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

Lembre-se de que as RouteRules podem ser encadeadas, pelo que uma Route nula condicional seria normalmente um componente de um conjunto de RouteRules concebidas para suportar o encaminhamento condicional.

Uma utilização prática de uma rota nula condicional seria no apoio à colocação em cache. Ao usar o valor da variável definida pela política de cache, pode configurar um proxy de API para executar a rota nula quando uma entrada é publicada a partir da cache.

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

TargetEndpoint

Um ponto final de destino é o equivalente de saída de um ponto final de proxy. Um ponto final de destino funciona como um cliente para um serviço ou uma API de back-end. Envia pedidos e recebe respostas.

Um proxy de API não tem de ter pontos finais de destino. Os pontos finais do proxy podem ser configurados para chamar URLs diretamente. Normalmente, um proxy de API sem pontos finais de destino contém um ponto final de proxy que chama diretamente um serviço de back-end ou que está configurado para chamar um serviço através de Java ou JavaScript.

Configuração do TargetEndpoint

/targets/default.xml

O ponto final de destino define a ligação de saída do Apigee para outro serviço ou recurso.

Segue-se um exemplo de configuração 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 configuração do TargetEndpoint

Um ponto final de destino pode chamar um destino de uma das seguintes formas:

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

Configure apenas um destes elementos num ponto final de destino.

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

Utilização do elemento <Authentication>

Referência de erro do elemento <Authentication>

Se estiver a usar o elemento <Authentication>, pode encontrar possíveis mensagens de erro e dicas de resolução de problemas para erros de implementação e de tempo de execução na secção Erros da documentação da política ServiceCallout.

Exemplos de elementos <Authentication>

O exemplo seguinte mostra como chamar um serviço implementado no Cloud Run como destino através do 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 seguinte 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 de autorização gerado a um cabeçalho denominado X-Serverless-Authorization que é enviado para o sistema de destino. O cabeçalho Authorization, se estiver presente, é deixado inalterado e também enviado no pedido.

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

O exemplo seguinte mostra como chamar um TargetService que aponta para o serviço Secret Manager da Google. Neste exemplo, o elemento GoogleAccessToken está configurado para gerar um token de autenticação Google para autenticar o pedido 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 seguinte mostra como definir automaticamente o público-alvo do GoogleIDToken. Quando useTargetUrl é true e a variável referenciada não é resolvida para uma variável válida, o URL do destino (excluindo os parâmetros de consulta) é usado como público-alvo. Suponhamos que o caminho do pedido é /foobar e o URL do servidor de destino é https://xyz.com. O público-alvo do GoogleIDToken é automaticamente definido 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 do TargetEndpoint TLS/SSL

Muitas vezes, os pontos finais de destino têm de gerir ligações HTTPS com uma infraestrutura de back-end heterogénea. Por este motivo, são suportadas várias definições de configuração de TLS/SSL.

TLS/SSL Elementos de configuração do 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 a aplicação de SSL ao nível do ambiente

Se SSLInfo.Enforce estiver definido como true ou false, o valor especificado substitui todas as opções de aplicação detalhadas especificadas nos blocos <SSLInfo> nas configurações TargetEndpoint ou TargetServer.

Se SSLInfo.Enforce não estiver definido, a aplicação da tecnologia SSL é determinada por quaisquer valores especificados através do elemento <Enforce> em blocos <SSLInfo> individuais. Para mais informações, consulte a configuração do TargetEndpoint TLS/SSL.

No exemplo seguinte, SSLInfo.Enforce está definido como true. Na saída resultante, pode ver que o SSL é aplicado no ambiente 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"'"             }]         }     }'   

Saída:

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

Exemplo de ponto final de destino com 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 o artigo Opções de configuração do TLS.

Usar variáveis de fluxo para definir dinamicamente os valores de TLS/SSL

Também pode definir dinamicamente os detalhes de TLS/SSL para suportar requisitos de tempo de execução flexíveis. Por exemplo, se o seu proxy se ligar a dois destinos potencialmente diferentes (um destino de teste e um destino de produção), pode fazer com que o seu proxy de API detete programaticamente o ambiente que está a chamar e defina dinamicamente referências ao keystore e truststore adequados. O artigo da comunidade do Apigee explica este cenário mais detalhadamente e fornece exemplos de proxy de API implementáveis.

No exemplo seguinte de como a etiqueta <SSLInfo> seria definida numa configuração de TargetEndpoint, os valores podem ser fornecidos no tempo de execução, por exemplo, por um Callout Java, uma política de JavaScript ou uma política AssignMessage. Use as variáveis de mensagens que contêm os valores que quer definir.

As variáveis só são permitidas nos seguintes 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 referências para definir dinamicamente os valores de TLS/SSL

Quando configurar um ponto final de destino que usa HTTPS, tem de considerar o caso em que o certificado TLS/SSL expira ou uma alteração à configuração do sistema requer que atualize o certificado.

Para mais informações, consulte o artigo Como processar certificados expirados.

No entanto, pode configurar opcionalmente o ponto final de destino para usar uma referência ao keystore ou truststore. A vantagem de usar uma referência é que pode atualizar a referência para apontar para um keystore ou um truststore diferente para atualizar o certificado TLS/SSL sem ter de reiniciar os processadores de mensagens.

Por exemplo, abaixo é apresentado um ponto final 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 da API POST para criar a referência com o nome 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>'

Onde $TOKEN está definido como a sua chave de acesso OAuth 2.0, conforme descrito em Obter uma chave de acesso OAuth 2.0. Para informações sobre as opções de curl usadas neste exemplo, consulte a secção Usar o curl. Para uma descrição das variáveis de ambiente que pode usar, consulte o artigo Definir variáveis de ambiente para pedidos de API Apigee.

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

Use a seguinte chamada da API GET para ver a referência:

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

Onde $TOKEN está definido como a sua chave de acesso OAuth 2.0, conforme descrito em Obter uma chave de acesso OAuth 2.0. Para informações sobre as opções de curl usadas neste exemplo, consulte a secção Usar o curl. Para uma descrição das variáveis de ambiente que pode usar, consulte o artigo Definir variáveis de ambiente para pedidos de API Apigee.

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

Onde $TOKEN está definido como a sua chave de acesso OAuth 2.0, conforme descrito em Obter uma chave de acesso OAuth 2.0. Para informações sobre as opções de curl usadas neste exemplo, consulte a secção Usar o curl. Para uma descrição das variáveis de ambiente que pode usar, consulte o artigo Definir variáveis de ambiente para pedidos de API Apigee.

Para alterar posteriormente a referência de modo a apontar para um keystore diferente, garantindo que o alias tem o mesmo nome, use a seguinte chamada 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>'

Onde $TOKEN está definido como a sua chave de acesso OAuth 2.0, conforme descrito em Obter uma chave de acesso OAuth 2.0. Para informações sobre as opções de curl usadas neste exemplo, consulte a secção Usar o curl. Para uma descrição das variáveis de ambiente que pode usar, consulte o artigo Definir variáveis de ambiente para pedidos de API Apigee.

TargetEndpoint com equilíbrio de carga de destino

Os pontos finais de destino suportam o balanceamento de carga em vários servidores de destino nomeados através de três algoritmos de balanceamento de carga.

Para obter instruções detalhadas, consulte o artigo Equilibrar a carga entre servidores de back-end.

IntegrationEndpoint

Um IntegrationEndpoint é um ponto final de destino que executa especificamente integrações do Apigee. Se tiver configurado um IntegrationEndpoint, o Apigee envia o objeto request para a plataforma de integração do Apigee para execução. Para executar a integração, além de configurar o IntegrationEndpoint, também tem de adicionar a política SetIntegrationRequest no fluxo do proxy.

Pode configurar a integração para ser executada de forma síncrona ou assíncrona definindo o elemento <AsyncExecution> na configuração IntegrationEndpoint. Para mais informações, consulte o artigo Execução síncrona vs. assíncrona. Após a execução da integração, o Apigee guarda a resposta na mensagem de resposta.

Configurar IntegrationEndpoint

Para configurar um ponto final de integração como ponto final de destino, adicione o elemento IntegrationEndpoint à configuração do ProxyEndpoint. Segue-se um exemplo de uma 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 de exemplo do ProxyEndpoint, o Apigee realiza as seguintes tarefas:

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

O ficheiro XML que contém a declaração <IntegrationEndpoint> vai estar disponível no diretório APIGEE_BUNDLE_DIRECTORY/apiproxy/integration-endpoints/. Se criar o proxy de API através da opção Develop > API Proxies > CREATE NEW > Integration target, o Apigee armazena a declaração no ficheiro /apiproxy/integration-endpoints/default.xml. Se criar o XML do ponto final de integração a partir da IU, pode fornecer um nome personalizado para o ficheiro XML.

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

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

Elementos de configuração do IntegrationEndpoint

Execução síncrona vs. assíncrona

Pode configurar a integração para ser executada no modo síncrono ou assíncrono. Para compreender a diferença entre os modos de execução síncronos e assíncronos, consulte <AsyncExecution>.

Use o elemento <AsyncExecution> no elemento </IntegrationEndpoint> para especificar a execução síncrona ou assíncrona. Se definir <AsyncExecution> como true, a integração é executada de forma assíncrona. Se a definir como false, a integração é executada de forma síncrona.

O exemplo seguinte define o valor de AsyncExecution como true:

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

Políticas

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

Elementos de configuração de políticas

Anexo de políticas

A imagem seguinte mostra a sequência de execução dos fluxos do proxy da API:

Conforme mostrado acima:

As políticas são anexadas como passos de processamento aos fluxos. O nome da política é usado para fazer referência à política a aplicar como um passo de processamento. O formato de um anexo de política é o seguinte:

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

As políticas são aplicadas pela 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 de anexos de políticas

Flows

ProxyEndpoint e TargetEndpoint definem um pipeline para o processamento de mensagens de pedidos e respostas. Um pipeline de processamento consiste num fluxo de pedidos e num fluxo de respostas. Cada fluxo de pedido e fluxo de resposta é subdividido num PreFlow, um ou mais fluxos condicionais ou denominados opcionais e um PostFlow.

• PreFlow: é sempre executado. É executado antes de quaisquer fluxos condicionais.
• PostFlow: é sempre executado. É executado após quaisquer fluxos condicionais.

Além disso, pode adicionar um PostClientFlow ao ponto final do proxy, que é executado depois de a resposta ser devolvida à app cliente que fez o pedido. Só é possível anexar a política MessageLogging a este fluxo. O PostClientFlow reduz a latência do proxy da API e disponibiliza informações para o registo que não são calculadas até a resposta ser devolvida ao cliente, como client.sent.start.timestamp e client.sent.end.timestamp.O fluxo é usado principalmente para medir o intervalo de tempo entre as datas/horas de início e fim da mensagem de resposta.

Segue-se um exemplo de um PostClientFlow com uma política de registo 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 os fluxos na seguinte sequência:

Pipeline de pedidos:

1. Proxy Request PreFlow
2. Fluxos condicionais de pedidos de proxy (opcional)
3. Proxy Request PostFlow
4. Target Request PreFlow
5. Fluxos condicionais de pedidos de segmentação (opcional)
6. Target Request PostFlow

Pipeline de respostas:

1. Target Response PreFlow
2. Fluxos condicionais de respostas alvo (opcional)
3. Target Response PostFlow
4. Proxy Response PreFlow
5. Fluxos condicionais de resposta do proxy (opcional)
6. Proxy Response PostFlow
7. Resposta PostClientFlow (opcional)

Apenas os fluxos com anexos de políticas têm de ser configurados nas configurações de ProxyEndpoint ou TargetEndpoint. O PreFlow e o PostFlow só precisam de ser especificados numa configuração de ProxyEndpoint ou TargetEndpoint quando uma política tem de ser aplicada durante o processamento de PreFlow ou PostFlow.

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

Fluxos condicionais

Os pontos finais de proxy e os pontos finais de destino suportam um número ilimitado de fluxos condicionais (também conhecidos como fluxos com nome).

Os testes de proxy de API para a condição especificada no fluxo condicional e, se a condição for cumprida, os passos de processamento no fluxo condicional são executados pelo proxy de API. Se a condição não for cumprida, os passos de processamento no fluxo condicional são ignorados. Os fluxos condicionais são avaliados pela ordem definida no proxy da API e o primeiro cuja condição seja cumprida é executado.

Ao definir fluxos condicionais, ganha a capacidade de aplicar passos de processamento num proxy de API com base no seguinte:

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

Por exemplo, o fluxo condicional seguinte especifica que é executado apenas quando o caminho do recurso de pedido é /accesstoken. Qualquer pedido de entrada com o caminho /accesstoken faz com que este fluxo seja executado, juntamente com quaisquer políticas anexadas ao fluxo. Se o caminho do pedido não incluir o sufixo /accesstoken, o fluxo não é 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 de configuração do fluxo

Processamento do passo

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

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

Os "recursos" (ficheiros de recursos para utilização em proxies de API) são scripts, código e transformações XSL que podem ser anexados a fluxos através de políticas. Estes aparecem na secção Scripts do editor de proxy da API na IU do Apigee.

Consulte o artigo Gerir recursos para ver os tipos de recursos compatíveis.

Os recursos podem ser armazenados num proxy de API, num ambiente ou numa organização. Em cada caso, um recurso é referenciado pelo nome numa política. O Apigee resolve o nome movendo-se do proxy de API para o ambiente e, em seguida, para o nível da organização.

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