Azure REST API-Referenz

Willkommen bei der Referenzdokumentation zur Azure REST-API.

REST-APIs (Representational State Transfer) sind Dienstendpunkte, die verschiedene HTTP-Vorgänge (Methoden) für den Zugriff auf Dienstressourcen zum Erstellen, Abrufen, Aktualisieren oder Löschen unterstützen. In diesem Artikel wird Folgendes beschrieben:

• Aufrufen von Azure REST-APIs mit curl
• Die grundlegenden Komponenten eines REST-API-Anforderungs-Antwort-Paares.
• So registrieren Sie Ihre Clientanwendung bei Microsoft Entra ID, um Ihre REST-Anforderungen zu schützen.
• Übersicht über das Erstellen und Senden einer REST-Anforderung und die Behandlung der Antwort.

Tipp

Die meisten Azure-Dienst-REST-APIs verfügen über Clientbibliotheken, die eine native Schnittstelle für die Verwendung von Azure-Diensten bereitstellen:

.NETTO | Java | | Node.jsPython | Gehen | C++

Aufrufen von Azure REST-APIs mit curl

Der im folgenden Blogbeitrag beschriebene Prozess zeigt, wie Sie eine Azure REST-API mithilfe von curl aufrufen. Sie können curl in unbeaufsichtigten Skripts verwenden. Beispiel: In DevOps-Automatisierungsszenarien.

Aufrufen der Azure REST-API über curl

Komponenten einer REST-API-Anforderung/Antwort

Ein REST-API-Anforderung/Antwort-Paar kann in fünf Komponenten gegliedert werden:

1. Der Anforderungs-URI, der aus {URI-scheme} :// {URI-host} / {resource-path} ? {query-string} besteht. Obwohl der Header der Anforderungsnachricht den Anforderungs-URI enthält, erwähnen wir ihn an dieser Stelle extra, da es für viele Sprachen und Frameworks erforderlich ist, diesen separat der Anforderungsnachricht zu entnehmen.

   • URI-Schema: gibt das Protokoll an, das zum Übertragen der Anforderung verwendet wird. Zum Beispiel: http oder https.
   • URI-Host: gibt den Domänennamen oder die IP-Adresse des Servers an, auf dem die REST-Dienstendpunkte gehostet werden. Zum Beispiel: graph.microsoft.com.
   • Ressourcenpfad: gibt die Ressource oder die Ressourcenauflistung an, die möglicherweise mehrere Segmente enthalten, die vom Dienst zur Bestimmung der Auswahl dieser Ressourcen verwendet werden. Beispiel: beta/applications/00003f25-7e1f-4278-9488-efc7bac53c4a/owners kann verwendet werden, um die Liste der Besitzer einer bestimmten Anwendung innerhalb der Anwendungensammlung abzufragen.
   • Abfragezeichenfolge (optional): stellt zusätzliche, einfache Parameter wie die API-Version oder die Kriterien der Ressourcenauswahl bereit.

2. Headerfelder für HTTP-Anforderungsnachrichten:

   • Eine erforderliche HTTP-Methode (auch als Vorgang oder Verb bezeichnet), die dem Dienst mitteilt, welche Art von Vorgang Sie anfordern. Azure REST-APIs unterstützen die Methoden GET, HEAD, PUT, POST und PATCH.
   • Zusätzliche optionale Headerfelder, die für den angegebenen URI und HTTP-Methode erforderlich sind. Beispielsweise ein Autorisierungsheader, der ein Bearertoken mit Clientautorisierungsinformationen für die Anforderung bereitstellt.

3. Optionale Nachrichtentextfelder mit HTTP-Antworten zur Unterstützung des URI und des HTTP-Vorgangs. Beispielsweise enthalten POST-Vorgänge MIME-codierte Objekte, die als komplexe Parameter übergeben werden. Für POST- oder PUT-Vorgänge sollte der MIME-codierte Textkörpertyp ebenfalls im Anforderungsheader Content-type angegeben werden. Einige Dienste verlangen die Verwendung eines MIME-Typs wie application/json.

