Esta página foi traduzida pela API Cloud Translation.

Referência de propriedades do endpoint

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Este tópico descreve as propriedades de transporte que podem ser definidas nas configurações TargetEndpoint e ProxyEndpoint para controlar as mensagens e o comportamento de conexão. Para ver a cobertura completa das configurações TargetEndpoint e ProxyEndpoint, consulte a Referência de configuração do proxy de API.

Propriedades de transporte do TargetEndpoint

O elemento HTTPTargetConnection nas configurações TargetEndpoint define um conjunto de propriedades de transporte HTTP. Use essas propriedades para definir configurações no nível de transporte.

As propriedades são definidas nos elementos TargetEndpoint e HTTPTargetConnection, conforme mostrado abaixo:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <Properties>
      <Property name="supports.http10">true</Property>
      <Property name="request.retain.headers">User-Agent,Referer,Accept-Language</Property>
      <Property name="retain.queryparams">apikey</Property>
    </Properties>
    <CommonName>COMMON_NAME_HERE</CommonName>
  </HTTPTargetConnection>
</TargetEndpoint>

Propriedade de transporte do TargetEndpoint Especificação

Nome da propriedade	Valor padrão	Descrição
`keepalive.timeout.millis`	`60000`	Tempo limite de inatividade para a conexão de destino no pool de conexões. Se a conexão no pool ficar inativa além do limite especificado, ela será fechada.
`connect.timeout.millis`	`3000`	Tempo limite da conexão de destino. O Edge retornará um código de status HTTP `503` se uma conexão tempo limite. Em alguns casos, um código de status HTTP 504 pode ser retornado quando `LoadBalancer` é usado na definição de TargetServer e um tempo limite é atingido. Observação: em alguns casos, a Apigee tenta se conectar automaticamente até três vezes. Como resultado, o tempo total de nova tentativa pode exceder o configurado para `connect.timeout.millis`.
`io.timeout.millis`	`55000`	Se não houver dados a serem lidos pelo número de milissegundos especificado ou se o soquete não estiver pronto para gravar dados pelo número especificado de milissegundos, a transação será tratada como tempo limite. Se ocorrer tempo limite durante a gravação da solicitação HTTP, `408, Request Timeout` será retornado. Se ocorrer tempo limite durante a leitura da resposta HTTP, `504, Gateway Timeout` será retornado. Este valor precisa ser sempre menor do que o valor da propriedade proxy_read_timeout do host virtual. Esse valor deve ser menor que o tempo limite usado pelo Roteador para comunicação com o processador de mensagens. Consulte Como configurar o tempo limite do roteador para mais. Consulte Como configurar io.timeout.millis e api.timeout para o Edge para saber mais.
`supports.http10`	`true`	Se for `true` e o cliente enviar uma solicitação 1.0, o destino também receberá uma solicitação. Caso contrário, a solicitação 1.1 será enviada para o destino.
`supports.http11`	`true`	Se for `true` e o cliente enviar uma solicitação 1.1, o destino também receberá uma Caso contrário, a solicitação 1.0 será enviada ao destino.
`use.proxy`	`true`	Se for definido como `true`, e as configurações de proxy forem especificadas em `http.properties` (apenas implantações locais), as conexões de destino serão definidas para usar o proxy especificado.
`use.proxy.tunneling`	`true`	Se for definido como `true` e as configurações de proxy forem especificadas em `http.properties` (apenas implantações locais), as conexões de destino serão configuradas para usar o túnel especificado. Se o destino usar TLS/SSL, essa propriedade será ignorada e a mensagem será sempre enviada por meio de um túnel.
`enable.method.override`	`false`	Para o método HTTP especificado, define um cabeçalho `X-HTTP-Method-Override` na solicitação de saída para o serviço de destino. Por exemplo, `<Property name="GET.override.method">POST</Property>`
`*.override.method`	N/D	Para o método HTTP especificado, define um cabeçalho `X-HTTP-Method-Override` na solicitação de saída. Por exemplo, `<Property name="GET.override.method">POST</Property>`
`request.streaming.enabled`	`false`	Por padrão (`false`), os payloads de solicitações HTTP são lidos em um buffer, e as políticas que possa operar no payload como esperado. Nos casos em que os payloads são maiores do que o tamanho do buffer (10 MB), é possível definir esse para `true`. Quando `true`, os payloads de solicitações HTTP não são lidos em um buffer. eles são transmitidos no estado em que se encontram para o endpoint de destino. Nesse caso, todas as políticas que operam no payload no fluxo de solicitação TargetEndpoint são ignoradas. Consulte também Solicitações e respostas de streaming.
`response.streaming.enabled`	`false`	Por padrão (`false`), os payloads de resposta HTTP são lidos em um buffer, e as políticas que possa operar no payload como esperado. Nos casos em que os payloads são maiores do que o tamanho do buffer (10 MB), é possível definir esse para `true`. Quando `true`, os payloads de resposta HTTP não são lidos em um buffer. eles são transmitidos no estado em que se encontram para o fluxo de resposta do ProxyEndpoint. Nesse caso, todas as políticas que operam no payload no fluxo de resposta TargetEndpoint são ignoradas. Consulte também Solicitações de streaming e de resposta.
`success.codes`	N/A	Por padrão, a Apigee Edge trata o código HTTP `4XX` ou `5XX` como erros e o código HTTP. `1XX`, `2XX`, `3XX` como sucesso. Essa propriedade permite a definição explícita de códigos de sucesso, para exemplo, `2XX, 1XX, 505` trata quaisquer códigos de resposta HTTP `100`, `200` e `505` como o sucesso. A definição dessa propriedade substitui os valores padrão. Portanto, se você quiser adicionar o código HTTP `400` à lista de códigos bem-sucedidos padrão, defina esta propriedade como: <Property name="success.codes">1XX,2XX,3XX,400</Property> Se você quiser que apenas o código HTTP `400` seja tratado como um código de sucesso, defina a propriedade como: <Property name="success.codes">400</Property> Ao definir o código HTTP `400` como o único código de sucesso, os códigos `1XX`, `2XX` e `3XX` são tratados como falhas.
`compression.algorithm`	N/A	Por padrão, o Apigee Edge encaminha solicitações para o destino usando o mesmo tipo de compactação da solicitação do cliente. Se a solicitação for recebida do cliente usando, por exemplo, a compactação gzip, o Apigee Edge encaminhará a solicitação para o destino usando a compactação gzip. Se a resposta recebida do destino usar deflate, o Apigee Edge encaminhará a resposta ao cliente usando deflate. Os valores aceitos são: gzip: sempre enviar mensagens usando a compactação gzip. deflate: sempre enviar mensagens usando a compactação deflate. nenhum: sempre enviar mensagens sem compactação. Consulte também: A Apigee oferece suporte a compactação/descompactação com GZIP/descompacta a compactação?
`request.retain.headers. enabled`	`true`	Por padrão, o Apigee Edge sempre mantém todos os cabeçalhos HTTP nas mensagens de saída. Quando definido como `true`, todos os cabeçalhos HTTP presentes na solicitação de entrada são definidos na solicitação de saída.
`request.retain.headers`	N/D	Define cabeçalhos HTTP específicos da solicitação que devem ser definidos na solicitação de saída para o serviço de destino. Por exemplo, para passar pelo cabeçalho `User-Agent`, defina o valor de `request.retain.headers` como `User-Agent`. Vários cabeçalhos HTTP são especificados como uma lista separada por vírgulas. Por exemplo, `User-Agent,Referer,Accept-Language`. Esta propriedade substitui `request.retain.headers.enabled`. Se `request.retain.headers.enabled` for definido como `false`, todos os cabeçalhos especificados na propriedade `request.retain.headers` ainda serão definidos na mensagem de saída.
`response.retain.headers. enabled`	`true`	Por padrão, o Apigee Edge sempre mantém todos os cabeçalhos HTTP nas mensagens de saída. Quando definido como `true`, todos os cabeçalhos HTTP presentes na resposta de entrada do serviço de destino são definidos na resposta de saída antes de ir para o ProxyEndpoint.
`response.retain.headers`	N/D	Define cabeçalhos HTTP específicos da resposta que precisam ser definidos na resposta de saída antes de ir para o ProxyEndpoint. Por exemplo, para passar pelo cabeçalho `Expires`, defina o valor de `response.retain.headers` como `Expires` Vários cabeçalhos HTTP são especificados como uma lista separada por vírgulas, para exemplo: `Expires,Set-Cookie`. Esta propriedade substitui `response.retain.headers.enabled`. Se `response.retain.headers.enabled` está definido como `false`, todos os cabeçalhos especificados na propriedade `response.retain.headers` ainda são definidos mensagem enviada.
`retain.queryparams. enabled`	`true`	Por padrão, o Apigee Edge sempre mantém todos os parâmetros de consulta nas solicitações de saída. Quando definido como `true`, todos os parâmetros de consulta presentes na solicitação de entrada são definidos na solicitação de saída para o serviço de destino.
`retain.queryparams`	N/D	Define parâmetros de consulta específicos a serem definidos na solicitação de saída. Por exemplo, para incluir o parâmetro de consulta `apikey` da mensagem de solicitação, defina `retain.queryparams` como `apikey`. Vários parâmetros de consulta são especificados como uma lista separada por vírgulas, por exemplo, `apikey,environment`. Esta propriedade modifica `retain.queryparams.enabled`.

