Werken met Azure Functions-proxy's

In dit artikel wordt uitgelegd hoe u uw Azure Functions-proxy's. Met deze functie kunt u eindpunten opgeven in uw functie-app die door een andere resource worden geïmplementeerd. U kunt deze -proxies gebruiken om een grote API op te delen in meerdere functie-apps (zoals in een microservicearchitectuur), terwijl u nog steeds één API-oppervlak voor clients presenteert.

Standard Functions-facturering is van toepassing op proxy-uitvoeringen. Zie Prijzen voor Azure Functions voor meer informatie.

Dit is referentie-informatie voor Azure Functions-ontwikkelaars. Als u nog geen ervaring hebt met Azure Functions, begint u met de volgende resources:

• Uw eerste functie maken: C#, JavaScript, Java of Python.
• Naslaginformatie over Azure Functions voor ontwikkelaars.
• Taalspecifieke naslaginformatie: C#, C# script, F#, Java, JavaScript of Python.
• Concepten van Azure Functions-triggers en -bindingen.
• Azure-functies lokaal programmeren en testen.

Een proxy maken

In deze sectie ziet u hoe u een proxy maakt in de Functions-portal.

1. Open de [Azure Portal]en ga vervolgens naar uw functie-app.
2. Selecteer nieuwe proxy in het linkerdeelvenster.
3. Geef een naam op voor uw proxy.
4. Configureer het eindpunt dat beschikbaar wordt gemaakt in deze functie-app door de routesjabloon en HTTP-methoden op te geven. Deze parameters gedragen zich volgens de regels voor [HTTP-triggers.]
5. Stel de back-end-URL in op een ander eindpunt. Dit eindpunt kan een functie in een andere functie-app zijn of een andere API. De waarde hoeft niet statisch te zijn [] en kan verwijzen naar toepassingsinstellingen en [parameters uit de oorspronkelijke clientaanvraag].
6. Klik op Create.

Uw proxy bestaat nu als een nieuw eindpunt in uw functie-app. Vanuit clientperspectief is dit gelijk aan een HttpTrigger in Azure Functions. U kunt uw nieuwe proxy uitproberen door de proxy-URL te kopiëren en deze te testen met uw favoriete HTTP-client.

Aanvragen en antwoorden wijzigen

Met Azure Functions-proxy's kunt u aanvragen naar en antwoorden van de back-end wijzigen. Deze transformaties kunnen variabelen gebruiken zoals gedefinieerd in [Variabelen gebruiken.]

De back-endaanvraag wijzigen

De back-endaanvraag wordt standaard als een kopie van de oorspronkelijke aanvraag initialiseren. Naast het instellen van de back-end-URL kunt u wijzigingen aanbrengen in de HTTP-methode, headers en queryreeksparameters. De gewijzigde waarden kunnen verwijzen naar toepassingsinstellingen en [-parameters uit de oorspronkelijke clientaanvraag.]

Back-endaanvragen kunnen worden gewijzigd in de portal door de sectie overschrijven van aanvragen van de detailpagina van de proxy uit te breiden.

Het antwoord wijzigen

Standaard wordt het antwoord van de client als een kopie van het back-end-antwoord initialiseren. U kunt wijzigingen aanbrengen in de statuscode, redenzin, headers en hoofdtekst van het antwoord. De gewijzigde waarden kunnen verwijzen [naar toepassingsinstellingen,] parameters van de oorspronkelijke clientaanvraagen [parameters uit het back-end-antwoord].

Back-endaanvragen kunnen worden gewijzigd in de portal door de sectie Antwoord overschrijven van de detailpagina van de proxy uit te breiden.

Variabelen gebruiken

De configuratie voor een proxy hoeft niet statisch te zijn. U kunt deze voorwaarde instellen voor het gebruik van variabelen uit de oorspronkelijke clientaanvraag, het back-end-antwoord of toepassingsinstellingen.

Verwijzen naar lokale functies

U kunt gebruiken om rechtstreeks te verwijzen naar localhost een functie in dezelfde functie-app, zonder een retourproxyaanvraag.

"backendUri": "https://localhost/api/httptriggerC#1" verwijst naar een lokale http-geactiveerde functie op de route /api/httptriggerC#1

Parameters voor verwijzingsaanvraag

U kunt aanvraagparameters gebruiken als invoer voor de eigenschap van de back-end-URL of als onderdeel van het wijzigen van aanvragen en antwoorden. Sommige parameters kunnen worden gebonden vanuit de routesjabloon die is opgegeven in de basisproxyconfiguratie en andere kunnen afkomstig zijn van de eigenschappen van de binnenkomende aanvraag.

Routesjabloonparameters

Parameters die worden gebruikt in de routesjabloon zijn beschikbaar om naar te verwijzen met de naam. De parameternamen worden tussen accolades ( ) {} ingesloten.

