Azure Functions HTTP-trigger
Met de HTTP-trigger kunt u een functie aanroepen met een HTTP-aanvraag. U kunt een HTTP-trigger gebruiken om serverloze API's te bouwen en te reageren op webhooks.
De standaard retourwaarde voor een door HTTP geactiveerde functie is:
HTTP 204 No Contentmet een lege body in Functions 2.x en hogerHTTP 200 OKmet een lege body in Functions 1.x
Configureer een uitvoerbinding om het HTTP-antwoord te wijzigen.
Zie het overzicht en de naslaginformatie voor uitvoerbinding voor meer informatie over HTTP-bindingen.
Tip
Als u van plan bent om de HTTP- of WebHook-bindingen te gebruiken, plan dan om uitputting van de poort te voorkomen. Dat kan worden veroorzaakt door onjuiste instantie-instellingen van HttpClient. Raadpleeg Verbindingen beheren in Azure Functions voor meer informatie.
Voorbeeld
In het volgende voorbeeld ziet u een C#-functie die zoekt naar een parameter in de name queryreeks of de body van de HTTP-aanvraag. U ziet dat de retourwaarde wordt gebruikt voor de uitvoerbinding, maar er is geen kenmerk voor de retourwaarde vereist.
[FunctionName("HttpTriggerCSharp")]
public static async Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)]
HttpRequest req, ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
string name = req.Query["name"];
string requestBody = String.Empty;
using (StreamReader streamReader = new StreamReader(req.Body))
{
requestBody = await streamReader.ReadToEndAsync();
}
dynamic data = JsonConvert.DeserializeObject(requestBody);
name = name ?? data?.name;
return name != null
? (ActionResult)new OkObjectResult($"Hello, {name}")
: new BadRequestObjectResult("Please pass a name on the query string or in the request body");
}
Kenmerken en aantekeningen
In C#-klassebibliotheken en Java HttpTrigger is het kenmerk beschikbaar om de functie te configureren.
U kunt het autorisatieniveau en toegestane HTTP-methoden instellen in kenmerk constructorparameters, webhooktype en een routesjabloon. Zie configuratie voor meer informatie over deze instellingen.
In dit voorbeeld wordt gedemonstreerd hoe u het kenmerk HttpTrigger gebruikt.
[FunctionName("HttpTriggerCSharp")]
public static Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Anonymous)] HttpRequest req)
{
...
}
Zie het triggervoorbeeld voor een volledig voorbeeld.
Configuratie
De volgende tabel bevat informatie over de bindingsconfiguratie-eigenschappen die u instelt in het bestand function.json en het kenmerk HttpTrigger.
| function.json-eigenschap | Kenmerkeigenschap | Beschrijving |
|---|---|---|
| type | N.v.t. | Vereist: moet worden ingesteld op httpTrigger . |
| direction | N.v.t. | Vereist: moet worden ingesteld op in . |
| name | N.v.t. | Vereist: de naam van de variabele die wordt gebruikt in functiecode voor de aanvraag- of aanvraag body. |
| authLevel | AuthLevel | Bepaalt welke sleutels, indien aanwezig, aanwezig moeten zijn op de aanvraag om de functie aan te roepen. Het autorisatieniveau kan een van de volgende waarden zijn:
|
| Methoden | Methoden | Een matrix van de HTTP-methoden waarop de functie reageert. Als deze niet wordt opgegeven, reageert de functie op alle HTTP-methoden. Zie Het HTTP-eindpunt aanpassen. |
| route | Route | Definieert de routesjabloon, waarmee wordt bepaald op welke aanvraag-URL's uw functie reageert. De standaardwaarde als er geen is opgegeven, is <functionname> . Zie het HTTP-eindpunt aanpassen voor meer informatie. |
| webHookType | WebHookType | Alleen ondersteund voor versie 1.x van de runtime. Hiermee configureert u de HTTP-trigger om te fungeren als een webhookontvanger voor de opgegeven provider. Stel de eigenschap niet methods in als u deze eigenschap in stelt. Het type webhook kan een van de volgende waarden zijn:
|
Nettolading
Het invoertype van de trigger wordt gedeclareerd HttpRequest als een of een aangepast type. Als u HttpRequest kiest, krijgt u volledige toegang tot het aanvraagobject. Voor een aangepast type probeert de runtime de JSON-aanvraag body te parseren om de objecteigenschappen in te stellen.
Het HTTP-eindpunt aanpassen
Wanneer u een functie voor een HTTP-trigger maakt, is de functie standaard adresseerbaar met een route van het formulier:
http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>
U kunt deze route aanpassen met behulp van de route optionele eigenschap in de invoerbinding van de HTTP-trigger. Zo definieert het volgende function.jsbestand een eigenschap voor route een HTTP-trigger:
{
"bindings": [
{
"type": "httpTrigger",
"name": "req",
"direction": "in",
"methods": [ "get" ],
"route": "products/{category:alpha}/{id:int?}"
},
{
"type": "http",
"name": "res",
"direction": "out"
}
]
}
Met deze configuratie is de functie nu adresseerbaar met de volgende route in plaats van de oorspronkelijke route.
http://<APP_NAME>.azurewebsites.net/api/products/electronics/357
Met deze configuratie kan de functiecode twee parameters ondersteunen in het adres, de categorie en de id. Zie Routering in ASP.NET Core voor meer informatie over hoe routeparameters in een URL worden ASP.NET Core.
U kunt elke routebeperking voor web-API's gebruiken met uw parameters. De volgende C#-functiecode maakt gebruik van beide parameters.
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
public static IActionResult Run(HttpRequest req, string category, int? id, ILogger log)
{
var message = String.Format($"Category: {category}, ID: {id}");
return (ActionResult)new OkObjectResult(message);
}
Standaard krijgen alle functieroutes het voorvoegsel api. U kunt het voorvoegsel ook aanpassen of verwijderen met behulp van de eigenschap inhost.jsextensions.http.routePrefix bestand. In het volgende voorbeeld wordt het voorvoegsel van de API-route verwijderd met behulp van een lege tekenreeks voor het voorvoegsel in host.jsop bestand.
{
"extensions": {
"http": {
"routePrefix": ""
}
}
}
Routeparameters gebruiken
Routeparameters die het patroon van een functie route hebben gedefinieerd, zijn beschikbaar voor elke binding. Als u bijvoorbeeld een route hebt gedefinieerd als , kan een table storage-binding de waarde van de "route": "products/{id}" {id} parameter in de bindingsconfiguratie gebruiken.
In de volgende configuratie ziet u hoe {id} de parameter wordt doorgegeven aan de van de rowKey binding.
{
"type": "table",
"direction": "in",
"name": "product",
"partitionKey": "products",
"tableName": "products",
"rowKey": "{id}"
}
Wanneer u routeparameters gebruikt, invoke_URL_template wordt er automatisch een gemaakt voor uw functie. Uw clients kunnen de URL-sjabloon gebruiken om inzicht te krijgen in de parameters die ze nodig hebben om de URL door te geven bij het aanroepen van uw functie met behulp van de URL. Navigeer naar een van uw HTTP-geactiveerde functies in Azure Portal selecteer Functie-URL downloaden.
U kunt programmatisch toegang krijgen tot de invoke_URL_template met behulp van Azure Resource Manager API's voor List Functions of Get Function.
Werken met clientidentiteiten
Als uw functie-app gebruik App Service verificatie/autorisatie,kunt u informatie over geverifieerde clients bekijken vanuit uw code. Deze informatie is beschikbaar als aanvraagheaders die worden geïnjecteerd door het platform.
U kunt deze informatie ook lezen uit bindingsgegevens. Deze mogelijkheid is alleen beschikbaar voor de Functions-runtime in 2.x en hoger. Het is momenteel ook alleen beschikbaar voor .NET-talen.
Informatie over geverifieerde clients is beschikbaar als een ClaimsPrincipal. De ClaimsPrincipal is beschikbaar als onderdeel van de aanvraagcontext, zoals wordt weergegeven in het volgende voorbeeld:
using System.Net;
using Microsoft.AspNetCore.Mvc;
using System.Security.Claims;
public static IActionResult Run(HttpRequest req, ILogger log)
{
ClaimsPrincipal identities = req.HttpContext.User;
// ...
return new OkObjectResult();
}
De ClaimsPrincipal kan ook gewoon worden opgenomen als een extra parameter in de functiehandtekening:
using System.Net;
using Microsoft.AspNetCore.Mvc;
using System.Security.Claims;
using Newtonsoft.Json.Linq;
public static void Run(JObject input, ClaimsPrincipal principal, ILogger log)
{
// ...
return;
}
Functietoegangssleutels
Met functies kunt u sleutels gebruiken om het moeilijker te maken om toegang te krijgen tot de eind punten van uw HTTP-functies tijdens het ontwikkelen. Tenzij het HTTP-toegangs niveau voor een HTTP-geactiveerde functie is ingesteld op anonymous , moeten aanvragen een API-toegangs sleutel bevatten in de aanvraag.
Hoewel sleutels een standaard beveiligings mechanisme bieden, kunt u extra opties overwegen om een HTTP-eind punt in de productie omgeving te beveiligen. Het is bijvoorbeeld doorgaans geen goede gewoonte om gedeeld geheim in open bare apps te distribueren. Als uw functie wordt aangeroepen vanuit een open bare client, kunt u overwegen om een ander beveiligings mechanisme te implementeren. Zie een HTTP-eind punt in productie beveiligenvoor meer informatie.
Wanneer u de waarden van de functie sleutel verlengt, moet u de bijgewerkte sleutel waarden hand matig opnieuw distribueren naar alle clients die uw functie aanroepen.
Autorisatie bereiken (functie niveau)
Er zijn twee toegangs scopes voor sleutels op functie niveau:
Functie: deze sleutels zijn alleen van toepassing op de specifieke functies waaronder ze zijn gedefinieerd. Wanneer u als een API-sleutel wordt gebruikt, is deze alleen toegankelijk voor deze functie.
Host: sleutels met een bereik van een host kunnen worden gebruikt voor toegang tot alle functies in de functie-app. Wanneer deze als een API-sleutel wordt gebruikt, is toegang tot alle functies in de functie-app toegestaan.
Elke sleutel krijgt de naam van de verwijzing en er is een standaard sleutel (met de naam ' default ') op het niveau van de functie en de host. Functie sleutels hebben voor rang op de sleutels van de host. Wanneer twee sleutels met dezelfde naam zijn gedefinieerd, wordt de functie toets altijd gebruikt.
Hoofd sleutel (beheer niveau)
Elke functie-app heeft ook een host-sleutel op beheer niveau met de naam _master . Naast het verschaffen van toegang op hostniveau voor alle functies in de app, biedt de hoofd sleutel ook beheerders toegang tot de runtime REST Api's. Deze sleutel kan niet worden ingetrokken. Wanneer u een toegangs niveau instelt admin , moeten aanvragen gebruikmaken van de hoofd sleutel. een andere sleutel resulteert in een toegangs fout.
Waarschuwing
Als gevolg van de verhoogde machtigingen in uw functie-app die is verleend door de hoofd sleutel, moet u deze sleutel niet delen met derden of deze distribueren in native client toepassingen. Wees voorzichtig bij het kiezen van het toegangs niveau voor de beheerder.
Sleutels verkrijgen
Sleutels worden opgeslagen als onderdeel van uw functie-app in Azure en worden in rust versleuteld. Als u uw sleutels wilt weergeven, maakt u nieuwe sleutels of rolt u sleutels naar nieuwe waarden, navigeert u naar een van uw http-geactiveerde functies in de Azure Portal en selecteert u Functiesleutels.
U kunt ook hostsleutels beheren. Navigeer naar de functie-app in Azure Portal en selecteer App-sleutels.
U kunt functie- en hostsleutels programmatisch verkrijgen met behulp van Azure Resource Manager API's. Er zijn API's om functiesleutels en lijsthostsleutels weer te geven.Bij het gebruik van implementatiesleuven zijn de equivalente API's List Function Keys Slot en List Host Keys Slot.
U kunt ook programmatisch nieuwe functie- en hostsleutels maken met behulp van de API's Functiegeheim maken of bijwerken,Functiegeheimsleuf maken of bijwerken,En Hostgeheim maken of bijwerken.
Functie- en hostsleutels kunnen programmatisch worden verwijderd met behulp van de API's Functiegeheim verwijderen,Functiegeheimsleuf verwijderen, Hostgeheimverwijderen en Hostgeheimensleuf verwijderen.
U kunt ook de verouderde API's voor sleutelbeheergebruiken om functiesleutels op te halen, maar in plaats daarvan wordt Azure Resource Manager aanbevolen.
Autorisatie van API-sleutels
Voor de meeste HTTP-triggersjablonen is een API-sleutel in de aanvraag vereist. Uw HTTP-aanvraag ziet er normaal gesproken uit als de volgende URL:
https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?code=<API_KEY>
De sleutel kan worden opgenomen in een queryreeksvariabele met de code naam , zoals hierboven. Het kan ook worden opgenomen in een x-functions-key HTTP-header. De waarde van de sleutel kan elke functiesleutel zijn die is gedefinieerd voor de functie of een hostsleutel.
U kunt anonieme aanvragen toestaan, waarvoor geen sleutels zijn vereist. U kunt ook vereisen dat de hoofdsleutel wordt gebruikt. U wijzigt het standaard autorisatieniveau met behulp van authLevel de eigenschap in de binding-JSON. Zie Trigger - configuratie voor meer informatie.
Notitie
Wanneer functies lokaal worden uitgevoerd, wordt autorisatie uitgeschakeld, ongeacht de opgegeven instelling op autorisatieniveau. Na het publiceren naar Azure wordt authLevel de instelling in de trigger afgedwongen. Sleutels zijn nog steeds vereist wanneer ze lokaal worden uitgevoerd in een container.
Een HTTP-eindpunt in productie beveiligen
Als u uw functie-eindpunten volledig wilt beveiligen in productie, kunt u overwegen om een van de volgende beveiligingsopties op app-niveau te implementeren. Wanneer u een van deze beveiligingsmethoden op functie-app-niveau gebruikt, moet u het autorisatieniveau van de door HTTP geactiveerde functie instellen op anonymous .
App Service-verificatie/-autorisatie inschakelen
Met het App Service-platform kunt u Azure Active Directory (AAD) en verschillende id-providers van derden gebruiken om clients te verifiëren. U kunt deze strategie gebruiken om aangepaste autorisatie regels voor uw functies te implementeren en u kunt met gebruikers gegevens uit uw functie code werken. Zie verificatie en autorisatie in azure app service en werken met client identiteitenvoor meer informatie.
Azure API Management (APIM) gebruiken om aanvragen te verifiëren
APIM biedt diverse API-beveiligings opties voor inkomende aanvragen. Zie API Management Authentication policies(Engelstalig) voor meer informatie. Als APIM is geïmplementeerd, kunt u uw functie-app zodanig configureren dat aanvragen alleen worden geaccepteerd van het IP-adres van uw APIM-exemplaar. Zie IP-adres beperkingenvoor meer informatie.
Uw functie-app geïsoleerd implementeren
Azure App Service Environment (ASE) biedt een toegewezen hostingomgeving waarin u uw functies kunt uitvoeren. Met ASE kunt u één front-endgateway configureren die u kunt gebruiken om alle binnenkomende aanvragen te verifiëren. Zie Configuring a Web Application Firewall (WAF) for App Service Environment (Een App Service Environment)voor meer App Service Environment.
Webhooks
Notitie
Webhookmodus is alleen beschikbaar voor versie 1.x van de Functions-runtime. Deze wijziging is aangebracht om de prestaties van HTTP-triggers in versie 2.x en hoger te verbeteren.
In versie 1.x bieden webhooksjablonen extra validatie voor webhook-nettoladingen. In versie 2.x en hoger werkt de HTTP-basistrigger nog steeds en is de aanbevolen methode voor webhooks.
GitHub webhooks
Als u wilt reageren GitHub webhooks, maakt u eerst uw functie met een HTTP-trigger en stelt u de eigenschap webHookType in op github . Kopieer vervolgens de URL en API-sleutel naar de pagina Webhook toevoegen van uw GitHub opslagplaats.

