Políticas de transformação de Gerenciamento de API

Artigo
06/22/2022
19 minutos para o fim da leitura

Este artigo fornece uma referência às políticas de Gerenciamento de API usadas para transformar solicitações ou respostas de API.

Para saber mais sobre políticas:

Visão geral das políticas
Definir ou editar políticas
Expressões de política
Referência de Política para uma lista completa das instruções de política e suas configurações

Políticas de transformação

Converter JSON para XML – converte o corpo da solicitação ou da resposta de JSON para XML.
Converter XML para JSON – converte o corpo da solicitação ou da resposta de XML para JSON.
Localizar e substituir cadeia de caracteres no corpo – localiza uma subcadeia de caracteres de solicitação ou de resposta e a substitui por outra subcadeia de caracteres.
Mascarar URLs no conteúdo – Reescreve (mascara) os links no corpo da resposta, para que eles apontem para o link equivalente por meio do gateway.
Definir o serviço de back-end - Altera o serviço de back-end para uma solicitação de entrada.
Definir corpo - Define o corpo da mensagem para solicitações de entrada e saída.
Definir cabeçalho HTTP - Atribui um valor a uma resposta e/ou cabeçalho de resposta existente ou adiciona uma nova resposta e/ou cabeçalho de resposta.
Definir parâmetro de cadeia de consulta - Adiciona, substitui o valor ou exclui parâmetros de cadeias de consulta de solicitação.
Reescrever URL – converte a URL de uma solicitação de sua forma pública para a forma esperada pelo serviço Web.
Transformar XML usando um XSLT – aplica uma transformação XSL para XML no corpo da solicitação ou resposta.

Converter JSON para XML

A política json-to-xml converte o corpo da solicitação ou da resposta de JSON para XML.

Dica

Saiba como definir e editar as políticas de Gerenciamento de API.

Declaração de política

<json-to-xml apply="always | content-type-json" consider-accept-header="true | false" parse-date="true | false"/>

Exemplo

<policies>
    <inbound>
        <base />
    </inbound>
    <outbound>
        <base />
        <json-to-xml apply="always" consider-accept-header="false" parse-date="false"/>
    </outbound>
</policies>

Elementos

Nome	Descrição	Obrigatório
json-to-xml	Elemento raiz.	Yes

Atributos

Nome	Descrição	Obrigatório	Padrão
aplicar	O atributo deve ser definido como um dos valores a seguir. – always – sempre aplicar conversão. – content-type-json – converter somente se o cabeçalho Content-Type da resposta indica a presença de JSON.	Sim	N/D
consider-accept-header	O atributo deve ser definido como um dos valores a seguir. – true – aplica conversão se XML é solicitado no cabeçalho Accept da solicitação. – false – sempre aplicar conversão.	No	true
parse-date	Quando definido como `false`, os valores de data são simplesmente copiados durante a transformação	Não	true

Uso

Essa política pode ser usada nas seções e nos escopos da política a seguir.

Seções de política: de entrada, de saída, em caso de erro
Escopos da política: todos os escopos

Converter XML em JSON

A política xml-to-json converte o corpo da solicitação ou da resposta de XML para JSON. Esta política pode ser usada para modernizar APIs baseadas em serviços Web de back-end somente XML.

Dica

Saiba como definir e editar as políticas de Gerenciamento de API.

Declaração de política

<xml-to-json kind="javascript-friendly | direct" apply="always | content-type-xml" consider-accept-header="true | false"/>

Exemplo

<policies>
    <inbound>
        <base />
    </inbound>
    <outbound>
        <base />
        <xml-to-json kind="direct" apply="always" consider-accept-header="false" />
    </outbound>
</policies>

Elementos

Nome	Descrição	Obrigatório
xml-to-json	Elemento raiz.	Yes

Atributos

Nome	Descrição	Obrigatório	Padrão
kind	O atributo deve ser definido como um dos valores a seguir. – javascript-friendly – o JSON convertido tem um formato amigável para desenvolvedores de JavaScript. – direct – o JSON convertido reflete a estrutura do documento XML original.	Sim	N/D
aplicar	O atributo deve ser definido como um dos valores a seguir. – always – converter sempre. – content-type-xml – converter somente se o cabeçalho Content-Type da resposta indica a presença de XML.	Sim	N/D
consider-accept-header	O atributo deve ser definido como um dos valores a seguir. – true – aplica conversão se JSON é solicitado no cabeçalho Accept da solicitação. – false – sempre aplicar conversão.	No	true