Als een proxy bijvoorbeeld een routesjabloon heeft, zoals , kan de /pets/{petId} back-end-URL de waarde {petId} van bevatten, zoals in https://<AnotherApp>.azurewebsites.net/api/pets/{petId} . Als de routesjabloon wordt beëindigd in een jokerteken, zoals , is de waarde een tekenreeksweergave van de resterende padsegmenten /api/{*restOfPath} {restOfPath} van de binnenkomende aanvraag.

Aanvullende aanvraagparameters

Naast de routesjabloonparameters kunnen de volgende waarden worden gebruikt in configuratiewaarden:

• {request.method}: de HTTP-methode die wordt gebruikt voor de oorspronkelijke aanvraag.
• {request.headers. <HeaderName> }: Een header die kan worden gelezen uit de oorspronkelijke aanvraag. Vervang <HeaderName> door de naam van de header die u wilt lezen. Als de header niet is opgenomen in de aanvraag, is de waarde de lege tekenreeks.
• {request.querystring. <ParameterName> }: Een querytekenreeksparameter die kan worden gelezen uit de oorspronkelijke aanvraag. Vervang <ParameterName> door de naam van de parameter die u wilt lezen. Als de parameter niet is opgenomen in de aanvraag, is de waarde de lege tekenreeks.

Verwijzen naar antwoordparameters voor back-end

Antwoordparameters kunnen worden gebruikt als onderdeel van het wijzigen van het antwoord op de client. De volgende waarden kunnen worden gebruikt in configuratiewaarden:

• {backend.response.statusCode}: De HTTP-statuscode die wordt geretourneerd op het back-end-antwoord.
• {backend.response.statusReason}: De HTTP-redenzin die wordt geretourneerd in het back-end-antwoord.
• {backend.response.headers. <HeaderName> }: Een header die kan worden gelezen uit het back-end-antwoord. Vervang <HeaderName> door de naam van de header die u wilt lezen. Als de header niet is opgenomen in het antwoord, is de waarde de lege tekenreeks.

Verwijzen naar toepassingsinstellingen

U kunt ook verwijzen naar toepassingsinstellingen die zijn gedefinieerd voor de functie-app door de naam van de instelling om te zetten met procenttekens (%).

Voor een back-end-URL van wordt bijvoorbeeld %ORDER_PROCESSING_HOST% vervangen door de waarde van de https://%ORDER_PROCESSING_HOST%/api/orders ORDER_PROCESSING_HOST instelling.

Problemen met -proxies oplossen

Door de vlag toe te "debug":true voegen aan een proxy in proxies.json uw, kunt u logboekregistratie voor foutopsporing inschakelen. Logboeken worden opgeslagen in D:\home\LogFiles\Application\Proxies\DetailedTrace en zijn toegankelijk via de geavanceerde hulpprogramma's (kudu). HTTP-antwoorden bevatten ook een Proxy-Trace-Location header met een URL voor toegang tot het logboekbestand.

U kunt fouten opsporen in een proxy aan de clientzijde door een Proxy-Trace-Enabled header toe te voegen die is ingesteld op true . Hiermee wordt ook een trace naar het bestandssysteem gelogd en wordt de traceer-URL als een header in het antwoord retourneerd.

Proxy-traceringen blokkeren

Uit veiligheidsoverwegingen wilt u misschien niet toestaan dat iemand die uw service aanroept, een traceer genereert. Ze hebben geen toegang tot de traceerinhoud zonder uw aanmeldingsreferenties, maar het genereren van de trace verbruikt resources en laat zien dat u functie-proxies gebruikt.

Schakel traceringen helemaal uit door toe te "debug":false voegen aan een bepaalde proxy in uw proxies.json .

Geavanceerde configuratie

De -proxies die u configureert, worden opgeslagen in een bestand proxies.json, dat zich in de hoofdmap van een functie-app-map bevindt. U kunt dit bestand handmatig bewerken en implementeren als onderdeel van uw app wanneer u een van de implementatiemethoden gebruikt die door Functions worden ondersteund.

Proxies.json wordt gedefinieerd door een proxies-object, dat bestaat uit benoemde proxies en hun definities. Als uw editor dit ondersteunt, kunt u desgewenst verwijzen naar een JSON-schema voor het voltooien van de code. Een voorbeeldbestand kan er als volgt uitzien:

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "proxy1": {
            "matchCondition": {
                "methods": [ "GET" ],
                "route": "/api/{test}"
            },
            "backendUri": "https://<AnotherApp>.azurewebsites.net/api/<FunctionName>"
        }
    }
}

Elke proxy heeft een gebruiksvriendelijke naam, zoals proxy1 in het vorige voorbeeld. Het bijbehorende proxydefinitieobject wordt gedefinieerd door de volgende eigenschappen:

