Freigeben über

HTTP-Trigger in Azure Functions

  • Artikel

Mit dem HTTP-Trigger können Sie eine Funktion mit einer HTTP-Anforderung aufrufen. Sie können einen HTTP-Trigger zum Erstellen von serverlosen APIs und zum Antworten auf Webhooks verwenden.

Der Standardrückgabewert für eine HTTP-ausgelöste Funktion ist:

  • HTTP 204 No Content bei leerem Hauptteil in Functions 2.x und höher
  • HTTP 200 OK bei leerem Hauptteil in Functions 1.x

Um die HTTP-Antwort zu ändern, konfigurieren Sie eine Ausgabebindung.

Weitere Informationen zu HTTP-Bindungen finden Sie in der Übersicht und Referenz für die Ausgabebindung.

Tipp

Wenn Sie die HTTP- oder WebHook-Bindungen verwenden möchten, vermeiden Sie die Portauslastung, die durch nicht ordnungsgemäße Instanziierung von HttpClient verursacht werden kann. Weitere Informationen finden Sie unter How to manage connections in Azure Functions (Verwalten von Verbindungen in Azure Functions).

Wichtig

In diesem Artikel werden Registerkarten verwendet, um mehrere Versionen des Node.js-Programmiermodells zu unterstützen. Das v4-Modell ist allgemein verfügbar und bietet JavaScript- und TypeScript-Entwicklern eine flexiblere und intuitivere Erfahrung. Weitere Informationen zur Funktionsweise des v4-Modells finden Sie im Azure Functions Node.js-Entwicklerhandbuch. Weitere Informationen zu den Unterschieden zwischen v3 und v4 finden Sie im Migrationshandbuch.

Azure Functions unterstützt zwei Programmiermodelle für Python. Wie Sie Ihre Bindung definieren, hängt vom gewählten Python-Programmiermodell ab.

Mit dem Python v2-Programmiermodell können Sie Bindungen mithilfe von Decorators direkt im Python-Funktionscode definieren. Weitere Informationen finden Sie im Python Developer-Leitfaden.

In diesem Artikel werden beide Programmiermodelle unterstützt.

Beispiel

Eine C#-Funktion kann mit einem der folgenden C#-Modi erstellt werden:

  • Isoliertes Workermodell: Kompilierte C#-Funktion, die in einem Workerprozess ausgeführt wird, der von der Runtime isoliert ist. Ein isolierter Workerprozess ist erforderlich, um C#-Funktionen zu unterstützen, die in LTS- und Nicht-LTS-Versionen von .NET und .NET Framework ausgeführt werden. Erweiterungen für isolierte Workerprozessfunktionen verwenden Microsoft.Azure.Functions.Worker.Extensions.*-Namespaces.
  • In-Process-Modell: Kompilierte C#-Funktion, die im gleichen Prozess wie die Functions-Runtime ausgeführt wird. In einer Variante dieses Modells kann Functions mithilfe von C#-Skripts ausgeführt werden. Dies wird hauptsächlich für die Bearbeitung im C#-Portal unterstützt. Erweiterungen für In-Process-Funktionen verwenden Microsoft.Azure.WebJobs.Extensions.*-Namespaces.

Wichtig

Die Unterstützung für das In-Process-Modell endet am 10. November 2026. Es wird dringend empfohlen, Ihre Apps zum isolierten Workermodell zu migrieren, um den vollständigen Support zu ermöglichen.

Der Code in diesem Artikel nutzt standardmäßig .NET Core-Syntax, die in Functions ab Version 2.x verwendet wird. Informationen zur 1.x-Syntax finden Sie in den 1.x-Functions-Vorlagen.

Das folgende Beispiel zeigt einen HTTP-Trigger, der die Antwort „hello, world“ als IActionResult zurückgibt, wobei ASP.NET Core Integration in .NET Isolated verwendet wird:

[Function("HttpFunction")]
public IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req)
{
    return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
}

Das folgende Beispiel zeigt einen HTTP-Trigger, der eine „hello world“-Antwort als HttpResponseData-Objekt zurückgibt:

[Function(nameof(HttpFunction))]
public static HttpResponseData Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequestData req,
    FunctionContext executionContext)
{
    var logger = executionContext.GetLogger(nameof(HttpFunction));
    logger.LogInformation("message logged");

    var response = req.CreateResponse(HttpStatusCode.OK);
    response.Headers.Add("Content-Type", "text/plain; charset=utf-8");
    response.WriteString("Welcome to .NET isolated worker !!");

    return response;
}

Dieser Abschnitt enthält folgende Beispiele:

In den folgenden Beispielen wird die HTTP-Triggerbindung veranschaulicht.

Lesen eines Parameters aus der Abfragezeichenfolge

Dieses Beispiel liest einen Parameter namens id aus der Abfragezeichenfolge und verwendet ihn zum Erstellen eines JSON-Dokuments mit dem Inhaltstyp application/json, das an den Client zurückgegeben wird.

