Übersicht über HTTP-Trigger und -Bindungen in Azure Functions

  • Artikel

Azure Functions kann mittels HTTP-Anforderungen aufgerufen werden, um serverlose APIs zu erstellen und auf Webhooks zu antworten.

Aktion type
Ausführen einer Funktion aus einer HTTP-Anforderung Trigger
Zurückgeben einer HTTP-Antwort von einer Funktion Ausgabebindung

Installieren der Erweiterung

Das NuGet-Erweiterungspaket, das Sie installieren, hängt vom C#-Modus ab, den Sie in Ihrer Funktions-App verwenden:

Funktionen werden in einem isolierten C#-Workerprozess ausgeführt. Weitere Informationen finden Sie im Leitfaden zum Ausführen von Azure Functions (C#) in einem isolierten Workerprozess.

Die Funktionalität der Erweiterung ist abhängig von der Erweiterungsversion unterschiedlich:

Fügen Sie Ihrem Projekt die Erweiterung hinzu, indem Sie Version 3.x des NuGet-Pakets installieren.

Hinweis

Ein zusätzliches Erweiterungspaket ist für ASP.NET Core Integration in .NET Isolated erforderlich

Installieren des Pakets

Ab Functions Version 2.x ist die HTTP-Erweiterung Teil eines Erweiterungspakets, das in Ihrer Projektdatei „host.json“ angegeben wird. Weitere Informationen finden Sie unter Erweiterungspakete.

Diese Version der Erweiterung sollte bereits für Ihre Funktions-App mit dem Erweiterungspaket, Version 2.x, verfügbar sein.

Einstellungen für „host.json“

In diesem Abschnitt werden die für diese Bindung verfügbaren Konfigurationseinstellungen in Version 2.x und höher beschrieben. Einstellungen in der Datei „host.json“ gelten für alle Funktionen in einer Funktions-App-Instanz. Die nachfolgende Beispieldatei „host.json“ enthält nur die Einstellungen für Version 2.x und höhere Versionen für diese Bindung. Weitere Informationen zu den Konfigurationseinstellungen für Funktions-Apps in Version 2.x und höher finden Sie unter host.json-Referenz für Azure Functions.

Hinweis

Eine Referenz für „host.json“ in Functions 1.x finden Sie unter host.json-Referenz für Azure Functions 1.x.

{
    "extensions": {
        "http": {
            "routePrefix": "api",
            "maxOutstandingRequests": 200,
            "maxConcurrentRequests": 100,
            "dynamicThrottlesEnabled": true,
            "hsts": {
                "isEnabled": true,
                "maxAge": "10"
            },
            "customHeaders": {
                "X-Content-Type-Options": "nosniff"
            }
        }
    }
}
Eigenschaft Standard BESCHREIBUNG
customHeaders Keine Ermöglicht das Festlegen benutzerdefinierter Header in der HTTP-Antwort. Im vorherigen Beispiel wird der Antwort der X-Content-Type-Options-Header hinzugefügt, um die Inhaltstypermittlung zu vermeiden. Dieser benutzerdefinierte Header gilt für alle über HTTP ausgelösten Funktionen in der Funktions-App.
dynamicThrottlesEnabled true* Bei einer Aktivierung dieser Einstellung überprüft die Pipeline zur Anforderungsverarbeitung regelmäßig Leistungsindikatoren zur Systemleistung wie connections/threads/processes/memory/cpu/etc, und wenn einer dieser Leistungsindikatoren einen integrierten Schwellenwert (80 %) übersteigt, werden Anforderungen mit der Antwort 429 "Too Busy" zurückgewiesen, bis die Leistungsindikatoren wieder ein normales Niveau erreichen.
*Der Standardwert in einem Verbrauchstarif ist true. Der Standardwert im Tarif „Dedicated“ ist false.
hsts Nicht aktiviert Wenn isEnabled auf true festgelegt ist, wird das HSTS-Verhalten (HTTP Strict Transport Security) von .NET Core erzwungen, wie in der HstsOptions-Klasse definiert. Das Beispiel oben legt außerdem die maxAge-Eigenschaft auf 10 Tage fest. Unterstützte Eigenschaften von hsts :
EigenschaftBESCHREIBUNG
excludedHostsEin Zeichenfolgenarray mit Hostnamen, für die der HSTS-Header nicht hinzugefügt wird.
includeSubDomainsBoolescher Wert, der angibt, ob der „includeSubDomain“-Parameter des „Strict-Transport-Security“-Headers aktiviert wurde.
maxAgeEine Zeichenfolge, die den „max-age“-Parameter des „Strict-Transport-Security“-Headers definiert.
preloadBoolescher Wert, der angibt, ob der „preload“-Parameter des „Strict-Transport-Security“-Headers aktiviert ist.
maxConcurrentRequests 100* Die maximale Anzahl von HTTP-Funktionen, die parallel ausgeführt werden. Mit diesem Wert können Sie die Parallelität steuern und somit die Verwaltung der Ressourcenverwendung vereinfachen. Beispielsweise könnten Sie über eine HTTP-Funktion verfügen, die eine große Zahl von Systemressourcen (Speicher/CPU/Sockets) verbraucht und daher Probleme verursacht, wenn die Parallelität zu hoch ist. Oder eine Funktion führt ausgehende Anforderungen an einen Dienst eines Drittanbieters durch, und die Rate dieser Aufrufe muss eingeschränkt werden. In diesen Fällen kann eine Drosselung hilfreich sein.
*Der Standardwert für einen Verbrauchstarif ist 100. Der Standardwert im Tarif „Dedicated“ ist unbegrenzt (-1).
maxOutstandingRequests 200* Die maximale Anzahl ausstehender Anforderungen, die zu einem beliebigen Zeitpunkt gespeichert werden. Dieser Grenzwert umfasst Anforderungen in der Warteschlange, deren Ausführung aber noch nicht gestartet ist, sowie alle laufenden Ausführungen. Alle eingehenden Anforderungen über diesem Grenzwert werden mit der Antwort 429 „Ausgelastet“ zurückgewiesen. Das ermöglicht es dem Aufrufer zeitbasierte Strategien für Wiederholungsversuche einzusetzen, und Sie erhalten damit die Möglichkeit, die maximalen Wartezeiten für Anforderungen zu steuern. Damit wird nur das Queuing gesteuert, das innerhalb des Ausführungspfads des Skripthosts auftritt. Andere Warteschlangen, z.B. die ASP.NET-Anforderungswarteschlange, sind von dieser Einstellung nicht betroffen und werden weiterhin verwendet.
*Der Standardwert für einen Verbrauchstarif ist 200. Der Standardwert im Tarif „Dedicated“ ist unbegrenzt (-1).
routePrefix api Das Routenpräfix, das für alle Routen gilt. Verwenden Sie eine leere Zeichenfolge, um das Standardpräfix zu entfernen.

Nächste Schritte