Transformatiebeleid API Management

In dit onderwerp vindt u een naslag voor de volgende API Management beleidsregels. Zie Beleidsregels in API Management voor meer informatie over het toevoegen en configureren van API Management.

Transformatiebeleid

JSON converteren naar XML

Het json-to-xml beleid converteert een aanvraag- of antwoord-body van JSON naar XML.

Beleidsverklaring

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

Voorbeeld

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

Elementen

Naam Beschrijving Vereist
json-to-xml Hoofdelement. Ja

Kenmerken

Naam Beschrijving Vereist Standaard
toepassen Het kenmerk moet worden ingesteld op een van de volgende waarden.

- altijd - altijd conversie toepassen.
- content-type-json: converteert alleen als de antwoordheader Content-Type de aanwezigheid van JSON aangeeft.
Ja N.v.t.
consider-accept-header Het kenmerk moet worden ingesteld op een van de volgende waarden.

- true: pas conversie toe als XML wordt aangevraagd in de accept-header van de aanvraag.
- onwaar - altijd conversie toepassen.
Nee true
parse-date Wanneer de waarde is false ingesteld op datum, worden deze gewoon gekopieerd tijdens de transformatie Nee true

Gebruik

Dit beleid kan worden gebruikt in de volgende beleidssecties en -scopes.

  • Beleidssecties: inkomende, uitgaande, on-error

  • Beleidsbereiken: alle scopes

XML converteren naar JSON

Het xml-to-json beleid converteert een aanvraag- of antwoord-body van XML naar JSON. Dit beleid kan worden gebruikt om API's te moderniseren op basis van alleen XML-back-end-webservices.

Beleidsverklaring

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

Voorbeeld

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

Elementen

Naam Beschrijving Vereist
xml-to-json Hoofdelement. Ja

Kenmerken

Naam Beschrijving Vereist Standaard
Soort Het kenmerk moet worden ingesteld op een van de volgende waarden.

-javascript-gebruiksvriendelijk: de geconverteerde JSON heeft een formulier dat gebruiksvriendelijk is voor JavaScript-ontwikkelaars.
-direct: de geconverteerde JSON weerspiegelt de structuur van het oorspronkelijke XML-document.
Ja N.v.t.
toepassen Het kenmerk moet worden ingesteld op een van de volgende waarden.

- altijd - altijd converteren.
- content-type-xml: converteert alleen als de antwoordheader Content-Type de aanwezigheid van XML aangeeft.
Ja N.v.t.
consider-accept-header Het kenmerk moet worden ingesteld op een van de volgende waarden.

-true: pas conversie toe als JSON wordt aangevraagd in de accept-header van de aanvraag.
- onwaar - altijd conversie toepassen.
Nee true

Gebruik

Dit beleid kan worden gebruikt in de volgende beleidssecties en -scopes.

  • Beleidssecties: inkomende, uitgaande, on-error

  • Beleidsbereiken: alle scopes

Tekenreeks in de body zoeken en vervangen

Het find-and-replace beleid zoekt een aanvraag- of antwoordsubtekenreeks en vervangt deze door een andere subtekenreeks.

Beleidsverklaring

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

Voorbeeld

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

Elementen

Naam Beschrijving Vereist
find-and-replace Hoofdelement. Ja

Kenmerken

Naam Beschrijving Vereist Standaard
from De tekenreeks waarnaar moet worden gezocht. Ja N.v.t.
tot De vervangende tekenreeks. Geef een vervangingsreeks met nullengte op om de zoekreeks te verwijderen. Ja N.v.t.

Gebruik

Dit beleid kan worden gebruikt in de volgende beleidssecties en -scopes.

  • Beleidssecties: inkomende, uitgaande, back-end, on-error

  • Beleidsbereiken: alle scopes

URL's in inhoud maskeren