4. Nachrichtenheaderfelder mit HTTP-Anworten:

   • Ein HTTP-Statuscode, der zwischen den Erfolgscodes 2xx und den Fehlercodes 4xx oder 5xx liegt. Stattdessen kann auch, wie in der API-Dokumentation angegeben, ein Statuscode zurückgegeben werden, der für einen Dienst definiert ist.
   • Zusätzliche optionale Headerfelder, die zum Unterstützen der Antwort der Anforderung erforderlich sind, z.B. ein Content-type-Antwortheader.

5. Optionale Nachrichtentextfelder mit HTTP-Antworten:

   • MIME-codierte Antwortobjekte werden im HTTP-Antworttext zurückgegeben, wie z.B. eine Antwort von einer GET-Methode, die Daten zurückgibt. Für gewöhnlich werden diese Objekte in einem strukturierten Format wie JSON oder XML zurückgegeben, wie im Content-type-Antwortheader angegeben. Wenn Sie beispielsweise ein Zugriffstoken von Microsoft Entra ID anfordern, wird es im Antworttext als access_token Element zurückgegeben, eines von mehreren namens-Wert-gekoppelten Objekten in einer Datensammlung. In diesem Beispiel ist auch ein Antwortheader von Content-Type: application/json enthalten.

Registrieren Ihrer Clientanwendung bei Microsoft Entra ID

Für die meisten Azure-Dienste (z. B. Azure Resource Manager-Anbieter und das klassische Bereitstellungsmodell) muss sich Ihr Clientcode mit gültigen Anmeldeinformationen authentifizieren, bevor Sie die API des Diensts aufrufen können. Die Authentifizierung wird zwischen den verschiedenen Akteuren von Microsoft Entra ID koordiniert und stellt Ihrem Client ein Zugriffstoken als Nachweis für die Authentifizierung zur Verfügung. Das Token wird dann im HTTP-Autorisierungsheader der nachfolgenden REST-API-Anforderungen an den Azure-Dienst gesendet. Die Ansprüche des Tokens stellen auch Informationen für den Dienst bereit, sodass er den Client überprüfen und alle erforderlichen Autorisierungen ausführen kann.

Wenn Sie eine REST-API verwenden, die keine integrierte Microsoft Entra-Authentifizierung verwendet, oder Wenn Sie Ihren Client bereits registriert haben, fahren Sie mit dem Abschnitt Erstellen der Anforderung fort.

Voraussetzungen

Ihre Clientanwendung muss ihre Identitätskonfiguration vor der Laufzeit Microsoft Entra ID bekannt machen, indem sie sie in einem Microsoft Entra Mandanten registriert. Bevor Sie Ihren Client bei Microsoft Entra ID registrieren, sollten Sie die folgenden Voraussetzungen berücksichtigen:

• Wenn Sie noch keinen Microsoft Entra Mandanten haben, lesen Sie Einrichten eines Microsoft Entra Mandanten.

• In Übereinstimmung mit dem OAuth2-Autorisierungsframework unterstützt Microsoft Entra ID zwei Arten von Clients. Das Verständnis der einzelnen Elemente hilft Ihnen bei der Entscheidung, welche für Ihr Szenario am besten geeignet ist:

  • Web-/vertrauliche Clients werden auf einem Webserver ausgeführt und können unter ihrer eigenen Identität auf Ressourcen zugreifen (z. B. einen Dienst oder Daemon), oder eine delegierte Autorisierung für den Zugriff auf Ressourcen unter der Identität eines angemeldeten Benutzers (z. B. eine Web-App) erhalten. Nur ein Webclient kann seine eigenen Anmeldeinformationen während Microsoft Entra Authentifizierung zum Abrufen eines Zugriffstokens sicher verwalten und präsentieren.
  • native/öffentliche Clients werden auf einem Gerät installiert und ausgeführt. Sie können nur unter delegierter Autorisierung auf Ressourcen zugreifen, indem sie die Identität des angemeldeten Benutzers verwenden, um ein Zugriffstoken im Namen des Benutzers abzurufen.