Uso

Essa política pode ser usada nas seções e nos escopos da política a seguir.

Seções de política: de entrada, de saída, em caso de erro
Escopos da política: todos os escopos

Localizar e substituir cadeia de caracteres no corpo

A política find-and-replace Encontra uma subcadeia de caracteres de uma solicitação ou resposta e a substitui por outra subcadeia de caracteres.

Dica

Saiba como definir e editar as políticas de Gerenciamento de API.

Declaração de política

<find-and-replace from="what to replace" to="replacement" />

Exemplo

<find-and-replace from="notebook" to="laptop" />

Elementos

Nome	Descrição	Obrigatório
find-and-replace	Elemento raiz.	Yes

Atributos

Nome	Descrição	Obrigatório	Padrão
de	A cadeia de caracteres a ser pesquisada.	Sim	N/D
como	A cadeia de caracteres substituta. Especifique uma cadeia de substituição de comprimento zero para remover a cadeia de caracteres de pesquisa.	Sim	N/D

Uso

Essa política pode ser usada nas seções e nos escopos da política a seguir.

Seções da política: entrada, saída, back-end, em caso de erro
Escopos da política: todos os escopos

Mascarar URLs no conteúdo

A política redirect-content-urls reescreve (mascara) os links no corpo da resposta para que eles apontem para o link equivalente por meio do gateway. Use na seção de saída a fim de reescrever links no corpo da resposta para que apontem para o gateway. Use na seção de entrada para obter um efeito oposto.

Observação

Essa política não altera nenhum valor de cabeçalho como cabeçalhos Location. Para alterar valores de cabeçalho, use a política set-header.

Dica

Saiba como definir e editar as políticas de Gerenciamento de API.

Declaração de política

<redirect-content-urls />

Exemplo

<redirect-content-urls />

Elementos

Nome	Descrição	Obrigatório
redirect-content-urls	Elemento raiz.	Yes

Uso

Essa política pode ser usada nas seções e nos escopos da política a seguir.

Seções de política: de entrada, de saída
Escopos da política: todos os escopos

Definir serviço de back-end

Use a política set-backend-service para redirecionar uma solicitação de entrada para um back-end diferente daquele especificado nas configurações de API para essa operação. Essa política altera a URL base do serviço de back-end da solicitação de entrada para aquele especificado na política.

Dica

Saiba como definir e editar as políticas de Gerenciamento de API.

Declaração de política

<set-backend-service base-url="base URL of the backend service" />

<set-backend-service backend-id="identifier of the backend entity specifying base URL of the backend service" />

Observação

As entidades de back-end podem ser gerenciadas por meio do portal do Azure, da API de gerenciamento e do PowerShell.

Exemplo

<policies>
    <inbound>
        <choose>
            <when condition="@(context.Request.Url.Query.GetValueOrDefault("version") == "2013-05")">
                <set-backend-service base-url="http://contoso.com/api/8.2/" />
            </when>
            <when condition="@(context.Request.Url.Query.GetValueOrDefault("version") == "2014-03")">
                <set-backend-service base-url="http://contoso.com/api/9.1/" />
            </when>
        </choose>
        <base />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>

Neste exemplo, a política de serviço de back-end do conjunto roteia solicitações com base no valor da versão passado na cadeia de consulta para um serviço de back-end diferente daquele especificado na API.

Inicialmente, a URL base do serviço de back-end é derivada das configurações de API. Assim, a URL da solicitação https://contoso.azure-api.net/api/partners/15?version=2013-05&subscription-key=abcdef se torna http://contoso.com/api/10.4/partners/15?version=2013-05&subscription-key=abcdef em que http://contoso.com/api/10.4/ é a URL do serviço de back-end especificada nas configurações de API.