Het redirect-content-urls beleid schrijft koppelingen (maskers) opnieuw in de antwoord-body zodat ze via de gateway naar de equivalente koppeling verwijzen. Gebruik in de sectie uitgaand om antwoord bodykoppelingen opnieuw te schrijven om ze naar de gateway te laten wijzen. Gebruik in de sectie voor binnenkomende gegevens voor een tegenovergestelde werking.

Notitie

Dit beleid wijzigt geen headerwaarden, zoals Location headers. Als u headerwaarden wilt wijzigen, gebruikt u het set-header-beleid.

Beleidsverklaring

<redirect-content-urls />

Voorbeeld

<redirect-content-urls />

Elementen

Naam Beschrijving Vereist
redirect-content-urls Hoofdelement. Ja

Gebruik

Dit beleid kan worden gebruikt in de volgende beleidssecties en -scopes.

  • Beleidssecties: inkomende, uitgaande

  • Beleidsbereiken: alle scopes

Back-endservice instellen

Gebruik het beleid om een binnenkomende aanvraag om te leiden naar een andere back-end dan de aanvraag die is opgegeven in de set-backend-service API-instellingen voor die bewerking. Met dit beleid wordt de basis-URL van de back-endservice van de binnenkomende aanvraag gewijzigd in de url die is opgegeven in het beleid.

Beleidsverklaring

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

of

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

Notitie

Back-end-entiteiten kunnen worden beheerd via Azure Portal, beheer-APIen PowerShell.

Voorbeeld

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

In dit voorbeeld routeert het beleid voor de back-endservice aanvragen op basis van de versiewaarde die in de queryreeks wordt doorgegeven aan een andere back-endservice dan de service die is opgegeven in de API.

De basis-URL van de back-endservice wordt in eerste instantie afgeleid van de API-instellingen. De aanvraag-URL https://contoso.azure-api.net/api/partners/15?version=2013-05&subscription-key=abcdef wordt dus de locatie waar de URL van de http://contoso.com/api/10.4/partners/15?version=2013-05&subscription-key=abcdef http://contoso.com/api/10.4/ back-service is die is opgegeven in de API-instellingen.

Wanneer de <> beleidsverklaring wordt toegepast, kan de basis-URL van de back-service opnieuw worden gewijzigd in of , afhankelijk van de waarde van de queryparameter voor de http://contoso.com/api/8.2 http://contoso.com/api/9.1 versieaanvraag. Als de waarde bijvoorbeeld de uiteindelijke "2013-15" aanvraag-URL is, wordt http://contoso.com/api/8.2/partners/15?version=2013-05&subscription-key=abcdef .

Als verdere transformatie van de aanvraag gewenst is, kunnen andere transformatiebeleidsregels worden gebruikt. Als u bijvoorbeeld de versiequeryparameter wilt verwijderen nu de aanvraag wordt doorgeleid naar een versiespecifieke back-end, kan het beleid Queryreeksparameter instellen worden gebruikt om het nu redundante versiekenmerk te verwijderen.

Voorbeeld

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

In dit voorbeeld wordt de aanvraag door het beleid gerouteerd naar een service fabric-back-end, met behulp van de queryreeks userId als partitiesleutel en met behulp van de primaire replica van de partitie.

Elementen

Naam Beschrijving Vereist
set-backend-service Hoofdelement. Ja

Kenmerken