• matchCondition: vereist: een object dat de aanvragen definieren die de uitvoering van deze proxy activeren. Deze bevat twee eigenschappen die worden gedeeld met [HTTP-triggers:]
  • methods: een matrix van de HTTP-methoden waar de proxy op reageert. Als deze niet is opgegeven, reageert de proxy op alle HTTP-methoden op de route.
  • route: vereist: definieert de routesjabloon, waarmee wordt bepaald op welke aanvraag-URL's uw proxy reageert. In tegenstelling tot http-triggers is er geen standaardwaarde.
• backendUri: de URL van de back-endresource waarop de aanvraag moet worden geproxied. Deze waarde kan verwijzen naar toepassingsinstellingen en -parameters uit de oorspronkelijke clientaanvraag. Als deze eigenschap niet is opgenomen, Azure Functions antwoordt met een HTTP 200 OK.
• requestOverrides: een object dat transformaties naar de back-endaanvraag definieert. Zie [Define a requestOverrides object (Een requestOverrides-object definiëren).]
• responseOverrides: een object dat transformaties naar het clientreactie definieert. Zie [Een responseOverrides-object definiëren.]

Afzonderlijke -proxies uitschakelen

U kunt afzonderlijke proxy's uitschakelen door toe te "disabled": true voegen aan de proxy in het proxies.json bestand. Dit zorgt ervoor dat aanvragen die voldoen aan de matchCondition 404 retourneren.

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "Root": {
            "disabled":true,
            "matchCondition": {
                "route": "/example"
            },
            "backendUri": "https://<AnotherApp>.azurewebsites.net/api/<FunctionName>"
        }
    }
}

Toepassings Instellingen

Het proxygedrag kan worden bepaald door verschillende app-instellingen. Ze worden allemaal beschreven in de naslag voor Instellingen Functions-app

• AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL
• AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES

Gereserveerde tekens (tekenreeksopmaak)

Met behulp van \ als escape-symbool worden alle tekenreeksen uit een JSON-bestand gelezen. Met proxies worden accolades ook geïnterpreteerd. Bekijk hieronder een volledige set voorbeelden.

Een requestOverrides-object definiëren

Het object requestOverrides definieert wijzigingen in de aanvraag wanneer de back-endresource wordt aangeroepen. Het object wordt gedefinieerd door de volgende eigenschappen:

• backend.request.method: de HTTP-methode die wordt gebruikt om de back-end aan te roepen.
• backend.request.querystring. <ParameterName> : Een queryreeksparameter die kan worden ingesteld voor de aanroep van de back-end. Vervang <ParameterName> door de naam van de parameter die u wilt instellen. Als er een lege tekenreeks wordt opgegeven, wordt de parameter nog steeds opgenomen in de back-endaanvraag.
• backend.request.headers. <HeaderName>: Een header die kan worden ingesteld voor de aanroep naar de back-end. Vervang <HeaderName> door de naam van de header die u wilt instellen. Als er een lege tekenreeks wordt opgegeven, wordt de parameter nog steeds opgenomen in de back-endaanvraag.

Waarden kunnen verwijzen naar toepassingsinstellingen en -parameters uit de oorspronkelijke clientaanvraag.

Een voorbeeldconfiguratie kan er als volgt uitzien:

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "proxy1": {
            "matchCondition": {
                "methods": [ "GET" ],
                "route": "/api/{test}"
            },
            "backendUri": "https://<AnotherApp>.azurewebsites.net/api/<FunctionName>",
            "requestOverrides": {
                "backend.request.headers.Accept": "application/xml",
                "backend.request.headers.x-functions-key": "%ANOTHERAPP_API_KEY%"
            }
        }
    }
}

Een responseOverrides-object definiëren

Het object requestOverrides definieert wijzigingen die worden aangebracht in het antwoord dat wordt doorgegeven aan de client. Het object wordt gedefinieerd door de volgende eigenschappen:

• response.statusCode: de HTTP-statuscode die moet worden geretourneerd naar de client.
• response.statusReason: de HTTP-redenzin die moet worden geretourneerd naar de client.
• response.body: de tekenreeksweergave van de body die moet worden geretourneerd naar de client.
• response.headers. <HeaderName>: Een header die kan worden ingesteld voor het antwoord op de client. Vervang <HeaderName> door de naam van de header die u wilt instellen. Als u de lege tekenreeks op geeft, wordt de header niet opgenomen in het antwoord.

Waarden kunnen verwijzen naar toepassingsinstellingen, parameters van de oorspronkelijke clientaanvraag en parameters uit het back-end-antwoord.

Een voorbeeldconfiguratie kan er als volgt uitzien:

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "proxy1": {
            "matchCondition": {
                "methods": [ "GET" ],
                "route": "/api/{test}"
            },
            "responseOverrides": {
                "response.body": "Hello, {test}",
                "response.headers.Content-Type": "text/plain"
            }
        }
    }
}