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: converteert de aanvraag- of antwoord-body van JSON naar XML.
XML converteren naar JSON: converteert de aanvraag- of antwoord-body van XML naar JSON.
Tekenreeks in de body zoeken en vervangen: zoekt een aanvraag- of antwoordsubtekenreeks en vervangt deze door een andere subtekenreeks.
URL's in inhoud maskeren: schrijf koppelingen in de antwoord-body opnieuw (maskers) zodat ze via de gateway naar de equivalente koppeling verwijzen.
Back-endservice instellen: wijzigt de back-endservice voor een binnenkomende aanvraag.
Body instellen: hiermee stelt u de bericht body in voor binnenkomende en uitgaande aanvragen.
HTTP-header instellen: hiermee wijst u een waarde toe aan een bestaand antwoord en/of aanvraagheader of voegt u een nieuw antwoord en/of een aanvraagheader toe.
Queryreeksparameter instellen: hiermee wordt de waarde van toegevoegd, vervangen of de queryreeksparameter van de aanvraag verwijderd.
URL herschrijven: converteert een aanvraag-URL van het openbare formulier naar het formulier dat wordt verwacht door de webservice.
XML transformeren met behulp van een XSLT: hiermee wordt een XSL-transformatie toegepast op XML in de aanvraag- of antwoord body.
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-bodypreserveContentbodytrueoplevert.- 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-Authenticatebevatten - kan datum (
Cookie,Set-Cookie, )Warningbevatten - bevat date (
Date, , , , , ,ExpiresIf-Modified-SinceIf-Unmodified-SinceLast-ModifiedRetry-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/ordernumberAanvraag-URL -
http://api.example.com/v2/US/hardware/storenumber&ordernumber?City&StateDit 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:
- Beleidsregels in API Management
- Beleidsverwijzing voor een volledige lijst met beleidsverklaringen en de instellingen
- Voorbeelden van beleid