@FunctionName("TriggerStringGet")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", 
            methods = {HttpMethod.GET}, 
            authLevel = AuthorizationLevel.ANONYMOUS)
        HttpRequestMessage<Optional<String>> request,
        final ExecutionContext context) {

    // Item list
    context.getLogger().info("GET parameters are: " + request.getQueryParameters());

    // Get named parameter
    String id = request.getQueryParameters().getOrDefault("id", "");

    // Convert and display
    if (id.isEmpty()) {
        return request.createResponseBuilder(HttpStatus.BAD_REQUEST)
                        .body("Document not found.")
                        .build();
    } 
    else {
        // return JSON from to the client
        // Generate document
        final String name = "fake_name";
        final String jsonDocument = "{\"id\":\"" + id + "\", " + 
                                        "\"description\": \"" + name + "\"}";
        return request.createResponseBuilder(HttpStatus.OK)
                        .header("Content-Type", "application/json")
                        .body(jsonDocument)
                        .build();
    }
}

Lesen des Hauptteils aus einer POST-Anforderung

Dieses Beispiel liest den Hauptteil einer POST-Anforderung als String und verwendet ihn zum Erstellen eines JSON-Dokuments mit dem Inhaltstyp application/json, das an den Client zurückgegeben wird.

    @FunctionName("TriggerStringPost")
    public HttpResponseMessage run(
            @HttpTrigger(name = "req", 
              methods = {HttpMethod.POST}, 
              authLevel = AuthorizationLevel.ANONYMOUS)
            HttpRequestMessage<Optional<String>> request,
            final ExecutionContext context) {

        // Item list
        context.getLogger().info("Request body is: " + request.getBody().orElse(""));

        // Check request body
        if (!request.getBody().isPresent()) {
            return request.createResponseBuilder(HttpStatus.BAD_REQUEST)
                          .body("Document not found.")
                          .build();
        } 
        else {
            // return JSON from to the client
            // Generate document
            final String body = request.getBody().get();
            final String jsonDocument = "{\"id\":\"123456\", " + 
                                         "\"description\": \"" + body + "\"}";
            return request.createResponseBuilder(HttpStatus.OK)
                          .header("Content-Type", "application/json")
                          .body(jsonDocument)
                          .build();
        }
    }

Lesen eines Parameters aus einer Route

Dieses Beispiel liest einen obligatorischen Parameter namens id sowie einen optionalen Parameter name aus dem Routenpfad und verwendet sie zum Erstellen eines JSON-Dokuments mit dem Inhaltstyp application/json, das an den Client zurückgegeben wird.

@FunctionName("TriggerStringRoute")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", 
            methods = {HttpMethod.GET}, 
            authLevel = AuthorizationLevel.ANONYMOUS,
            route = "trigger/{id}/{name=EMPTY}") // name is optional and defaults to EMPTY
        HttpRequestMessage<Optional<String>> request,
        @BindingName("id") String id,
        @BindingName("name") String name,
        final ExecutionContext context) {

    // Item list
    context.getLogger().info("Route parameters are: " + id);

    // Convert and display
    if (id == null) {
        return request.createResponseBuilder(HttpStatus.BAD_REQUEST)
                        .body("Document not found.")
                        .build();
    } 
    else {
        // return JSON from to the client
        // Generate document
        final String jsonDocument = "{\"id\":\"" + id + "\", " + 
                                        "\"description\": \"" + name + "\"}";
        return request.createResponseBuilder(HttpStatus.OK)
                        .header("Content-Type", "application/json")
                        .body(jsonDocument)
                        .build();
    }
}

Lesen des POJO-Hauptteils aus einer POST-Anforderung

Hier ist der Code für die Klasse, auf die ToDoItem in diesem Beispiel verwiesen wird:


public class ToDoItem {

  private String id;
  private String description;  

  public ToDoItem(String id, String description) {
    this.id = id;
    this.description = description;
  }

  public String getId() {
    return id;
  }

  public String getDescription() {
    return description;
  }

  @Override
  public String toString() {
    return "ToDoItem={id=" + id + ",description=" + description + "}";
  }
}

In diesem Beispiel wird der Hauptteil einer POST-Anforderung gelesen. Der Anforderungstext wird automatisch in ein ToDoItem-Objekt deserialisiert und mit dem Inhaltstyp application/json an den Client zurückgegeben. Der Parameter ToDoItem wird durch die Functions-Runtime serialisiert, wenn er der Eigenschaft body der HttpMessageResponse.Builder-Klasse zugewiesen wird.