Quando a instrução de política choose> é aplicada, a URL base do serviço de back-end pode se alterar novamente para http://contoso.com/api/8.2 ou http://contoso.com/api/9.1, dependendo do valor do parâmetro de consulta de solicitação de versão. Por exemplo, se o valor for "2013-15", a URL da solicitação final se tornará http://contoso.com/api/8.2/partners/15?version=2013-05&subscription-key=abcdef.

Se ainda mais transformação da solicitação for desejada, outras políticas de transformação poderão ser usadas. Por exemplo, para remover o parâmetro de consulta de versão agora que a solicitação está sendo roteada para um back-end específico da versão, a política Definir parâmetro de cadeia de caracteres de consulta pode ser usada para remover o atributo de versão agora redundante.

Exemplo

<policies>
    <inbound>
        <set-backend-service backend-id="my-sf-service" sf-partition-key="@(context.Request.Url.Query.GetValueOrDefault("userId","")" sf-replica-type="primary" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>

Neste exemplo, a política encaminha a solicitação para um back-end de Service Fabric usando a cadeia de caracteres de consulta userId como a chave de partição e usando a réplica primária da partição.

Elementos

Nome	Descrição	Obrigatório
set-backend-service	Elemento raiz.	Yes

Atributos

Nome	Descrição	Obrigatório	Padrão
base-url	Nova URL base do serviço de back-end.	Um `base-url` ou `backend-id` deve estar presente.	N/D
backend-id	Identificador do back-end para o qual encaminhar. (As entidades de back-end são gerenciadas por meio do portal do Azure, da API e do PowerShell.)	Um `base-url` ou `backend-id` deve estar presente.	N/D
sf-partition-key	Aplicável somente quando o back-end é um serviço do Service Fabric e é especificado usando 'backend-id'. Usado para resolver uma partição específica do serviço de resolução de nome.	Não	N/D
sf-replica-type	Aplicável somente quando o back-end é um serviço do Service Fabric e é especificado usando 'backend-id'. Controla se a solicitação deve ir para a réplica primária ou secundária de uma partição.	Não	N/D
sf-resolve-condition	Aplicável somente quando o back-end é um serviço do Service Fabric. Condição que identifica se a chamada para o back-end do Service Fabric deve ser repetida com a nova resolução.	Não	N/D
sf-service-instance-name	Aplicável somente quando o back-end é um serviço do Service Fabric. Permite alterar as instâncias de serviço em runtime.	Não	N/D
sf-listener-name	Aplicável somente quando o back-end é um serviço do Service Fabric e é especificado usando "backend-id". O Reliable Services do Service Fabric permite que você crie vários ouvintes em um serviço. Este atributo é usado para selecionar um ouvinte específico quando um Reliable Service de back-end tiver mais de um ouvinte. Se esse atributo não for especificado, o Gerenciamento de API tentará usar um ouvinte sem nome. Um ouvinte sem nome é comum para o Reliable Services, que têm apenas um ouvinte.	Não	N/D

Uso

Essa política pode ser usada nas seções e nos escopos da política a seguir.

Seções de política: de entrada, back-end
Escopos da política: todos os escopos

Definir corpo

Use a política set-body para definir o corpo da mensagem para solicitações de entrada e saída. Para acessar o corpo da mensagem, você pode usar a propriedade context.Request.Body ou a context.Response.Body, dependendo da seção em que a política está: de entrada ou de saída.

Importante

Observe que, por padrão, quando você acessa o corpo da mensagem usando context.Request.Body ou context.Response.Body, o corpo da mensagem original é perdido e deve ser definido por meio do retorno do corpo de volta na expressão. Para preservar o conteúdo do corpo, defina o parâmetro preserveContent para true ao acessar a mensagem. Se preserveContent é definido para true e um corpo diferente é retornado pela expressão, o corpo retornado é usado.

Observe as seguintes considerações ao usar a política set-body.

Se você estiver usando a política set-body para retornar um corpo novo ou atualizado, você não precisará definir preserveContent para true porque você estará fornecendo explicitamente o novo conteúdo do corpo.
- Preservar o conteúdo de uma resposta no pipeline de entrada não faz sentido, porque ainda não há nenhuma resposta.
- Preservar o conteúdo de uma solicitação no pipeline de saída não faz sentido porque nesse momento a solicitação já foi enviada para o back-end.
- Se essa política é usada quando não há nenhum corpo da mensagem, por exemplo em um GET de entrada, uma exceção é lançada.