Naam Beschrijving Vereist Standaard
base-url Nieuwe basis-URL voor back-en-back-en-service. Een van of base-url backend-id moet aanwezig zijn. N.v.t.
backend-id Id van de back-end waar naar moet worden gerouteerd. (Back-end-entiteiten worden beheerd via Azure Portal, APIen PowerShell.) Een van of base-url backend-id moet aanwezig zijn. N.v.t.
sf-partition-key Alleen van toepassing wanneer de back-Service Fabric service is en wordt opgegeven met behulp van 'back-end-id'. Wordt gebruikt om een specifieke partitie van de naamoplossingsservice om te lossen. Nee N.v.t.
sf-replica-type Alleen van toepassing wanneer de back-Service Fabric service is en wordt opgegeven met behulp van 'back-end-id'. Hiermee bepaalt u of de aanvraag naar de primaire of secundaire replica van een partitie moet gaan. Nee N.v.t.
sf-resolve-condition Alleen van toepassing wanneer de back-Service Fabric is. Voorwaarde die identificeert of de aanroep Service Fabric back-end moet worden herhaald met een nieuwe oplossing. Nee N.v.t.
sf-service-instance-name Alleen van toepassing wanneer de back-Service Fabric is. Hiermee kunt u service-exemplaren tijdens runtime wijzigen. Nee N.v.t.
sf-listener-name Alleen van toepassing wanneer de back-Service Fabric service is en wordt opgegeven met behulp van 'back-end-id'. Service Fabric Reliable Services kunt u meerdere listeners in een service maken. Dit kenmerk wordt gebruikt om een specifieke listener te selecteren wanneer een betrouwbare back-endservice meer dan één listener heeft. Als dit kenmerk niet is opgegeven, API Management een listener zonder een naam gebruiken. Een listener zonder een naam is gebruikelijk voor Reliable Services die slechts één listener hebben. Nee N.v.t.

Gebruik

Dit beleid kan worden gebruikt in de volgende beleidssecties en -scopes.

  • Beleidssecties: inkomende, back-end

  • Beleidsbereiken: alle scopes

Body instellen

Gebruik het set-body beleid om de bericht body in te stellen voor binnenkomende en uitgaande aanvragen. Als u toegang wilt krijgen tot de berichtgedeelte, kunt u de eigenschap of de gebruiken, afhankelijk van of het beleid zich in de sectie voor binnenkomende of uitgaande gegevens in de sectie voor binnenkomende of context.Request.Body uitgaande gegevens context.Response.Body voordeed.

Belangrijk

Houd er rekening mee dat wanneer u toegang hebt tot de bericht-body met of , de oorspronkelijke bericht-body verloren gaat en moet worden ingesteld door de body terug te retourneren context.Request.Body context.Response.Body in de expressie. Als u de inhoud van de tekst wilt behouden, stelt u preserveContent de parameter in op bij het openen van het true bericht. Als preserveContent is ingesteld op en een andere body wordt geretourneerd door de true expressie, wordt de geretourneerde body gebruikt.

Houd rekening met de volgende overwegingen bij het gebruik van het set-body beleid.

  • Als u het beleid gebruikt om een nieuwe of bijgewerkte body te retourneren, hoeft u niet in te stellen op omdat u expliciet de nieuwe inhoud van de set-body preserveContent body true oplevert.
    • Het behouden van de inhoud van een antwoord in de binnenkomende pijplijn is niet logisch omdat er nog geen reactie is.
    • Het behouden van de inhoud van een aanvraag in de uitgaande pijplijn is niet logisch omdat de aanvraag op dit moment al naar de back-out is verzonden.
    • Als dit beleid wordt gebruikt wanneer er geen bericht-body is, bijvoorbeeld in een inkomende GET, wordt er een uitzondering weergegeven.

Zie de secties , en in de tabel context.Request.Body context.Response.Body IMessage Contextvariabele voor meer informatie.

Beleidsverklaring

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

Voorbeelden

Voorbeeld van letterlijke tekst

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

Voorbeeld van toegang tot de body als een tekenreeks. Houd er rekening mee dat we de oorspronkelijke aanvraag body behouden, zodat we deze later in de pijplijn kunnen openen.

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

Voorbeeld van toegang tot de body als een JObject. Houd er rekening mee dat omdat we de oorspronkelijke aanvraag niet reserveren, dit later in de pijplijn tot een uitzondering leidt.

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

Antwoord filteren op basis van product