@FunctionName("TriggerPojoPost")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", 
            methods = {HttpMethod.POST}, 
            authLevel = AuthorizationLevel.ANONYMOUS)
        HttpRequestMessage<Optional<ToDoItem>> request,
        final ExecutionContext context) {

    // Item list
    context.getLogger().info("Request body is: " + request.getBody().orElse(null));

    // Check request body
    if (!request.getBody().isPresent()) {
        return request.createResponseBuilder(HttpStatus.BAD_REQUEST)
                        .body("Document not found.")
                        .build();
    } 
    else {
        // return JSON from to the client
        // Generate document
        final ToDoItem body = request.getBody().get();
        return request.createResponseBuilder(HttpStatus.OK)
                        .header("Content-Type", "application/json")
                        .body(body)
                        .build();
    }
}

Das folgende Beispiel zeigt eine TypeScript-Funktion für den HTTP-Trigger. Die Funktion sucht in der Abfragezeichenfolge oder im Text der HTTP-Anforderung nach einem name-Parameter.

import { app, HttpRequest, HttpResponseInit, InvocationContext } from '@azure/functions';

export async function httpTrigger1(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {
    context.log(`Http function processed request for url "${request.url}"`);

    const name = request.query.get('name') || (await request.text()) || 'world';

    return { body: `Hello, ${name}!` };
}

app.http('httpTrigger1', {
    methods: ['GET', 'POST'],
    authLevel: 'anonymous',
    handler: httpTrigger1,
});

Das folgende Beispiel zeigt eine JavaScript-Funktion für den HTTP-Trigger. Die Funktion sucht in der Abfragezeichenfolge oder im Text der HTTP-Anforderung nach einem name-Parameter.

const { app } = require('@azure/functions');

app.http('httpTrigger1', {
    methods: ['GET', 'POST'],
    authLevel: 'anonymous',
    handler: async (request, context) => {
        context.log(`Http function processed request for url "${request.url}"`);

        const name = request.query.get('name') || (await request.text()) || 'world';

        return { body: `Hello, ${name}!` };
    },
});

Das folgende Beispiel zeigt eine Triggerbindung in einer Datei function.json sowie eine PowerShell-Funktion. Die Funktion sucht in der Abfragezeichenfolge oder im Text der HTTP-Anforderung nach einem name-Parameter.

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

using namespace System.Net

# Input bindings are passed in via param block.
param($Request, $TriggerMetadata)

# Write to the Azure Functions log stream.
Write-Host "PowerShell HTTP trigger function processed a request."

# Interact with query parameters or the body of the request.
$name = $Request.Query.Name
if (-not $name) {
    $name = $Request.Body.Name
}

$body = "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."

if ($name) {
    $body = "Hello, $name. This HTTP triggered function executed successfully."
}

# Associate values to output bindings by calling 'Push-OutputBinding'.
Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [HttpStatusCode]::OK
    Body       = $body
})

In diesem Beispiel werden HTTP-Daten verwendet , um Daten zu blockierten Antworten zurückzugeben.

import time

import azure.functions as func
from azurefunctions.extensions.http.fastapi import Request, StreamingResponse

app = func.FunctionApp(http_auth_level=func.AuthLevel.ANONYMOUS)


def generate_sensor_data():
    """Generate real-time sensor data."""
    for i in range(10):
        # Simulate temperature and humidity readings
        temperature = 20 + i
        humidity = 50 + i
        yield f"data: {{'temperature': {temperature}, 'humidity': {humidity}}}\n\n"
        time.sleep(1)


@app.route(route="stream", methods=[func.HttpMethod.GET])
async def stream_sensor_data(req: Request) -> StreamingResponse:
    """Endpoint to stream real-time sensor data."""
    return StreamingResponse(generate_sensor_data(), media_type="text/event-stream")

Weitere Informationen, einschließlich der Aktivierung von HTTP-Streams in Ihrem Projekt, finden Sie unter HTTP-Streams.

Dieses Beispiel zeigt eine Triggerbindung und eine Python-Funktion, die die Bindung verwendet. Die Funktion sucht in der Abfragezeichenfolge oder im Text der HTTP-Anforderung nach einem name-Parameter.

import azure.functions as func
import logging

app = func.FunctionApp()