• Der Registrierungsprozess erstellt zwei verwandte Objekte im Microsoft Entra Mandanten, in dem die Anwendung registriert ist: ein Anwendungsobjekt und ein Dienstprinzipalobjekt. Weitere Informationen zu diesen Komponenten und deren Verwendung zur Laufzeit finden Sie unter Anwendungs- und Dienstprinzipalobjekte in Microsoft Entra ID.

Jetzt können Sie Ihre Clientanwendung bei Microsoft Entra ID registrieren.

Clientregistrierung

Informationen zum Registrieren eines Clients, der auf eine Azure Resource Manager-REST-API zugreift, finden Sie unter Verwenden des Portals zum Erstellen Microsoft Entra Anwendung und des Dienstprinzipals, der auf Ressourcen zugreifen kann. Der Artikel (auch in PowerShell- und CLI-Versionen zum Automatisieren der Registrierung verfügbar) zeigt Ihnen Folgendes:

• Registrieren Sie die Clientanwendung bei Microsoft Entra ID.
• Legen Sie Berechtigungsanforderungen fest, damit der Client auf die Azure Resource Manager-API zugreifen kann.
• Konfigurieren Sie Azure Resource Manager Role-Based Access Control -Einstellungen (RBAC) für die Autorisierung des Clients.

Wenn Ihr Client auf eine andere API als eine Azure Resource Manager-API zugreift, lesen Sie Folgendes:

• Registrieren einer Anwendung bei der Microsoft Identity Platform
  • Registrieren Sie die Clientanwendung bei Microsoft Entra ID im Abschnitt "Anwendung registrieren".
  • Erstellen Sie im Abschnitt "Anmeldeinformationen hinzufügen" einen geheimen Schlüssel (wenn Sie einen Webclient registrieren).
• Konfigurieren einer Anwendung für das Verfügbarmachen einer Web-API
  • Hinzufügen von Berechtigungen zu Ihrer Web-API und Verfügbarmachen als Bereiche
• Konfigurieren einer Clientanwendung für den Zugriff auf eine Web-API
  • Fügen Sie berechtigungsanforderungen gemäß den für die API definierten Bereichen im Abschnitt "Hinzufügen von Berechtigungen für den Zugriff auf Ihre Web-API" hinzu.

Nachdem Sie die Registrierung Ihrer Clientanwendung abgeschlossen haben, fahren Sie mit Ihrem Clientcode fort, wo Sie die REST-Anforderung erstellen und die Antwort behandeln.

Erstellen der Anforderung

In diesem Abschnitt werden die ersten drei der fünf Komponenten behandelt, die wir zuvor erläutert haben. Zuerst müssen Sie das Zugriffstoken von Microsoft Entra ID abrufen, das Sie zum Zusammenstellen des Anforderungsnachrichtenheaders verwenden.

Abrufen eines Zugriffstokens

Nachdem Sie über eine gültige Clientregistrierung verfügen, haben Sie zwei Möglichkeiten, in Microsoft Entra ID zu integrieren, um ein Zugriffstoken abzurufen:

• Plattform- und sprachneutrale OAuth2-Dienstendpunkte, die wir in diesem Artikel verwenden. Die Anweisungen in diesem Abschnitt gehen nicht von der Plattform oder Sprache/dem Skript Ihres Clients aus, wenn Sie die Microsoft Entra OAuth-Endpunkte verwenden. Die einzige Voraussetzung ist, dass Sie HTTPS-Anforderungen an/von Microsoft Entra ID senden/empfangen und die Antwortnachricht analysieren können.
• Die plattform- und sprachspezifischen Microsoft Authentication Libraries (MSAL), die den Rahmen dieses Artikels sprengen. Die Bibliotheken bieten asynchrone Wrapper für die OAuth2-Endpunktanforderungen und robuste Tokenbehandlungsfeatures wie zwischenspeichern und Aktualisieren der Tokenverwaltung. Weitere Informationen finden Sie in der Übersicht über die Microsoft Authentication Library (MSAL).