Para obter mais informações, consulte as seções context.Request.Body, context.Response.Body e IMessage na tabela context.Request.Body.

Dica

Saiba como definir e editar as políticas de Gerenciamento de API.

Declaração de política

<set-body>new body value as text</set-body>

Exemplos

Exemplo de texto literal

<set-body>Hello world!</set-body>

Exemplo acessando o corpo como uma cadeia de caracteres

Estamos preservando o corpo da solicitação original, de modo que possamos acessá-lo mais tarde no pipeline.

<set-body>
@{ 
    string inBody = context.Request.Body.As<string>(preserveContent: true); 
    if (inBody[0] =='c') { 
        inBody[0] = 'm'; 
    } 
    return inBody; 
}
</set-body>

Exemplo acessando o corpo como um JObject

Como não estamos preservando o corpo da solicitação original, acessá-lo mais tarde no pipeline resultará em uma exceção.

<set-body> 
@{ 
    JObject inBody = context.Request.Body.As<JObject>(); 
    if (inBody.attribute == <tag>) { 
        inBody[0] = 'm'; 
    } 
    return inBody.ToString(); 
} 
</set-body>

Resposta de filtro com base no produto

Este exemplo mostra como executar a filtragem de conteúdo removendo elementos de dados da resposta recebida de um serviço de back-end ao usar o produto Starter. A resposta de back-end de exemplo inclui propriedades de nível de raiz semelhantes à API de chamada OpenWeather One.

<!-- Copy this snippet into the outbound section to remove a number of data elements from the response received from the backend service based on the name of the product -->
<choose>
  <when condition="@(context.Response.StatusCode == 200 && context.Product.Name.Equals("Starter"))">
    <set-body>@{
        var response = context.Response.Body.As<JObject>();
        foreach (var key in new [] {"current", "minutely", "hourly", "daily", "alerts"}) {
          response.Property (key).Remove ();
        }
        return response.ToString();
      }
    </set-body>
  </when>
</choose>

Usando modelos Líquidos com o corpo definido

A política set-body pode ser configurada para usar a linguagem de modelagem set-body para transformar o corpo de uma solicitação ou resposta. Isso poderá ser eficaz se você precisar remodelar por completo o formato da mensagem.

Importante

A implementação de Líquido usado na política set-body é configurada no “modo C#”. Isso é particularmente importante ao executar ações como filtragem. Por exemplo, o uso de um filtro de data exige o uso de maiúsculas Pascal e da formatação das datas do C#, por exemplo:

Importante

Para associar corretamente a um corpo XML usando o modelo Líquido, use uma política set-header para definir Content-Type como application/xml, text/xml (ou qualquer tipo que termina com +xml); para um corpo JSON, ele deve ser application/json, text/json (ou qualquer tipo que termina com +json).

Filtros do Liquid com suporte

Os filtros do Liquid a seguir têm suporte na política set-body. Para obter exemplos de filtro, confira a Documentação do Liquid.

Observação

A política requer o uso de maiúsculas e minúsculas Pascal para os nomes de filtro do Liquid (por exemplo, "AtLeast" em vez de "at_least").

Abs
Acrescentar
AtLeast
AtMost
Capitalize
Compacto
Moeda
Data
Padrão
DividedBy
Downcase
Escape
Primeiro
H
Join
Último
Lstrip
Mapeamento
Minus
Módulo
NewlineToBr
Plus
Prepend
Remover
RemoveFirst
Substitua
ReplaceFirst
Round
Rstrip
Tamanho
Fatia
Classificar
Divisão
Strip
StripHtml
StripNewlines
Horas
Truncate
TruncateWords
Uniq
Upcase
UrlDecode
UrlEncode

Converter JSON em SOAP usando um modelo Líquido