@app.function_name(name="HttpTrigger1")
@app.route(route="hello", auth_level=func.AuthLevel.ANONYMOUS)
def test_function(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')
    return func.HttpResponse(
        "This HTTP triggered function executed successfully.",
        status_code=200
        )

Attribute

Sowohl das isolierte Workermodell als auch das In-Process-Modell verwenden die HttpTriggerAttribute Definition der Triggerbindung. Das C#-Skript verwendet stattdessen eine Konfigurationsdatei function.json, wie im C#-Skript-Handbuch beschrieben.

In isolierten Arbeitsmodell-Funktions-Apps werden die HttpTriggerAttribute folgenden Parameter unterstützt:

Parameter BESCHREIBUNG
AuthLevel Bestimmt, welche Schlüssel (sofern erforderlich) in der Anforderung vorhanden sein müssen, um die Funktion aufzurufen. Unterstützte Werte sind unter Autorisierungsstufe aufgeführt.
Methoden Ein Array der HTTP-Methoden, auf die diese Funktion antwortet. Wird dieses Array nicht angegeben, antwortet die Funktion auf alle HTTP-Methoden. Siehe Anpassen des HTTP-Endpunkts.
Route Definiert die Routenvorlage, mit der gesteuert wird, auf welche Anforderungs-URLs die Funktion antwortet. Wenn kein anderer Wert angegeben wird, lautet der Standardwert <functionname>. Weitere Informationen finden Sie unter Anpassen des HTTP-Endpunkts.

Decorator-Elemente

Gilt nur für das Python v2-Programmiermodell.

Für Python v2-Funktionen, die mithilfe eines Decorators definiert werden, werden die folgenden Eigenschaften für einen Trigger im Decorator route definiert, der die HttpTrigger- und HttpOutput-Bindung hinzufügt:

Eigenschaft Beschreibung
route Route für den HTTP-Endpunkt. If None, it will be set to function name if present or user-defined python function name.
trigger_arg_name Argumentname für HttpRequest. Der Standardwert ist „req“.
binding_arg_name Argumentname für HttpResponse. Der Standardwert ist „$return“.
methods Ein Array der HTTP-Methoden, auf die diese Funktion antwortet.
auth_level Bestimmt, welche Schlüssel (sofern erforderlich) in der Anforderung vorhanden sein müssen, um die Funktion aufzurufen.

Informationen zu Python-Funktionen, die mithilfe von function.json definiert wurden, finden Sie im Abschnitt Konfiguration.

Anmerkungen

Verwenden Sie in der Laufzeitbibliothek für Java-Funktionen die HttpTrigger-Anmerkung, die die folgenden Einstellungen unterstützt:

Konfiguration

Gilt nur für das Python v1-Programmiermodell.

In der folgenden Tabelle werden die Eigenschaften erläutert, die Sie für das options-Objekt festlegen können, das an die app.http()-Methode übergeben wurde.

Eigenschaft Beschreibung
authLevel Bestimmt, welche Schlüssel (sofern erforderlich) in der Anforderung vorhanden sein müssen, um die Funktion aufzurufen. Unterstützte Werte sind unter Autorisierungsstufe aufgeführt.
methods Ein Array der HTTP-Methoden, auf die diese Funktion antwortet. Wird dieses Array nicht angegeben, antwortet die Funktion auf alle HTTP-Methoden. Siehe Anpassen des HTTP-Endpunkts.
route Definiert die Routenvorlage, mit der gesteuert wird, auf welche Anforderungs-URLs die Funktion antwortet. Wenn kein anderer Wert angegeben wird, lautet der Standardwert <functionname>. Weitere Informationen finden Sie unter Anpassen des HTTP-Endpunkts.

Die folgende Tabelle gibt Aufschluss über die Triggerkonfigurationseigenschaften, die Sie in der Datei function.json festlegen (unterscheidet sich je nach Runtimeversion).

Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.

function.json-Eigenschaft BESCHREIBUNG
type Erforderlich – muss auf httpTrigger festgelegt sein.
direction Erforderlich – muss auf in festgelegt sein.
name Erforderlich – der Variablenname, der im Funktionscode für die Anforderung oder den Anforderungstext verwendet wird.
authLevel Bestimmt, welche Schlüssel (sofern erforderlich) in der Anforderung vorhanden sein müssen, um die Funktion aufzurufen. Unterstützte Werte sind unter Autorisierungsstufe aufgeführt.
methods Ein Array der HTTP-Methoden, auf die diese Funktion antwortet. Wird dieses Array nicht angegeben, antwortet die Funktion auf alle HTTP-Methoden. Siehe Anpassen des HTTP-Endpunkts.
route Definiert die Routenvorlage, mit der gesteuert wird, auf welche Anforderungs-URLs die Funktion antwortet. Wenn kein anderer Wert angegeben wird, lautet der Standardwert <functionname>. Weitere Informationen finden Sie unter Anpassen des HTTP-Endpunkts.

Verwendung

In diesem Abschnitt wird beschrieben, wie Sie Ihre HTTP-Triggerfunktionsbindung konfigurieren.

Die HttpTrigger-Anmerkung sollte auf einen Methodenparameter eines der folgenden Typen angewendet werden:

  • HttpRequestMessage<T>.
  • Alle nativen Java-Typen wie „int“, „String“, „byte[]“.
  • Nullable-Werte unter Verwendung von „Optional“.
  • Beliebige POJO-Typen (Plain-Old Java Object).

Nutzlast

Der Triggereingabetyp wird als einer der folgenden Typen deklariert:

type Beschreibung
HttpRequest Die Verwendung dieses Typs erfordert, dass die App mit ASP.NET Core Integration in .NET Isolated konfiguriert ist.
Dadurch erhalten Sie Vollzugriff auf das Anforderungsobjekt und HttpContext insgesamt.
HttpRequestData Eine Projektion des Anforderungsobjekts.
Ein benutzerdefinierter Typ Wenn der Textkörper der Anforderung JSON ist, versucht die Laufzeit, sie zu analysieren, um die Objekteigenschaften festzulegen.

Wenn der Triggerparameter vom Typ oder HttpRequestData HttpRequest, benutzerdefinierte Typen kann auch an andere Parameter gebunden werden.Microsoft.Azure.Functions.Worker.Http.FromBodyAttribute Die Verwendung dieses Attributs erfordert Microsoft.Azure.Functions.Worker.Extensions.Http Version 3.1.0 oder höher. Dies ist ein anderer Typ als das ähnliche Attribut in Microsoft.AspNetCore.Mvc. Wenn Sie ASP.NET Core-Integration verwenden, benötigen Sie einen vollqualifizierten Verweis oder using eine vollqualifizierte Anweisung. In diesem Beispiel wird gezeigt, wie Sie das Attribut verwenden, um nur den Textinhalt abzurufen und gleichzeitig Zugriff auf den vollständigen HttpRequestInhalt zu haben, indem ASP.NET Core-Integration verwendet wird:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using FromBodyAttribute = Microsoft.Azure.Functions.Worker.Http.FromBodyAttribute;

namespace AspNetIntegration
{
    public class BodyBindingHttpTrigger
    {
        [Function(nameof(BodyBindingHttpTrigger))]
        public IActionResult Run([HttpTrigger(AuthorizationLevel.Anonymous, "post")] HttpRequest req,
            [FromBody] Person person)
        {
            return new OkObjectResult(person);
        }
    }

    public record Person(string Name, int Age);
}

Anpassen des HTTP-Endpunkts

Wenn Sie eine Funktion für einen HTTP-Trigger erstellen, ist die Funktion mit einer Route der folgenden Form erreichbar:

https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>

Sie können diese Route mit der optionalen route-Eigenschaft in der Eingabebindung des HTTP-Triggers anpassen. Sie können für Ihre Parameter eine beliebige Web-API-Routeneinschränkung verwenden.

Der folgende Funktionscode akzeptiert die beiden Parameter category und id in der Route und schreibt eine Antwort unter Verwendung dieser beiden Parameter.

[Function("HttpTrigger1")]
public static HttpResponseData Run([HttpTrigger(AuthorizationLevel.Function, "get", "post",
Route = "products/{category:alpha}/{id:int?}")] HttpRequestData req, string category, int? id,
FunctionContext executionContext)
{
    var logger = executionContext.GetLogger("HttpTrigger1");
    logger.LogInformation("C# HTTP trigger function processed a request.");

    var message = String.Format($"Category: {category}, ID: {id}");
    var response = req.CreateResponse(HttpStatusCode.OK);
    response.Headers.Add("Content-Type", "text/plain; charset=utf-8");
    response.WriteString(message);

    return response;
}

Routenparameter werden mithilfe der route-Einstellung der HttpTrigger-Anmerkung definiert. Der folgende Funktionscode akzeptiert die beiden Parameter category und id in der Route und schreibt eine Antwort unter Verwendung dieser beiden Parameter.

package com.function;

import java.util.*;
import com.microsoft.azure.functions.annotation.*;
import com.microsoft.azure.functions.*;

public class HttpTriggerJava {
    public HttpResponseMessage<String> HttpTrigger(
            @HttpTrigger(name = "req",
                         methods = {"get"},
                         authLevel = AuthorizationLevel.FUNCTION,
                         route = "products/{category:alpha}/{id:int}") HttpRequestMessage<String> request,
            @BindingName("category") String category,
            @BindingName("id") int id,
            final ExecutionContext context) {

        String message = String.format("Category  %s, ID: %d", category, id);
        return request.createResponseBuilder(HttpStatus.OK).body(message).build();
    }
}

Der folgende TypeScript-Code definiert beispielsweise eine route-Eigenschaft für einen HTTP-Trigger mit den beiden Parametern category und id. Im Beispiel werden die Parameter in der Anforderung gelesen und ihre Werte in der Antwort zurückgegeben.

import { app, HttpRequest, HttpResponseInit, InvocationContext } from '@azure/functions';

export async function httpTrigger1(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {
    const category = request.params.category;
    const id = request.params.id;

    return { body: `Category: ${category}, ID: ${id}` };
}

app.http('httpTrigger1', {
    methods: ['GET'],
    authLevel: 'anonymous',
    route: 'products/{category:alpha}/{id:int?}',
    handler: httpTrigger1,
});

Der folgende JavaScript-Code definiert beispielsweise eine route-Eigenschaft für einen HTTP-Trigger mit den beiden Parametern category und id. Im Beispiel werden die Parameter in der Anforderung gelesen und ihre Werte in der Antwort zurückgegeben.

const { app } = require('@azure/functions');

app.http('httpTrigger1', {
    methods: ['GET'],
    authLevel: 'anonymous',
    route: 'products/{category:alpha}/{id:int?}',
    handler: async (request, context) => {
        const category = request.params.category;
        const id = request.params.id;

        return { body: `Category: ${category}, ID: ${id}` };
    },
});

Der folgende Code definiert beispielsweise eine route-Eigenschaft für einen HTTP-Trigger mit den beiden Parametern category und id:

@app.function_name(name="httpTrigger")
@app.route(route="products/{category:alpha}/{id:int?}")

Routenparameter, die in der Datei function.json deklariert werden, sind als Eigenschaft des $Request.Params-Objekts zugänglich.

$Category = $Request.Params.category
$Id = $Request.Params.id

$Message = "Category:" + $Category + ", ID: " + $Id

Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [HttpStatusCode]::OK
    Body = $Message
})