Die beiden Microsoft Entra Endpunkte, die Sie zum Authentifizieren Ihres Clients und zum Abrufen eines Zugriffstokens verwenden, werden als OAuth2/authorize- und /token Endpunkte bezeichnet. Wie Sie sie verwenden, hängt von der Registrierung Ihrer Anwendung und dem Typ des OAuth2-Autorisierungserteilungsflows ab, den Sie zur Laufzeit benötigen, um Ihre Anwendung zu unterstützen. Für die Zwecke dieses Artikels wird davon ausgegangen, dass Ihr Client einen der folgenden Autorisierungszuteilungsflows verwendet: Autorisierungscode oder Clientanmeldeinformationen. Befolgen Sie zum Abrufen eines Zugriffstokens, das in den verbleibenden Abschnitten verwendet wird, die Anweisungen für den Ablauf, der ihrem Szenario am besten entspricht.

Autorisierungscodezuweisung (interaktive Clients)

Diese Gewährung wird sowohl von Web- als auch von nativen Clients verwendet, die Anmeldeinformationen eines angemeldeten Benutzers erfordern, um den Ressourcenzugriff an die Clientanwendung zu delegieren. Er verwendet den /authorize Endpunkt, um einen Autorisierungscode abzurufen (als Reaktion auf die Benutzeranmeldung/-zustimmung), gefolgt von dem /token Endpunkt, um den Autorisierungscode gegen ein Zugriffstoken auszutauschen.

1. Zunächst muss Ihr Client einen Autorisierungscode von Microsoft Entra ID anfordern. Ausführliche Informationen zum Format der HTTPS GET-Anforderung an den /authorize Endpunkt sowie Beispiel-Anforderungs-/Antwortnachrichten finden Sie unter Anfordern eines Autorisierungscodes. Der URI enthält die folgenden Abfragezeichenfolgenparameter, die für Ihre Clientanwendung spezifisch sind:

   • client_id: Eine GUID, die Ihrer Clientanwendung während der Registrierung zugewiesen wurde, auch als Anwendungs-ID bezeichnet.

   • redirect_uri: Eine URL-codierte Version einer der Antwort-/Umleitungs-URIs, die bei der Registrierung Ihrer Clientanwendung angegeben wurde. Der übergebene Wert muss genau mit Ihrem Registrierungswert übereinstimmen.

   • resource: Ein URL-codierter Bezeichner-URI, der von der aufgerufenen REST-API angegeben wird. Web-/REST-APIs (auch als Ressourcenanwendungen bezeichnet) können eine oder mehrere Anwendungs-ID-URIs in ihrer Konfiguration verfügbar machen. Beispiel:

     • Azure Resource Manager-Anbieter-APIs (und klassisches Bereitstellungsmodell) verwenden https://management.core.windows.net/.
     • Weitere Ressourcen finden Sie in der API-Dokumentation oder in der Konfiguration der Ressourcenanwendung im Azure-Portal. Weitere Informationen finden Sie in der identifierUris -Eigenschaft des Microsoft Graph-API-Anwendungsobjekts.

   Die Anforderung an den /authorize Endpunkt löst zunächst eine Anmeldeaufforderung zur Authentifizierung des Benutzers aus. Die zurückgegebene Antwort wird als Umleitung (302) an den URI übermittelt, den Sie in redirect_uriangegeben haben. Die Antwortheadernachricht enthält ein location Feld, das den Umleitungs-URI gefolgt von einem code Abfrageparameter enthält. Der code Parameter enthält den Autorisierungscode, den Sie für Schritt 2 benötigen.

2. Als Nächstes muss Ihr Client den Autorisierungscode für ein Zugriffstoken einlösen. Ausführliche Informationen zum Format der HTTPS POST-Anforderung an den /token Endpunkt und Anforderungs-/Antwortbeispiele finden Sie unter Anfordern eines Zugriffstokens. Da es sich um eine POST-Anforderung handelt, packen Sie Ihre anwendungsspezifischen Parameter im Anforderungstext. Zusätzlich zu einigen der zuvor erwähnten Parameter (zusammen mit anderen neuen Parametern) übergeben Sie Folgendes:

   • code: Dieser Abfrageparameter enthält den Autorisierungscode, den Sie in Schritt 1 abgerufen haben.

   • client_secret: Sie benötigen diesen Parameter nur, wenn Ihr Client als Webanwendung konfiguriert ist. Dies ist derselbe Geheimnis-/Schlüsselwert, den Sie zuvor bei der Clientregistrierung generiert haben.