<set-body template="liquid">
    <soap:Envelope xmlns="http://tempuri.org/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <soap:Body>
            <GetOpenOrders>
                <cust>{{body.getOpenOrders.cust}}</cust>
            </GetOpenOrders>
        </soap:Body>
    </soap:Envelope>
</set-body>

Transformar JSON usando um modelo Líquido

{
"order": {
    "id": "{{body.customer.purchase.identifier}}",
    "summary": "{{body.customer.purchase.orderShortDesc}}"
    }
}

Elementos

Nome	Descrição	Obrigatório
set-body	Elemento raiz. Contém o texto do corpo ou expressão que retorna um corpo.	Sim

Propriedades

Nome	Descrição	Obrigatório	Padrão
template	Usado para alterar o modo de modelagem no qual a política de corpo definida será executada. Atualmente, o único valor aceito é: - liquid – a política de corpo definida usará o mecanismo de modelagem líquida	Não

Para acessar informações sobre a solicitação e a resposta, o modelo Líquido pode ser associado a um objeto de contexto com as seguintes propriedades:

context.
    Request.
        Url
        Method
        OriginalMethod
        OriginalUrl
        IpAddress
        MatchedParameters
        HasBody
        ClientCertificates
        Headers

    Response.
        StatusCode
        Method
        Headers
Url.
    Scheme
    Host
    Port
    Path
    Query
    QueryString
    ToUri
    ToString

OriginalUrl.
    Scheme
    Host
    Port
    Path
    Query
    QueryString
    ToUri
    ToString

Uso

Essa política pode ser usada nas seções e nos escopos da política a seguir.

Seções de política: entrada, saída, back-end
Escopos da política: todos os escopos

Definir cabeçalho HTTP

A política set-header atribui um valor a uma resposta e/ou cabeçalho de resposta existente ou adiciona uma nova resposta e/ou cabeçalho de resposta.

Use a política para inserir uma lista de cabeçalhos HTTP em uma mensagem HTTP. Quando colocada em um pipeline de entrada, esta política define os cabeçalhos HTTP para a solicitação que está sendo passada para o serviço alvo. Quando colocada em um pipeline de saída, esta política define os cabeçalhos HTTP para a resposta que está sendo passada para o cliente do gateway.

Dica

Para ajudá-lo a configurar essa política, o portal fornece um editor guiado baseado em formulário. Saiba mais sobre como definir e editar as políticas de Gerenciamento de API.

Declaração de política

<set-header name="header name" exists-action="override | skip | append | delete">
    <value>value</value> <!--for multiple headers with the same name add additional value elements-->
</set-header>

Exemplos

Exemplo – adicionar cabeçalho, substituir existente

<set-header name="some header name" exists-action="override">
    <value>20</value>
</set-header>

Exemplo – remover cabeçalho

 <set-header name="some header name" exists-action="delete" />

Encaminhar informações de contexto para o serviço de back-end

Este exemplo mostra como aplicar a política no nível da API para fornecer informações de contexto para o serviço de back-end.

<!-- Copy this snippet into the inbound element to forward some context information, user id and the region the gateway is hosted in, to the backend service for logging or evaluation -->
<set-header name="x-request-context-data" exists-action="override">
  <value>@(context.User.Id)</value>
  <value>@(context.Deployment.Region)</value>
</set-header>

Para obter mais informações, veja Expressões de política e Variável de contexto.

Observação

Vários valores de um cabeçalho são concatenados em uma cadeia de caracteres CSV; por exemplo: headerName: value1,value2,value3

As exceções incluem cabeçalhos padronizados, cujos valores:

podem conter vírgulas (User-Agent, WWW-Authenticate, Proxy-Authenticate),
podem conter a data (Cookie, Set-Cookie, Warning),
contêm a data (Date, Expires, If-Modified-Since, If-Unmodified-Since, Last-Modified, Retry-After).

No caso de exceções, vários valores de cabeçalho não serão concatenados em uma cadeia de caracteres e serão passados como cabeçalhos separados; por exemplo: User-Agent: value1User-Agent: value2User-Agent: value3

Elementos

Nome	Descrição	Obrigatório
set-header	Elemento raiz.	Yes
value	Especifica o valor do cabeçalho a ser definido. Para adicionar vários cabeçalhos com o mesmo nome, adicione elementos `value` adicionais.	Não