Der Funktionsausführungskontext wird über einen als func.HttpRequest deklarierten Parameter bereitgestellt. Diese Instanz ermöglicht einer Funktion den Zugriff auf Datenroutenparameter, Abfragezeichenfolgenwerte und Methoden, mit denen Sie HTTP-Antworten zurückgeben können.

Nach der Definition sind die Routenparameter für die Funktion verfügbar, indem die route_params-Methode aufgerufen wird.

import logging

import azure.functions as func

def main(req: func.HttpRequest) -> func.HttpResponse:

    category = req.route_params.get('category')
    id = req.route_params.get('id')
    message = f"Category: {category}, ID: {id}"

    return func.HttpResponse(message)

Mit dieser Konfiguration ist die Funktion jetzt über die folgende Route erreichbar, anstatt über die ursprüngliche Route.

https://<APP_NAME>.azurewebsites.net/api/products/electronics/357

Diese Konfiguration ermöglicht es dem Funktionscode, zwei Parameter in der Adresse, Kategorie und ID zu unterstützen. Weitere Informationen dazu, wie Routenparameter in einer URL mit einem Token versehen werden, finden Sie unter Routing in ASP.NET Core.

Standardmäßig werden alle Funktionsrouten mit dem Präfix " api. Sie können das Präfix auch mit der extensions.http.routePrefix-Eigenschaft in der Datei extensions.http.routePrefix anpassen oder entfernen. Im folgenden Beispiel wird das api Routenpräfix mithilfe einer leeren Zeichenfolge für das Präfix in der datei host.json entfernt.

