Übersicht über HTTP-Trigger und -Bindungen in Azure Functions
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 in den Premium- und Dedizierten Plänen 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 :
|
||||||||||
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 für die Pläne Premium und Dedicated ist ungebunden ( -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 für die Pläne Premium und Dedicated ist ungebunden ( -1 ). |
||||||||||
routePrefix | api | Das Routenpräfix, das für alle Routen gilt. Verwenden Sie eine leere Zeichenfolge, um das Standardpräfix zu entfernen. |