Propriedades

Nome	Descrição	Obrigatório	Padrão
exists-action	Especifica a ação a ser adotada quando o cabeçalho já foi especificado. Este atributo deve ter um dos valores a seguir. - override - substitui o valor do cabeçalho existente. - skip - não substitui o valor do cabeçalho existente. - append - acrescenta o valor ao valor do cabeçalho existente. - delete - remove o cabeçalho da solicitação. Quando definido como `override`, listar diversas entradas com o mesmo nome faz com que o cabeçalho seja definido de acordo com todas as entradas (que serão listadas várias vezes); somente valores listados serão definidos no resultado.	Não	override
name	Especifica o nome do cabeçalho a ser definido.	Sim	N/D

Uso

Essa política pode ser usada nas seções e nos escopos da política a seguir.

Seções da política: entrada, saída, back-end, em caso de erro
Escopos da política: todos os escopos

Definir parâmetro de cadeia de caracteres de consulta

A política set-query-parameter adiciona, substitui o valor ou exclui parâmetros de cadeias de consulta de solicitação. Pode ser usada para transmitir parâmetros de consulta esperados pelo serviço de back-end que são opcionais ou nunca estão presentes na solicitação.

Dica

Para ajudá-lo a configurar essa política, o portal fornece um editor guiado baseado em formulário. Saiba mais sobre como definir e editar as políticas de Gerenciamento de API.

Declaração de política

<set-query-parameter name="param name" exists-action="override | skip | append | delete">
    <value>value</value> <!--for multiple parameters with the same name add additional value elements-->
</set-query-parameter>

Exemplo


<set-query-parameter name="api-key" exists-action="skip">
  <value>12345678901</value>
</set-query-parameter>

Encaminhar informações de contexto para o serviço de back-end

Este exemplo mostra como aplicar a política no nível da API para fornecer informações de contexto para o serviço de back-end.

<!-- Copy this snippet into the inbound element to forward a piece of context, product name in this example, to the backend service for logging or evaluation -->
<set-query-parameter name="x-product-name" exists-action="override">
  <value>@(context.Product.Name)</value>
</set-query-parameter>

Para obter mais informações, veja Expressões de política e Variável de contexto.

Elementos

Nome	Descrição	Obrigatório
set-query-parameter	Elemento raiz.	Yes
value	Especifica o valor do parâmetro de consulta a ser definido. Para adicionar vários parâmetros de consulta com o mesmo nome, adicione elementos `value` adicionais.	Sim

Propriedades

Nome	Descrição	Obrigatório	Padrão
exists-action	Especifica a ação a ser adotada quando o parâmetro de consulta já foi especificado. Este atributo deve ter um dos valores a seguir. – override – substitui o valor do parâmetro existente. – skip – não substitui o valor do parâmetro de consulta existente. – append – acrescenta o valor ao valor do parâmetro de consulta existente. – delete – remove o parâmetro de consulta da solicitação. Quando definido como `override`, listar diversas entradas com o mesmo nome faz com que o parâmetro de consulta seja definido de acordo com todas as entradas (que serão listadas várias vezes); somente valores listados serão definidos no resultado.	Não	override
name	Especifica o nome do parâmetro de consulta a ser definido.	Sim	N/D

Uso

Essa política pode ser usada nas seções e nos escopos da política a seguir.

Seções de política: de entrada, back-end
Escopos da política: todos os escopos

Regravar URL

A política rewrite-uri converte a URL de uma solicitação de sua forma pública para a forma esperada pelo serviço Web, conforme mostrado no exemplo a seguir.

URL pública – http://api.example.com/storenumber/ordernumber
URL de Solicitação – http://api.example.com/v2/US/hardware/storenumber&ordernumber?City&State

Essa política pode ser usada quando uma URL simplificada para humanos e/ou navegadores precisar ser transformado na URL esperada pelo serviço Web. Essa política só precisa ser aplicada ao expor um formato de URL alternativo como URLs limpas, URLs RESTful, URLs simplificadas para usuários ou para URLs amigáveis ao SEO que são URLs puramente estruturais que não contêm uma cadeia de consulta, contendo somente o caminho do recurso (após o esquema e autoridade). Frequentemente, isso é feito para fins estéticos, de usabilidade ou de otimização do mecanismo de pesquisa (SEO).