Gewährung von Clientanmeldeinformationen (nicht interaktive Clients)

Diese Gewährung wird nur von Webclients verwendet, sodass die Anwendung direkt auf Ressourcen zugreifen kann (keine Benutzerdelegierung), indem die Anmeldeinformationen des Clients verwendet werden, die zum Zeitpunkt der Registrierung bereitgestellt werden. Die Gewährung wird in der Regel von nicht interaktiven Clients (keine Benutzeroberfläche) verwendet, die als Dienst oder Daemon ausgeführt werden. Es erfordert nur den /token Endpunkt, um ein Zugriffstoken abzurufen.

Die Client-/Ressourceninteraktionen für diese Gewährung ähneln Schritt 2 der Autorisierungscodezuweisung. Ausführliche Informationen zum Format der HTTPS POST-Anforderung an den /token Endpunkt und Beispiele für Anforderung/Antwort finden Sie im Abschnitt "Abrufen eines Tokens" in Microsoft Identity Platform und im OAuth 2.0-Clientanmeldeinformationsflow.

Zusammenstellen der Anforderungsnachricht

Die meisten Programmiersprachen oder Frameworks und Skriptumgebungen erleichtern das Zusammenstellen und Senden der Anforderungsnachricht. Sie stellen in der Regel eine Web-/HTTP-Klasse oder API bereit, die die Erstellung oder Formatierung der Anforderung abstrahiert, sodass der Clientcode einfacher geschrieben werden kann (z. B. die HttpWebRequest Klasse im .NET Framework). Aus Gründen der Kürze und da der Großteil der Aufgabe für Sie erledigt wird, werden in diesem Abschnitt nur die wichtigen Elemente der Anforderung behandelt.

Anforderungs-URI

Da vertrauliche Informationen übertragen und empfangen werden, benötigen alle REST-Anforderungen das HTTPS-Protokoll für das URI-Schema, sodass die Anforderung und die Antwort einen sicheren Kanal erhalten. Die Informationen (d. h. der Microsoft Entra Autorisierungscode, Zugriffs-/Bearertoken und vertraulichen Anforderungs-/Antwortdaten) werden durch eine niedrigere Transportebene verschlüsselt, um den Datenschutz der Nachrichten zu gewährleisten.

Der Rest des Anforderungs-URI Ihres Diensts (Host, Ressourcenpfad und alle erforderlichen Abfragezeichenfolgenparameter) werden durch die zugehörige REST-API-Spezifikation bestimmt. Beispielsweise verwenden https://management.azure.com/Azure Resource Manager-Anbieter-APIs , und das klassische Azure-Bereitstellungsmodell verwendet https://management.core.windows.net/. Beide erfordern einen api-version Abfragezeichenfolgenparameter.

Anforderungsheader

Der Anforderungs-URI ist im Anforderungsnachrichtenheader zusammen mit allen zusätzlichen Feldern gebündelt, die für die REST-API-Spezifikation Ihres Diensts und die HTTP-Spezifikation erforderlich sind. Ihre Anforderung erfordert möglicherweise die folgenden allgemeinen Headerfelder:

• Authorization: Enthält das OAuth2-Bearertoken zum Sichern der Anforderung, wie es zuvor von Microsoft Entra ID abgerufen wurde.
• Content-Type: In der Regel auf "application/json" (Name/Wert-Paare im JSON-Format) festgelegt und gibt den MIME-Typ des Anforderungstexts an.
• Host: Der Domänenname oder die IP-Adresse des Servers, auf dem der REST-Dienstendpunkt gehostet wird.

Anforderungstext

Wie bereits erwähnt, ist der Anforderungsnachrichtentext optional, je nach dem von Ihnen angeforderten vorgang und den Parameteranforderungen. Falls erforderlich, gibt die API-Spezifikation für den angeforderten Dienst auch die Codierung und das Format an.