Propriedades de transporte do ProxyEndpoint

Os elementos ProxyEndpoint e HTTPTargetConnection definem um conjunto de propriedades de transporte HTTP. Essas propriedades podem ser usadas para definir configurações no nível de transporte.

As propriedades são definidas nos elementos ProxyEndpoint e HTTPProxyConnection da seguinte maneira:

<ProxyEndpoint name="default">
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <Properties>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
    <VirtualHost>default</VirtualHost>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

Para saber mais sobre hosts virtuais, consulte Sobre hosts virtuais.

Propriedade de transporte do ProxyEndpoint Especificação

Nome da propriedade	Valor padrão	Descrição
`X-Forwarded-For`	`false`	Quando definido como `true`, o endereço IP do host virtual é adicionado à solicitação de saída como o do cabeçalho HTTP `X-Forwarded-For`.
`request.streaming. enabled`	`false`	Por padrão (`false`), payloads de solicitações HTTP são lidos em um buffer, e as políticas que podem para operar no trabalho do payload como esperado. Nos casos em que os payloads são maiores que (10 MB), é possível definir esse valor para `true`. Quando `true`, os payloads de solicitações HTTP não são lidos em um buffer. eles são transmitidos no estado em que se encontram para o fluxo de solicitação do TargetEndpoint. Nesse caso, todas as políticas que operam no payload no fluxo de solicitação ProxyEndpoint são ignoradas. Consulte também Solicitações e respostas de streaming.
`response.streaming. enabled`	`false`	Por padrão (`false`), os payloads de resposta HTTP são lidos em um buffer, e as políticas que possa operar no payload como esperado. Nos casos em que os payloads são maiores do que o tamanho do buffer (10 MB), é possível definir esse para `true`. Quando `true`, os payloads de resposta HTTP não são lidos em um buffer. eles são transmitidos para o cliente no estado em que se encontram. Nesse caso, todas as políticas que operam no payload no fluxo de resposta ProxyEndpoint são ignoradas. Consulte também Solicitações e respostas de streaming.
`compression.algorithm`	N/D	Por padrão, o Apigee Edge respeita o tipo de compactação definido para qualquer mensagem recebida. Por exemplo, quando um cliente envia uma solicitação que usa a compactação gzip, o Apigee Edge encaminha a solicitação ao destino usando a compactação gzip. Configure os algoritmos de compactação para serem aplicados explicitamente definindo essa propriedade no TargetEndpoint ou no ProxyEndpoint. Os valores aceitos são: gzip: sempre enviar mensagens usando a compactação gzip. deflate: sempre enviar mensagens usando a compactação deflate. nenhum: sempre enviar mensagens sem compactação. Consulte também: A Apigee oferece suporte a compactação/descompactação com GZIP/descompacta a compactação?
`api.timeout`	N/A	Configurar o tempo limite para proxies de API individuais É possível configurar proxies de API, mesmo aqueles com streaming ativado, para expirar após um tempo especificado com um status `504 Gateway Timeout`. O caso de uso principal é para clientes que têm proxies de API que levam mais tempo para serem executados. Por exemplo, digamos que você precise de proxies específicos para expirar em 3 minutos. Veja a seguir como usar `api.timeout`. Primeiro, configure o balanceador de carga, o roteador e o processador de mensagens para que eles expirem após três minutos. Em seguida, configure os proxies relevantes para expirar em três minutos. Especifique o valor em milissegundos. Por exemplo: `<Property name="api.timeout">180000</Property>` No entanto, aumentar os tempos limite do sistema pode causar problemas de desempenho, porque todos os proxies sem uma configuração api.timeout usam os novos tempos limite maiores do balanceador de carga, roteador e processador de mensagens. Assim, configure outros proxies de API que não exigem tempos limite mais longos para usar tempos limite mais baixos. Por exemplo, o comando a seguir define um proxy de API que expira depois de um minuto: `<Property name="api.timeout">60000</Property>` Não é possível definir essa propriedade com uma variável. Os clientes que não puderem modificar os tempos limite do Edge também podem configurar um proxy de API tempo limite, desde que o tempo limite seja menor que o do processador de mensagens Edge padrão de 57 segundos. Consulte Como configurar io.timeout.millis e api.timeout para o Edge para saber mais.

