Políticas de transformação de Gerenciamento de API
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.
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.
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.
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.
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.
Declaração de política
<set-backend-service base-url="base URL of the backend service" />
ou
<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á definirpreserveContent
paratrue
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
.
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:
{{body.foo.startDateTime| Date:"yyyyMMddTHH:mm:ssZ"}}
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: value1
User-Agent: value2
User-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.
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.
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