{
    "extensions": {
        "http": {
            "routePrefix": ""
        }
    }
}

Verwenden von Routenparametern

Routenparameter, die das Muster route einer Funktion definiert haben, sind für jede Bindung verfügbar. Wenn Sie beispielsweise eine Route als "route": "products/{id}" definiert haben, kann eine Tabellenspeicherbindung den Wert des Parameters {id} in der Bindungskonfiguration verwenden.

Die folgende Konfiguration zeigt, wie der Parameter {id} an das rowKey-Element der Bindung übergeben wird:

@app.table_input(arg_name="product", table_name="products", 
                 row_key="{id}", partition_key="products",
                 connection="AzureWebJobsStorage")

import { app, HttpRequest, HttpResponseInit, input, InvocationContext } from '@azure/functions';

const tableInput = input.table({
    connection: 'MyStorageConnectionAppSetting',
    partitionKey: 'products',
    tableName: 'products',
    rowKey: '{id}',
});

export async function httpTrigger1(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {
    return { jsonBody: context.extraInputs.get(tableInput) };
}

app.http('httpTrigger1', {
    methods: ['GET'],
    authLevel: 'anonymous',
    route: 'products/{id}',
    extraInputs: [tableInput],
    handler: httpTrigger1,
});

const { app, input } = require('@azure/functions');

const tableInput = input.table({
    connection: 'MyStorageConnectionAppSetting',
    partitionKey: 'products',
    tableName: 'products',
    rowKey: '{id}',
});

app.http('httpTrigger1', {
    methods: ['GET'],
    authLevel: 'anonymous',
    route: 'products/{id}',
    extraInputs: [tableInput],
    handler: async (request, context) => {
        return { jsonBody: context.extraInputs.get(tableInput) };
    },
});

{
    "type": "table",
    "direction": "in",
    "name": "product",
    "partitionKey": "products",
    "tableName": "products",
    "rowKey": "{id}"
}

Wenn Sie Routenparameter verwenden, wird automatisch eine invoke_URL_template für Ihre Funktion erstellt. Die Clients können die URL-Vorlage verwenden, um zu wissen, welche Parameter sie beim Aufrufen Ihrer Funktion an die URL übergeben müssen. Navigieren Sie im Azure-Portal zu einer der durch HTTP ausgelösten Funktionen, und wählen Sie Funktions-URL abrufen aus.

Sie können programmgesteuert auf die invoke_URL_template zugreifen, indem Sie die Azure Resource Manager-APIs invoke_URL_template oder Funktionen abrufen verwenden.

HTTP-Datenströme

Sie können jetzt Anforderungen an und Antworten von Ihrem HTTP-Endpunkt in Node.js v4-Funktions-Apps streamen. Weitere Informationen finden Sie unter HTTP-Streams.

HTTP-Datenströme

Mit der UNTERSTÜTZUNG von HTTP-Streams in Python können Sie Daten von Ihren HTTP-Endpunkten mithilfe von FastAPI-Anforderungs- und Antwort-APIs akzeptieren und zurückgeben, die in Ihren Funktionen aktiviert sind. Diese APIs ermöglichen es dem Host, Daten in HTTP-Nachrichten als Blöcke zu verarbeiten, anstatt eine gesamte Nachricht in den Arbeitsspeicher zu lesen. Weitere Informationen finden Sie unter HTTP-Streams in Python

Wichtig

DIE HTTP-Streams-Unterstützung für Python befindet sich derzeit in der Vorschau und wird nur für das Python v2-Programmiermodell unterstützt.

Arbeiten mit Clientidentitäten

Wenn Ihre Funktions-App App Service-Authentifizierung/-Autorisierung verwendet, können Sie Informationen über authentifizierte Clients aus Ihrem Code anzeigen. Diese Informationen sind als von der Plattform eingefügter Anforderungsheader verfügbar.

Sie können diese Informationen auch aus Datenbindungen auslesen.

Hinweis

Der Zugriff auf authentifizierte Clientinformationen ist derzeit nur für .NET-Sprachen verfügbar. Sie wird auch in Version 1.x der Funktionslaufzeit nicht unterstützt.

Informationen zu authentifizierten Clients sind als ClaimsPrincipal verfügbar, der als Teil des Anforderungskontexts verfügbar ist, wie im folgenden Beispiel gezeigt:

Der authentifizierte Benutzer ist über HTTP-Header verfügbar.

Der authentifizierte Benutzer ist über HTTP-Header verfügbar.

Autorisierungsstufe

Die Autorisierungsstufe ist ein Zeichenfolgenwert, der die Art des Autorisierungsschlüssels angibt, der für den Zugriff auf den Funktionsendpunkt erforderlich ist. Für eine durch HTTP ausgelöste Funktion kann die Autorisierungsstufe einen der folgenden Werte aufweisen:

Level-Wert BESCHREIBUNG
anonymous Es ist keine Zugriffstaste erforderlich.
function Für den Zugriff auf den Endpunkt ist ein funktionsspezifischer Schlüssel erforderlich.
admin Der Hauptschlüssel ist erforderlich, um auf den Endpunkt zuzugreifen.

Wenn eine Ebene nicht explizit festgelegt ist, wird die Autorisierung standardmäßig auf der function Ebene festgelegt.

Wenn eine Ebene nicht explizit festgelegt wird, hängt die Standardautorisierung von der Version des Node.js Modells ab:

Die Autorisierung wird standardmäßig auf der anonymous Ebene festgelegt.

Funktionszugriffsschlüssel

Mithilfe von Funktionen können Sie Zugriffstasten verwenden, um den Zugriff auf Ihre Funktionsendpunkte zu erschweren. Sofern die Autorisierungsstufe für eine ausgelöste HTTP-Funktion nicht festgelegt anonymousist, müssen Anforderungen einen Zugriffsschlüssel in der Anforderung enthalten. Weitere Informationen finden Sie unter Arbeiten mit Zugriffsschüsseln in Azure Functions.

Zugriffstastenautorisierung

Die meisten HTTP-Triggervorlagen erfordern einen Zugriffsschlüssel in der Anforderung. Ihre HTTP-Anforderung sieht daher normalerweise wie folgende URL aus:

https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?code=<API_KEY>

Der Schlüssel kann wie bereits erwähnt in eine Abfragezeichenfolgenvariable mit dem Namen codeeingeschlossen werden. Er kann auch in einem x-functions-key-HTTP-Header enthalten sein. Der Wert des Schlüssels kann ein beliebiger für die Funktion definierter Funktionsschlüssel oder ein beliebiger Hostschlüssel sein.

Sie können anonyme Anforderungen zulassen, für die keine Schlüssel erforderlich sind. Sie können auch anfordern, dass der Hauptschlüssel verwendet wird. Zum Ändern der Standardautorisierungsstufe verwenden Sie die authLevel-Eigenschaft in der Bindungs-JSON.

Hinweis

Beim lokalen Ausführen von Funktionen ist die Autorisierung unabhängig von der festgelegten Autorisierungsebene deaktiviert. Die authLevel-Einstellung in Ihrem Trigger wird nach der Veröffentlichung in Azure angewendet. Schlüssel sind auch bei lokaler Ausführung in einem Container weiterhin erforderlich.

webhooks

Hinweis

Der Webhookmodus ist nur für die Version 1.x der Functions-Laufzeit verfügbar. Diese Änderung wurde vorgenommen, um die Leistung von HTTP-Triggern in Version 2.x und höheren Versionen zu verbessern.

In Version 1.x bieten Webhook-Vorlagen eine weitere Überprüfung für Webhook-Nutzlasten. In Version 2.x und höheren Versionen kann der HTTP-Basistrigger weiterhin verwendet werden. Zudem wird er für Webhooks empfohlen.

WebHook-Typ

Die Bindungseigenschaft webHookType gibt den Typ an, wenn die Funktion Webhooks unterstützt. Dieser Wert gibt auch die unterstützte Payload vor. Der Webhooktyp kann folgende Werte annehmen:

Typwert Beschreibung
genericJson Ein allgemeiner Webhookendpunkt ohne Logik für einen bestimmten Anbieter. Diese Einstellung beschränkt Anforderungen auf solche, die HTTP POST verwenden und den Inhaltstyp application/json aufweisen.
github Die Funktion antwortet auf GitHub-Webhooks. Verwenden Sie die authLevel-Eigenschaft nicht mit GitHub-Webhooks.
slack Die Funktion antwortet auf Slack-Webhooks. Verwenden Sie die authLevel-Eigenschaft nicht mit Slack-Webhooks.

Bei Festlegung der webHookType-Eigenschaft darf die methods-Eigenschaft nicht ebenfalls für die Bindung festgelegt werden.

GitHub-Webhooks

Erstellen Sie zum Antworten auf GitHub-Webhooks zuerst eine Funktion mit einem HTTP-Trigger, und legen Sie die webHookType-Eigenschaft auf github fest. Kopieren Sie dann die URL und den API-Schlüssel auf die Seite Webhook hinzufügen Ihres GitHub-Repositorys.

Screenshot: Hinzufügen eines Webhooks für Ihre Funktion

Slack-Webhooks

Der Slack-Webhook lässt Sie das Token nicht angeben, sondern generiert es für Sie. Daher müssen Sie einen funktionsspezifischen Schlüssel mit dem Token aus Slack konfigurieren. Weitere Informationen finden Sie unter Autorisierungsschlüssel.

Webhooks und Schlüssel

Die Webhookautorisierung wird von der Empfangskomponente für Webhooks verarbeitet, die zum HTTP-Trigger gehört. Der Mechanismus variiert je nach Webhooktyp. Für jeden Mechanismus wird ein Schlüssel benötigt. Standardmäßig wird der Funktionsschlüssel namens „default“ verwendet. Um einen anderen Schlüssel zu verwenden, konfigurieren Sie den Webhookanbieter, sodass der Schlüsselname auf eine der folgenden Arten mit der Anforderung gesendet wird:

  • Abfragezeichenfolge: Der Anbieter übergibt den Schlüsselnamen im clientid-Abfragezeichenfolgenparameter, z. B. https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>.
  • Anforderungsheader: Der Anbieter übergibt den Schlüsselnamen im x-functions-clientid-Header.

Inhaltstypen

Bei der Übergabe von Binär- und Formulardaten an eine C#-fremde Funktion muss der passende Content-Type-Header verwendet werden. Zu den unterstützten Inhaltstypen zählt octet-stream für Binärdaten und octet-stream.

Bekannte Probleme

In C#-fremden Funktionen wird bei Anforderungen, die mit dem Inhaltstyp image/jpeg gesendet werden, ein Wert vom Typ string an die Funktion übergeben. In einem solchen Fall können Sie den Wert vom Typ string manuell in ein Bytearray konvertieren, um auf die unformatierten Binärdaten zuzugreifen.

Einschränkungen

Die Länge der HTTP-Anforderung ist auf 100 MB (104.857.600 Bytes) und die URL-Länge auf 4 KB (4.096 Bytes) beschränkt. Diese Grenzwerte werden durch das httpRuntime-Element der Datei httpRuntime der Runtime angegeben.

Wenn eine Funktion, die den HTTP-Trigger verwendet, nicht innerhalb von etwa 230 Sekunden abgeschlossen ist, tritt bei Azure Load Balancer ein Timeout auf, und es wird ein HTTP 502-Fehler zurückgegeben. Die Funktion wird weiterhin ausgeführt, kann aber keine HTTP-Antwort zurückgeben. Bei Funktionen mit langer Ausführungsdauer empfiehlt es sich, asynchrone Muster zu befolgen und einen Speicherort zurückzugeben, von dem aus Sie den Status der Anforderung pingen können. Informationen dazu, wie lang eine Funktion ausgeführt werden kann, finden Sie unter Skalierung und Hosting – Verbrauchsplan.

Nächste Schritte