In dit voorbeeld ziet u hoe u inhoud filtert door gegevenselementen te verwijderen uit het antwoord dat is ontvangen van de back-endservice wanneer u het Starter product gebruikt. Zie Cloud Cover Aflevering 177: Meer API Management-functies met Vlad Vinogradsky en fast-forward naar 34:30 voor een demonstratie van het configureren en gebruiken van dit beleid. Begin om 31:50 uur voor een overzicht van de prognose-API voor donkere lucht die wordt gebruikt voor deze demo.

<!-- 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 api 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 [] {"minutely", "hourly", "daily", "flags"}) {
          response.Property (key).Remove ();
        }
        return response.ToString();
      }
    </set-body>
  </when>
</choose>

Liquid-sjablonen gebruiken met de set-body

Het set-body beleid kan worden geconfigureerd voor het gebruik van de Liquid- templating-taal om de body van een aanvraag of antwoord te transformeren. Dit kan zeer effectief zijn als u de indeling van uw bericht volledig moet wijzigen.

Belangrijk

De implementatie van Liquid die in het set-body beleid wordt gebruikt, is geconfigureerd in de C#-modus. Dit is vooral belangrijk bij het doen van zaken zoals filteren. Voor het gebruik van een datumfilter is bijvoorbeeld het gebruik van het casing- en C#-datumopmaak nodig, bijvoorbeeld:

{{body.foo.startDateTime| Date:"yyyyMMddTHH:mm:ssZ"}}

Belangrijk

Als u een juiste binding wilt maken met een XML-body met behulp van de Liquid-sjabloon, gebruikt u een beleid om Content-Type in te stellen op application/xml, text/xml (of een type dat eindigt op +xml); voor een JSON-body moet dit set-header application/json, text/json zijn (of een type dat eindigt op +json).

JSON converteren naar SOAP met behulp van een Liquid-sjabloon

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

JSON transformeren met behulp van een Liquid-sjabloon

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

Elementen

Naam Beschrijving Vereist
set-body Hoofdelement. Bevat de tekst van de tekst of een expressie die een body retourneert. Ja

Eigenschappen

Naam Beschrijving Vereist Standaard
sjabloon Wordt gebruikt om de templating-modus te wijzigen waarin het beleid voor de set-body wordt uitgevoerd. Momenteel is de enige ondersteunde waarde:

- liquid : het beleid voor de set body maakt gebruik van de liquide templating-engine
Nee

Voor toegang tot informatie over de aanvraag en het antwoord kan de Liquid-sjabloon worden binden aan een contextobject met de volgende eigenschappen:

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

Gebruik

Dit beleid kan worden gebruikt in de volgende beleidssecties en -scopes.

  • Beleidssecties: inkomende, uitgaande, back-en

  • Beleidsbereiken: alle scopes

HTTP-header instellen

Het beleid wijst een waarde toe aan een bestaand antwoord en/of aanvraagheader of voegt een nieuw antwoord set-header en/of aanvraagheader toe.

Hiermee voegt u een lijst met HTTP-headers in een HTTP-bericht in. Wanneer dit beleid in een binnenkomende pijplijn wordt geplaatst, worden de HTTP-headers voor de aanvraag die wordt doorgegeven aan de doelservice, door dit beleid. Wanneer dit beleid in een uitgaande pijplijn wordt geplaatst, worden met dit beleid de HTTP-headers voor het antwoord dat naar de client van de gateway wordt verzonden,sets uitgevoerd.

Beleidsverklaring

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

Voorbeelden

Voorbeeld: koptekst toevoegen, bestaande overschrijven

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

Voorbeeld: header verwijderen

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

Contextinformatie doorsturen naar de back-endservice

In dit voorbeeld ziet u hoe u beleid op API-niveau kunt toepassen om contextinformatie aan de back-endservice op te geven. Zie Cloud Cover Aflevering 177: Meer API Management-functies met Vlad Vinogradsky en fast-forward naar 10:30 voor een demonstratie van het configureren en gebruiken van dit beleid. Om 12:10 is er een demo van het aanroepen van een bewerking in de ontwikkelaarsportal, waar u het beleid op het werk kunt zien.

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