Observação

Você pode adicionar somente parâmetros de cadeia de consulta usando a política. Você não pode adicionar parâmetros de caminho do modelo extra à URL reescrita.

Dica

Saiba como definir e editar as políticas de Gerenciamento de API.

Declaração de política

<rewrite-uri template="uri template" copy-unmatched-params="true | false" />

Exemplo

<policies>
    <inbound>
        <base />
        <rewrite-uri template="/v2/US/hardware/{storenumber}&{ordernumber}?City=city&State=state" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>

<!-- Assuming incoming request is /get?a=b&c=d and operation template is set to /get?a={b} -->
<policies>
    <inbound>
        <base />
        <rewrite-uri template="/put" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>
<!-- Resulting URL will be /put?c=d -->

<!-- Assuming incoming request is /get?a=b&c=d and operation template is set to /get?a={b} -->
<policies>
    <inbound>
        <base />
        <rewrite-uri template="/put" copy-unmatched-params="false" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>
<!-- Resulting URL will be /put -->

Elementos

Nome	Descrição	Obrigatório
rewrite-uri	Elemento raiz.	Yes

Atributos

Atributo	Descrição	Obrigatório	Padrão
template	A URL real do serviço Web com quaisquer parâmetros de cadeia de consulta. Ao usar expressões, o valor inteiro deve ser uma expressão.	Sim	N/D
copy-unmatched-params	Especifica se os parâmetros de consulta na solicitação de entrada não presentes no modelo de URL original são adicionados à URL definida pelo modelo reescrito	Não	true

Uso

Essa política pode ser usada nas seções e nos escopos da política a seguir.

Seções de política: de entrada
Escopos da política: todos os escopos

Transformar XML usando um XSLT

A política Transform XML using an XSLT aplica uma transformação XSL para XML no corpo da solicitação ou da resposta.

Dica

Saiba como definir e editar as políticas de Gerenciamento de API.

Declaração de política

<xsl-transform>
    <parameter name="User-Agent">@(context.Request.Headers.GetValueOrDefault("User-Agent","non-specified"))</parameter>
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
        <xsl:output method="xml" indent="yes" />
        <xsl:param name="User-Agent" />
        <xsl:template match="* | @* | node()">
            <xsl:copy>
                <xsl:if test="self::* and not(parent::*)">
                    <xsl:attribute name="User-Agent">
                        <xsl:value-of select="$User-Agent" />
                    </xsl:attribute>
                </xsl:if>
                <xsl:apply-templates select="* | @* | node()" />
            </xsl:copy>
        </xsl:template>
    </xsl:stylesheet>
  </xsl-transform>

Exemplo

<policies>
  <inbound>
      <base />
  </inbound>
  <outbound>
      <base />
      <xsl-transform>
          <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
            <xsl:output omit-xml-declaration="yes" method="xml" indent="yes" />
            <!-- Copy all nodes directly-->
            <xsl:template match="node()| @*|*">
                <xsl:copy>
                    <xsl:apply-templates select="@* | node()|*" />
                </xsl:copy>
            </xsl:template>
          </xsl:stylesheet>
    </xsl-transform>
  </outbound>
</policies>

Elementos

Nome	Descrição	Obrigatório
xsl-transform	Elemento raiz.	Sim
parâmetro	Usado para definir as variáveis usadas na transformação	Não
xsl:stylesheet	Elemento de folha de estilos de raiz. Todos os elementos e atributos definidos dentro dele seguem o padrão especificação XSLT	Sim

Uso

Essa política pode ser usada nas seções e nos escopos da política a seguir.

Seções de política: de entrada, de saída
Escopos da política: todos os escopos

Próximas etapas

Para obter mais informações sobre como trabalhar com políticas, consulte:

Tutorial: Transformar e proteger sua API
Referência de Política para uma lista completa das instruções de política e suas configurações
Expressões de política
Definir ou editar políticas
Reutilizar configurações de política
Exemplos de política