Der Anforderungstext wird vom Header durch eine leere Zeile getrennt, die gemäß dem Content-Type Headerfeld formatiert ist. Ein Beispiel für einen "application/json"-formatierten Text würde wie folgt angezeigt:

{
  "<name>": "<value>"
}

Senden der Anforderung

Nachdem Sie nun über den Anforderungs-URI des Diensts verfügen und den zugehörigen Anforderungsnachrichtenheader und -text erstellt haben, können Sie die Anforderung an den REST-Dienstendpunkt senden.

Sie können beispielsweise eine HTTPS GET-Anforderungsmethode für einen Azure Resource Manager-Anbieter senden, indem Sie Anforderungsheaderfelder verwenden, die den folgenden ähneln (beachten Sie, dass der Anforderungstext leer ist):

GET /subscriptions?api-version=2014-04-01-preview HTTP/1.1
Authorization: Bearer <bearer-token>
Host: management.azure.com

<no body>

Außerdem können Sie eine HTTPS PUT-Anforderungsmethode für einen Azure Resource Manager-Anbieter senden, indem Sie Anforderungsheader- und Textfelder ähnlich dem folgenden Beispiel verwenden:

PUT /subscriptions/.../resourcegroups/ExampleResourceGroup?api-version=2016-02-01  HTTP/1.1
Authorization: Bearer <bearer-token>
Content-Length: 29
Content-Type: application/json
Host: management.azure.com

{
  "location": "West US"
}

Nachdem Sie die Anforderung gestellt haben, werden der Header der Antwortnachricht und der optionale Text zurückgegeben.

Verarbeiten der Antwortnachricht

Der Prozess endet mit den letzten beiden der fünf Komponenten.

Um die Antwort zu verarbeiten, analysieren Sie den Antwortheader und optional den Antworttext (abhängig von der Anforderung). Im HTTPS GET-Beispiel im vorherigen Abschnitt haben Sie den Endpunkt /subscriptions verwendet, um die Liste der Abonnements für einen Benutzer abzurufen. Unter der Annahme, dass die Antwort erfolgreich war, sollten Sie Antwortheaderfelder erhalten, die dem folgenden Beispiel ähneln:

HTTP/1.1 200 OK
Content-Length: 303
Content-Type: application/json;

Außerdem sollten Sie einen Antworttext erhalten, der eine Liste der Azure-Abonnements und deren individuellen Eigenschaften enthält, die im JSON-Format codiert sind, ähnlich wie:

{
    "value":[
        {
        "id":"/subscriptions/...",
        "subscriptionId":"...",
        "displayName":"My Azure Subscription",
        "state":"Enabled",

"subscriptionPolicies":{
            "locationPlacementId":"Public_2015-09-01",
            "quotaId":"MSDN_2014-05-01",
            "spendingLimit":"On"}
        }
    ]
}

Ebenso sollten Sie für das HTTPS PUT-Beispiel einen Antwortheader ähnlich dem folgenden erhalten, der bestätigt, dass Ihr PUT-Vorgang zum Hinzufügen von "ExampleResourceGroup" erfolgreich war:

HTTP/1.1 200 OK
Content-Length: 193
Content-Type: application/json;

Und Sie sollten einen Antworttext erhalten, der den Inhalt Ihrer neu hinzugefügten Ressourcengruppe im JSON-Format codiert bestätigt, ähnlich wie:

{
    "id":"/subscriptions/.../resourceGroups/ExampleResourceGroup",
    "name":"ExampleResourceGroup",
    "location":"westus",
    "properties":
        {
        "provisioningState":"Succeeded"
        }
}

Wie bei der Anforderung erleichtern die meisten Programmiersprachen und Frameworks die Verarbeitung der Antwortnachricht. Sie geben diese Informationen in der Regel nach der Anforderung an Ihre Anwendung zurück, sodass Sie sie in einem typisierten/strukturierten Format verarbeiten können. In erster Linie möchten Sie den HTTP-status Code im Antwortheader bestätigen und den Antworttext gemäß der API-Spezifikation (oder den Content-Type Antwortheaderfeldern und Content-Length ) analysieren.