Como definir io.timeout.millis e api.timeout para o Edge

No Edge, a operação de io.timeout.millis e api.timeout estão relacionados. Em todas as solicitações a um proxy de API:

O roteador envia seu valor de tempo limite para o processador de mensagens. O valor de tempo limite do roteador é o valor de proxy_read_timeout definido pelo host virtual que processa a solicitação ou o valor de tempo limite padrão de 57 segundos.
O processador de mensagens define api.timeout:
1. Se api.timeout não estiver definido no nível do proxy, defina-o como o tempo limite do roteador.
2. Se api.timeout estiver definido no nível do proxy, defina-o no processador de mensagens como o menor tempo limite do roteador ou como o valor de api.timeout.
O valor de api.timeout especifica a quantidade máxima de tempo que um proxy de API precisa executar da solicitação de API para a resposta.

Após a execução de cada política no proxy de API, ou antes que o processador de mensagens envie a solicitação para o endpoint de destino, o processador de mensagens calcula (api.timeout - tempo decorrido desde o início da solicitação). Se o valor for menor que zero, significa que a quantidade máxima de tempo para lidar com a solicitação expirou e o processador de mensagens retorna 504.
O valor de io.timeout.millis especifica o tempo máximo que o endpoint de destino tem para responder.

Antes de se conectar a um endpoint de destino, o processador de mensagens determina (api.timeout: tempo decorrido desde o início da solicitação) e io.timeout.millis. Em seguida, ele define io.timeout.millis como esse valor.
- Se ocorrer tempo limite durante a gravação da solicitação HTTP, 408, Request Timeout será retornado.
- Se ocorrer tempo limite durante a leitura da resposta HTTP, 504, Gateway Timeout será retornado.

Sobre o ScriptTarget para aplicativos Node.js

O elemento ScriptTarget é usado para integrar um aplicativo Node.js ao proxy. Para informações sobre como usar Node.js e ScriptTarget, consulte:

Sobre os endpoints do HostedTarget

Uma tag <HostedTarget/> vazia instrui o Edge a usar um Node.js como destino. aplicativo que é implantado no ambiente de destinos hospedados. Para mais detalhes, consulte Visão geral dos destinos hospedados.