Zie Beleidsexpressie en Contextvariabele voor meer informatie.

Notitie

Meerdere waarden van een header worden samenvoegd met een CSV-tekenreeks, bijvoorbeeld: headerName: value1,value2,value3

Uitzonderingen zijn gestandaardiseerde headers, die de volgende waarden hebben:

  • kan komma's ( User-Agent , WWW-Authenticate , ) Proxy-Authenticate bevatten
  • kan datum ( Cookie , Set-Cookie , ) Warning bevatten
  • bevat date ( Date , , , , , , Expires If-Modified-Since If-Unmodified-Since Last-Modified Retry-After ).

In het geval van deze uitzonderingen worden meerdere headerwaarden niet in één tekenreeks samenvoegd en worden ze doorgegeven als afzonderlijke headers, bijvoorbeeld: User-Agent: value1 User-Agent: value2 User-Agent: value3

Elementen

Naam Beschrijving Vereist
set-header Hoofdelement. Ja
waarde Hiermee geeft u de waarde van de in te stellen header op. Voeg voor meerdere headers met dezelfde naam extra elementen value toe. Nee

Eigenschappen

Naam Beschrijving Vereist Standaard
exists-action Hiermee geeft u op welke actie moet worden ondernomen wanneer de header al is opgegeven. Dit kenmerk moet een van de volgende waarden hebben.

- overschrijven : vervangt de waarde van de bestaande header.
- overslaan : vervangt niet de bestaande headerwaarde.
- toevoegen : de waarde wordt aan de bestaande headerwaarde toevoegen.
- verwijderen : hiermee verwijdert u de header uit de aanvraag.

Wanneer deze is ingesteld op meerdere vermeldingen met dezelfde naam, wordt de header ingesteld op basis van alle vermeldingen (die meerdere keren worden weergegeven); alleen vermelde waarden worden ingesteld in het override resultaat.
Nee overschrijven
naam Hiermee geeft u de naam van de header moet worden ingesteld. Ja N.v.t.

Gebruik

Dit beleid kan worden gebruikt in de volgende beleidssecties en -scopes.

  • Beleidssecties: inkomende, uitgaande, back-end, on-error

  • Beleidsbereiken: alle scopes

Queryreeksparameter instellen

Met set-query-parameter het beleid wordt de waarde van toegevoegd, vervangen of de queryreeksparameter van de aanvraag verwijderd. Kan worden gebruikt om queryparameters door te geven die worden verwacht door de back-endservice, die optioneel zijn of nooit aanwezig zijn in de aanvraag.

Beleidsverklaring

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

Voorbeeld


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

Contextinformatie doorsturen naar de back-endservice

In dit voorbeeld ziet u hoe u beleid op API-niveau kunt toepassen om contextinformatie aan de back-endservice op te geven. Zie Cloud Cover Aflevering 177: Meer API Management-functies met Vlad Vinogradsky en fast-forward naar 10:30 voor een demonstratie van het configureren en gebruiken van dit beleid. Om 12:10 is er een demo van het aanroepen van een bewerking in de ontwikkelaarsportal, waar u het beleid op het werk kunt zien.

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

Zie Beleidsexpressie en Contextvariabele voor meer informatie.

Elementen

Naam Beschrijving Vereist
set-query-parameter Hoofdelement. Ja
waarde Hiermee geeft u de waarde van de in te stellen queryparameter op. Voeg extra elementen toe voor meerdere queryparameters met dezelfde value naam. Ja

Eigenschappen

Naam Beschrijving Vereist Standaard
exists-action Hiermee geeft u op welke actie moet worden uitgevoerd wanneer de querytekenreeks al is opgegeven. Dit kenmerk moet een van de volgende waarden hebben.