Asynchrone Vorgänge, Drosselung und Paging

Das in diesem Artikel beschriebene Muster "Create/Send/Process-Response" ist synchron und gilt für alle REST-Nachrichten. Einige Dienste unterstützen jedoch auch ein asynchrones Muster, das eine zusätzliche Verarbeitung von Antwortheadern erfordert, um die asynchrone Anforderung zu überwachen oder abzuschließen. Weitere Informationen finden Sie unter Nachverfolgen asynchroner Vorgänge in Azure.

Resource Manager wendet einen Grenzwert für die Anzahl von Lese- und Schreibanforderungen pro Stunde an, um zu verhindern, dass eine Anwendung zu viele Anforderungen sendet. Wenn Ihre Anwendung diese Grenzwerte überschreitet, werden Anforderungen gedrosselt. Der Antwortheader enthält die Anzahl der verbleibenden Anforderungen für Ihren Bereich. Weitere Informationen finden Sie unter Drosselung von Resource Manager-Anforderungen.

Einige Listenvorgänge geben eine Eigenschaft namens nextLink im Antworttext zurück. Diese Eigenschaft wird angezeigt, wenn die Ergebnisse zu groß sind, um in einer Antwort zurückgegeben zu werden. In der Regel enthält die Antwort die nextLink-Eigenschaft, wenn der Listenvorgang mehr als 1.000 Elemente zurückgibt. Wenn nextLink in den Ergebnissen nicht vorhanden ist, sind die zurückgegebenen Ergebnisse vollständig. Wenn nextLink eine URL enthält, sind die zurückgegebenen Ergebnisse nur Teil des Gesamten Resultsets.

Die Antwort hat das folgende Format:

{
  "value": [
    <returned-items>
  ],
  "nextLink": "https://management.azure.com/{operation}?api-version={version}&%24skiptoken={token}"
}

Um die nächste Seite der Ergebnisse abzurufen, senden Sie eine GET-Anforderung an die URL in der nextLink-Eigenschaft. Die URL enthält ein Fortsetzungstoken, um anzugeben, wo Sie sich in den Ergebnissen befinden. Setzen Sie das Senden von Anforderungen an die nextLink-URL fort, bis sie keine URL mehr in den zurückgegebenen Ergebnissen enthält.

Resilienz von Azure-APIs

Die Azure-REST-APIs sind auf Resilienz und kontinuierliche Verfügbarkeit ausgelegt. Vorgänge auf Steuerungsebene (Anforderungen, die an management.azure.com gesendet werden) in der REST-API sind:

• Sie sind regionsübergreifend verteilt. Einige Dienste sind regional.

• Sie sind an Standorten mit mehreren Verfügbarkeitszonen über diese Verfügbarkeitszonen (sowie deren Regionen) verteilt.

• Sie sind nicht von einem einzelnen logischen Rechenzentrum abhängig.

• Sie werden nie für Wartungsaktivitäten außer Betrieb genommen.

Verwandte Inhalte

Das ist alles. Nachdem Sie Ihre Microsoft Entra-Anwendung registriert haben und über eine modulare Technik zum Abrufen eines Zugriffstokens und zum Verarbeiten von HTTP-Anforderungen verfügen, ist es ziemlich einfach, Ihren Code zu replizieren, um neue REST-APIs zu nutzen. Weitere Informationen zur Anwendungsregistrierung und zum Microsoft Entra-Programmiermodell finden Sie in der Microsoft Identity Platform-Dokumentation.

Informationen zum Testen von HTTP-Anforderungen/-Antworten finden Sie unter:

• Fiddler. Fiddler ist ein kostenloser Proxy zum Webdebuggen, der Ihre REST-Anforderungen abfangen kann. Dies vereinfacht die Diagnose von Anforderungs-bzw. Antwortnachrichten.
• JWT.ms, mit denen Sie die Ansprüche schnell und einfach in Ihrem Bearertoken speichern können, damit Sie deren Inhalt überprüfen können.