Slack-webhooks
De Slack-webhook genereert een token voor u in plaats van dat u dit kunt opgeven. Daarom moet u een functiespecifieke sleutel configureren met het token van Slack. Zie Autorisatiesleutels.
Webhooks en sleutels
Webhook-autorisatie wordt verwerkt door het ontvangeronderdeel van de webhook, dat deel uitmaakt van de HTTP-trigger, en het mechanisme varieert op basis van het type webhook. Elk mechanisme is afhankelijk van een sleutel. Standaard wordt de functiesleutel met de naam 'default' gebruikt. Als u een andere sleutel wilt gebruiken, configureert u de webhookprovider om de sleutelnaam met de aanvraag op een van de volgende manieren te verzenden:
- Queryreeks: de provider geeft de sleutelnaam door in de
clientidqueryreeksparameter, zoalshttps://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>. - Aanvraagheader: de provider geeft de sleutelnaam door in de
x-functions-clientidheader.
Inhoudstypen
Voor het doorgeven van binaire en formuliergegevens aan een niet-C#-functie moet u de juiste header van het inhoudstype gebruiken. Ondersteunde inhoudstypen octet-stream zijn onder andere voor binaire gegevens en typen met meerdere onderdelen.
Bekende problemen
In niet-C#-functies resulteert de aanvraag die wordt verzonden met het inhoudstype image/jpeg in een waarde die wordt doorgegeven aan de string functie. In dergelijke gevallen kunt u de waarde handmatig converteren naar een string byte-matrix om toegang te krijgen tot de onbewerkte binaire gegevens.
Limieten
De lengte van de HTTP-aanvraag is beperkt tot 100 MB (104.857.600 bytes) en de URL-lengte is beperkt tot 4 KB (4096 bytes). Deze limieten worden opgegeven door het element van hetWeb.config httpRuntime runtimebestand.
Als een functie die gebruikmaakt van de HTTP-trigger niet binnen 230 seconden wordt voltooid, thaalt de Azure Load Balancer een time-out en wordt een HTTP 502-fout weergegeven. De functie blijft actief, maar kan geen HTTP-antwoord retourneren. Voor langlopende functies raden we u aan om asyntische patronen te volgen en een locatie te retourneren waar u de status van de aanvraag kunt pingen. Zie Schalen en hosten - Verbruiksplanvoor meer informatie over hoe lang een functie kan worden uitgevoerd.