- overschrijven - vervangt de waarde van de bestaande parameter.
- overslaan : vervangt niet de bestaande queryparameterwaarde.
- toevoegen : de waarde wordt aan de bestaande queryparameterwaarde toevoegen.
- verwijderen : hiermee verwijdert u de queryparameter uit de aanvraag.

Wanneer deze is ingesteld op meerdere vermeldingen met dezelfde naam, wordt de queryparameter ingesteld op basis van alle vermeldingen (die meerdere keren worden weergegeven); alleen vermelde waarden worden ingesteld in het override resultaat.
Nee overschrijven
naam Hiermee geeft u de naam van de queryparameter moet worden ingesteld. Ja N.v.t.

Gebruik

Dit beleid kan worden gebruikt in de volgende beleidssecties en -scopes.

  • Beleidssecties: inkomende, back-end

  • Beleidsbereiken: alle scopes

URL herschrijven

Het beleid converteert een aanvraag-URL van het openbare formulier naar het formulier dat wordt verwacht door de rewrite-uri webservice, zoals wordt weergegeven in het volgende voorbeeld.

  • Openbare URL - http://api.example.com/storenumber/ordernumber

  • Aanvraag-URL - http://api.example.com/v2/US/hardware/storenumber&ordernumber?City&State

    Dit beleid kan worden gebruikt wanneer een menselijke url en/of browservriendelijke URL moet worden omgezet in de URL-indeling die door de webservice wordt verwacht. Dit beleid hoeft alleen te worden toegepast bij het beschikbaar maken van een alternatieve URL-indeling, zoals schone URL's, RESTful-URL's, gebruiksvriendelijke URL's of URL's die uitsluitend structurele URL's zijn die geen queryreeks bevatten en in plaats daarvan alleen het pad van de resource bevatten (na het schema en de autoriteit). Dit wordt vaak gedaan voor vormgeving, bruikbaarheid of zoekmachineoptimalisatie (SEO).

Notitie

U kunt alleen queryreeksparameters toevoegen met behulp van het beleid. U kunt geen extra parameters voor het sjabloonpad toevoegen aan de herschrijf-URL.

Beleidsverklaring

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

Voorbeeld

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

Elementen

Naam Beschrijving Vereist
rewrite-uri Hoofdelement. Ja

Kenmerken

Kenmerk Beschrijving Vereist Standaard
sjabloon De werkelijke webservice-URL met queryreeksparameters. Wanneer u expressies gebruikt, moet de hele waarde een expressie zijn. Ja N.v.t.
copy-unmatched-params Hiermee geeft u op of queryparameters in de binnenkomende aanvraag die niet aanwezig zijn in de oorspronkelijke URL-sjabloon worden toegevoegd aan de URL die is gedefinieerd door de sjabloon voor opnieuw schrijven Nee true

Gebruik

Dit beleid kan worden gebruikt in de volgende beleidssecties en -scopes.

  • Beleidssecties: inkomende

  • Beleidsbereiken: alle scopes

XML transformeren met behulp van een XSLT

Het Transform XML using an XSLT beleid past een XSL-transformatie toe op XML in de aanvraag- of antwoord-body.

Beleidsverklaring

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

Voorbeeld

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

Elementen

Naam Beschrijving Vereist
xsl-transform Hoofdelement. Ja
parameter Wordt gebruikt voor het definiëren van variabelen die worden gebruikt in de transformatie Nee
xsl:stylesheet Het element Basisstijlblad. Alle elementen en kenmerken die in zijn gedefinieerd, volgen de standaard XSLT-specificatie Ja

Gebruik

Dit beleid kan worden gebruikt in de volgende beleidssecties en -scopes.

  • Beleidssecties: inkomende, uitgaande

  • Beleidsbereiken: alle scopes

Volgende stappen

Zie de volgende onderwerpen voor meer informatie: