Dokumentacja interfejsu API REST platformy Azure

Dokumentacja referencyjna interfejsu API REST platformy Azure — Zapraszamy!

Interfejsy API REST (Representational State Transfer) to punkty końcowe usługi obsługujące zestawy operacji (metod) HTTP, które umożliwiają tworzenie, pobieranie, aktualizowanie i usuwanie dostępu do zasobów usługi. Ten artykuł przeprowadzi Cię przez następujące kroki:

• Jak wywoływać interfejsy API REST platformy Azure za pomocą narzędzia curl
• Podstawowe składniki pary żądań/odpowiedzi interfejsu API REST.
• Jak zarejestrować aplikację kliencczą przy użyciu Tożsamość Microsoft Entra w celu zabezpieczenia żądań REST.
• Omówienie tworzenia i wysyłania żądania REST oraz obsługi odpowiedzi.

Porada

Większość interfejsów API REST usługi platformy Azure ma biblioteki klienckie, które udostępniają interfejs natywny do korzystania z usług platformy Azure:

.NETTO | Java | | Node.jsPython | Przejdź | C++

Jak wywoływać interfejsy API REST platformy Azure za pomocą narzędzia curl

Proces opisany w poniższym wpisie w blogu pokazuje, jak wywołać interfejs API REST platformy Azure przy użyciu narzędzia curl. Możesz rozważyć użycie narzędzia curl w skryptach nienadzorowanych. Na przykład w scenariuszach automatyzacji DevOps.

Wywoływanie interfejsu API REST platformy Azure za pośrednictwem narzędzia curl

Składniki żądania/odpowiedzi interfejsu API REST

W parze żądanie/odpowiedź interfejsu API REST można wyróżnić pięć składników:

1. Identyfikator URI żądania, który składa się z następujących elementów: {URI-scheme} :// {URI-host} / {resource-path} ? {query-string}. Mimo że identyfikator URI żądania jest zawarty w nagłówku komunikatu żądania, wymieniamy go oddzielnie, ponieważ większość języków i struktur wymaga jego przekazania poza komunikatem żądania.

   • Schemat identyfikatora URI: określa protokół używany do przesyłania żądania, Na przykład: http lub https.
   • Host identyfikatora URI: określa nazwę domeny lub adres IP serwera, na którym jest hostowany punkt końcowy usługi REST, na przykład graph.microsoft.com.
   • Ścieżka zasobu: określa zasób lub kolekcję zasobów, która może obejmować wiele segmentów używanych przez usługę podczas wybierania tych zasobów. Na przykład: beta/applications/00003f25-7e1f-4278-9488-efc7bac53c4a/owners może służyć do wykonywania zapytań względem listy właścicieli określonej aplikacji w kolekcji aplikacji.
   • Ciąg zapytania (opcjonalnie): udostępnia dodatkowe proste parametry, takie jak wersja interfejsu API lub kryteria wybierania zasobów.

2. Pola nagłówka komunikatu żądania HTTP:

   • Wymagana metoda HTTP (nazywana również operacją lub zleceniem), która informuje usługę o typie żądanej operacji. Interfejsy API REST platformy Azure obsługują metody GET, HEAD, PUT, POST i PATCH.
   • Opcjonalne dodatkowe pola nagłówka wymagane przez określony identyfikator URI i metodę HTTP. Na przykład nagłówek autoryzacji, który dostarcza token elementu nośnego zawierający informacje o autoryzacji klienta dla żądania.

3. Opcjonalne pola treści komunikatu żądania HTTP umożliwiające obsługę identyfikatora URI i działania protokołu HTTP. Na przykład operacje POST zawierają obiekty zakodowane w formacie MIME, które są przekazywane jako parametry złożone. W przypadku operacji POST lub PUT typ treści z kodowaniem MIME należy również określić w nagłówku żądania Content-type. Niektóre usługi wymagają użycia konkretnego typu MIME, takiego jak application/json.

4. Pola nagłówka komunikatu odpowiedzi HTTP:

   • Kod stanu HTTP — od kodów 2xx oznaczających powodzenie do kodów błędów 4xx lub 5xx. Można także zwracać kod stanu zdefiniowany przez usługę zgodnie z informacjami podanymi w dokumentacji interfejsu API.
   • Opcjonalne dodatkowe pola nagłówka, wymagane do obsługi odpowiedzi na żądanie, takie jak nagłówek odpowiedzi Content-type.

5. Opcjonalne pola treści komunikatu odpowiedzi HTTP:

   • Obiekty odpowiedzi zakodowane w formacie MIME są zwracane w treści odpowiedzi HTTP, np. odpowiedzi metody GET zwracającej dane. Zazwyczaj te obiekty są zwracane w formacie strukturalnym, takim jak JSON lub XML, zgodnie z nagłówkiem odpowiedzi Content-type. Na przykład gdy zażądasz tokenu dostępu z Tożsamość Microsoft Entra, zostanie on zwrócony w treści odpowiedzi jako access_token element , jeden z kilku obiektów sparowanych nazwy/wartości w kolekcji danych. W tym przykładzie dołączany jest również nagłówek Content-Type: application/json odpowiedzi.

Rejestrowanie aplikacji klienckiej w usłudze Tożsamość Microsoft Entra

Większość usług platformy Azure (takich jak dostawcy usługi Azure Resource Manager i klasyczny model wdrażania) wymaga, aby kod klienta uwierzytelnił się przy użyciu prawidłowych poświadczeń, zanim będzie można wywołać interfejs API usługi. Uwierzytelnianie jest koordynowane między różnymi aktorami przez Tożsamość Microsoft Entra i dostarcza klientowi token dostępu jako dowód uwierzytelniania. Token jest następnie wysyłany do usługi platformy Azure w nagłówku autoryzacji HTTP kolejnych żądań interfejsu API REST. Oświadczenia tokenu udostępniają również informacje do usługi, umożliwiając jej zweryfikowanie klienta i wykonanie dowolnej wymaganej autoryzacji.

Jeśli używasz interfejsu API REST, który nie używa zintegrowanego uwierzytelniania Microsoft Entra lub masz już zarejestrowanego klienta, przejdź do sekcji Tworzenie żądania.

Wymagania wstępne

Aplikacja kliencka musi ustawić konfigurację tożsamości znaną Tożsamość Microsoft Entra przed uruchomieniem, rejestrując ją w dzierżawie Microsoft Entra. Przed zarejestrowaniem klienta w Tożsamość Microsoft Entra należy wziąć pod uwagę następujące wymagania wstępne:

• Jeśli nie masz jeszcze dzierżawy Microsoft Entra, zobacz Konfigurowanie dzierżawy Microsoft Entra.

• Zgodnie z platformą autoryzacji OAuth2 Tożsamość Microsoft Entra obsługuje dwa typy klientów. Zrozumienie każdego z nich ułatwia podjęcie decyzji, która jest najbardziej odpowiednia dla danego scenariusza:

  • klienci sieci Web/poufne działają na serwerze internetowym i mogą uzyskiwać dostęp do zasobów w ramach własnej tożsamości (na przykład usługi lub demona) lub uzyskać delegowane autoryzację dostępu do zasobów w ramach tożsamości zalogowanego użytkownika (na przykład aplikacji internetowej). Tylko klient internetowy może bezpiecznie utrzymywać i prezentować własne poświadczenia podczas uwierzytelniania Microsoft Entra w celu uzyskania tokenu dostępu.
  • klienci natywni/publiczni są instalowani i uruchamiani na urządzeniu. Mogą oni uzyskiwać dostęp do zasobów tylko w ramach autoryzacji delegowanej przy użyciu tożsamości zalogowanego użytkownika w celu uzyskania tokenu dostępu w imieniu użytkownika.

• Proces rejestracji tworzy dwa powiązane obiekty w dzierżawie Microsoft Entra, w której zarejestrowano aplikację: obiekt aplikacji i obiekt jednostki usługi. Aby uzyskać więcej informacji na temat tych składników i sposobu ich użycia w czasie wykonywania, zobacz Obiekty aplikacji i jednostki usługi w Tożsamość Microsoft Entra.

Teraz możesz przystąpić do rejestrowania aplikacji klienckiej przy użyciu Tożsamość Microsoft Entra.

Rejestracja klienta

Aby zarejestrować klienta, który uzyskuje dostęp do interfejsu API REST usługi Azure Resource Manager, zobacz Tworzenie Microsoft Entra aplikacji i jednostki usługi, które mogą uzyskiwać dostęp do zasobów za pomocą portalu. Artykuł (dostępny również w programie PowerShell i wersjach interfejsu wiersza polecenia na potrzeby automatyzacji rejestracji) pokazuje, jak wykonać następujące czynności:

• Zarejestruj aplikację kliencą przy użyciu Tożsamość Microsoft Entra.
• Ustaw żądania uprawnień, aby umożliwić klientowi dostęp do interfejsu API usługi Azure Resource Manager.
• Skonfiguruj ustawienia usługi Azure Resource Manager Role-Based Access Control (RBAC) na potrzeby autoryzowania klienta.

Jeśli klient uzyskuje dostęp do interfejsu API innego niż interfejs API usługi Azure Resource Manager, zobacz:

• Rejestrowanie aplikacji za pomocą platformy tożsamości firmy Microsoft
  • Zarejestruj aplikację kliencą przy użyciu Tożsamość Microsoft Entra w sekcji "Rejestrowanie aplikacji".
  • Utwórz klucz tajny (jeśli rejestrujesz klienta internetowego) w sekcji "Dodawanie poświadczeń".
• Konfigurowanie aplikacji w celu uwidocznienia internetowego interfejsu API
  • Dodawanie uprawnień do internetowego interfejsu API, uwidacznianie ich jako zakresów
• Konfigurowanie aplikacji klienckiej w celu uzyskania dostępu do internetowego interfejsu API
  • Dodaj żądania uprawnień zgodnie z wymaganiami zakresów zdefiniowanych dla interfejsu API w sekcji "Dodawanie uprawnień dostępu do internetowego interfejsu API".

Po zakończeniu rejestracji aplikacji klienckiej przejdź do kodu klienta, w którym utworzono żądanie REST i obsłużono odpowiedź.

Tworzenie żądania

W tej sekcji omówiono pierwsze trzy z pięciu omówionych wcześniej składników. Najpierw należy uzyskać token dostępu z Tożsamość Microsoft Entra, który służy do tworzenia nagłówka komunikatu żądania.

Uzyskiwanie tokenu dostępu

Po zarejestrowaniu prawidłowej rejestracji klienta masz dwa sposoby integracji z Tożsamość Microsoft Entra w celu uzyskania tokenu dostępu:

• Punkty końcowe usługi OAuth2 neutralne dla platformy i języka, których używamy w tym artykule. Instrukcje podane w tej sekcji zakładają, że nic nie dotyczy platformy lub języka/skryptu klienta podczas korzystania z punktów końcowych protokołu OAuth Microsoft Entra. Jedynym wymaganiem jest wysyłanie/odbieranie żądań HTTPS do/z Tożsamość Microsoft Entra i analizowanie komunikatu odpowiedzi.
• Biblioteki uwierzytelniania firmy Microsoft specyficzne dla platformy i języka (MSAL), które wykraczają poza zakres tego artykułu. Biblioteki udostępniają asynchroniczne otoki dla żądań punktu końcowego OAuth2 oraz niezawodne funkcje obsługi tokenów, takie jak buforowanie i zarządzanie tokenami odświeżania. Aby uzyskać więcej informacji, zobacz Omówienie biblioteki Microsoft Authentication Library (MSAL).

Dwa Microsoft Entra punkty końcowe używane do uwierzytelniania klienta i uzyskiwania tokenu dostępu są określane jako OAuth2 /authorize i /token punkty końcowe. Sposób ich używania zależy od rejestracji aplikacji i typu przepływu udzielania autoryzacji OAuth2 potrzebnego do obsługi aplikacji w czasie wykonywania. Na potrzeby tego artykułu przyjęto założenie, że klient używa jednego z następujących przepływów udzielania autoryzacji: kodu autoryzacji lub poświadczeń klienta. Aby uzyskać token dostępu używany w pozostałych sekcjach, postępuj zgodnie z instrukcjami dotyczącymi przepływu, który najlepiej pasuje do danego scenariusza.

Udzielanie kodu autoryzacji (klienci interaktywni)

To przyznanie jest używane zarówno przez klientów internetowych, jak i natywnych, wymagających poświadczeń od zalogowanego użytkownika w celu delegowania dostępu do zasobów do aplikacji klienckiej. Używa punktu końcowego /authorize do uzyskania kodu autoryzacji (w odpowiedzi na logowanie/wyrażenie zgody użytkownika), a następnie /token punktu końcowego w celu wymiany kodu autoryzacji dla tokenu dostępu.

1. Najpierw klient musi zażądać kodu autoryzacji z Tożsamość Microsoft Entra. Aby uzyskać szczegółowe informacje na temat formatu żądania HTTPS GET do punktu końcowego /authorize oraz przykładowych komunikatów żądania/odpowiedzi, zobacz Żądanie kodu autoryzacji. Identyfikator URI zawiera następujące parametry ciągu zapytania, które są specyficzne dla aplikacji klienckiej:

   • client_id: identyfikator GUID przypisany do aplikacji klienckiej podczas rejestracji, znany również jako identyfikator aplikacji.

   • redirect_uri: zakodowana pod adresem URL wersja jednego z identyfikatorów URI odpowiedzi/przekierowania określona podczas rejestracji aplikacji klienckiej. Przekazana wartość musi być dokładnie zgodna z wartością rejestracji.

   • resource: identyfikator URI zakodowany w adresie URL określony przez wywoływany interfejs API REST. Interfejsy API sieci Web/REST (nazywane również aplikacjami zasobów) mogą uwidaczniać co najmniej jeden identyfikator URI identyfikatora aplikacji w konfiguracji. Na przykład:

     • Interfejsy API dostawcy usługi Azure Resource Manager (i klasycznego modelu wdrażania) używają usługi https://management.core.windows.net/.
     • Aby uzyskać informacje o innych zasobach, zobacz dokumentację interfejsu API lub konfigurację aplikacji zasobów w Azure Portal. Aby uzyskać więcej informacji, zobacz identifierUris właściwość obiektu aplikacji Microsoft interfejs Graph API.

   Żądanie do punktu końcowego /authorize najpierw wyzwala monit logowania o uwierzytelnienie użytkownika. Otrzymana odpowiedź jest dostarczana jako przekierowanie (302) do identyfikatora URI określonego w pliku redirect_uri. Komunikat nagłówka odpowiedzi zawiera location pole zawierające identyfikator URI przekierowania, po którym następuje code parametr zapytania. Parametr code zawiera kod autoryzacji, który jest potrzebny dla kroku 2.

2. Następnie klient musi zrealizować kod autoryzacji dla tokenu dostępu. Aby uzyskać szczegółowe informacje na temat formatu żądania HTTPS POST dla punktu końcowego /token i przykładów żądania/odpowiedzi, zobacz Żądanie tokenu dostępu. Ponieważ jest to żądanie POST, należy spakujesz parametry specyficzne dla aplikacji w treści żądania. Oprócz niektórych wcześniej wymienionych parametrów (wraz z innymi nowymi), przekażesz następujące elementy:

   • code: ten parametr zapytania zawiera kod autoryzacji uzyskany w kroku 1.

   • client_secret: Ten parametr jest potrzebny tylko wtedy, gdy klient jest skonfigurowany jako aplikacja internetowa. Jest to ta sama wartość wpisu tajnego/klucza wygenerowana wcześniej w rejestracji klienta.

Udzielanie poświadczeń klienta (klienci nieinterakcyjni)

To udzielenie jest używane tylko przez klientów internetowych, co umożliwia aplikacji bezpośredni dostęp do zasobów (bez delegowania użytkownika) przy użyciu poświadczeń klienta, które są udostępniane w czasie rejestracji. Grant jest zwykle używany przez nieinterakcyjnych klientów (bez interfejsu użytkownika), które działają jako usługa lub demon. Wymaga tylko punktu końcowego /token do uzyskania tokenu dostępu.

Interakcje klienta/zasobu dla tego przyznania są podobne do kroku 2 udzielania kodu autoryzacji. Aby uzyskać szczegółowe informacje na temat formatu żądania HTTPS POST do /token punktu końcowego i przykładów żądania/odpowiedzi, zobacz sekcję "Pobierz token" w Platforma tożsamości Microsoft i przepływ poświadczeń klienta OAuth 2.0.

Skompletuj komunikat żądania

Większość języków programowania lub struktur i środowisk skryptowych ułatwia składanie i wysyłanie komunikatu żądania. Zazwyczaj udostępniają one klasę internetową/http lub interfejs API, która abstrakcyjnie tworzy lub formatuje żądanie, co ułatwia pisanie kodu klienta (HttpWebRequestna przykład klasy w .NET Framework). W przypadku zwięzłości i ze względu na to, że większość zadań jest obsługiwana, w tej sekcji omówiono tylko ważne elementy żądania.

Identyfikator URI żądania

Ponieważ informacje poufne są przesyłane i odbierane, wszystkie żądania REST wymagają protokołu HTTPS dla schematu identyfikatora URI, dając żądanie i odpowiedź na bezpieczny kanał. Informacje (czyli kod autoryzacji Microsoft Entra, token dostępu/elementu nośnego i poufne dane żądania/odpowiedzi) są szyfrowane przez niższą warstwę transportu, zapewniając prywatność komunikatów.

Pozostała część identyfikatora URI żądania usługi (hosta, ścieżki zasobu i wszelkich wymaganych parametrów ciągu zapytania) jest określana przez powiązaną specyfikację interfejsu API REST. Na przykład interfejsy API dostawcy usługi Azure Resource Manager używają klasy , a klasyczny model wdrażania platformy Azure używa https://management.azure.com/metody https://management.core.windows.net/. Oba wymagają parametru api-version ciągu zapytania.

Nagłówek żądania

Identyfikator URI żądania jest dołączony do nagłówka komunikatu żądania wraz z dodatkowymi polami wymaganymi przez specyfikację interfejsu API REST usługi i specyfikację HTTP. Żądanie może wymagać następujących typowych pól nagłówka:

• Authorization: zawiera token elementu nośnego OAuth2 w celu zabezpieczenia żądania, jak nabyty wcześniej z Tożsamość Microsoft Entra.
• Content-Type: zazwyczaj ustawiono wartość "application/json" (pary nazw/wartości w formacie JSON) i określa typ MIME treści żądania.
• Host: nazwa domeny lub adres IP serwera, na którym jest hostowany punkt końcowy usługi REST.

Treść żądania

Jak wspomniano wcześniej, treść komunikatu żądania jest opcjonalna, w zależności od określonej operacji, której żądasz, i jej wymagań dotyczących parametrów. Jeśli jest to wymagane, specyfikacja interfejsu API dla żądanej usługi określa również kodowanie i format.

Treść żądania jest oddzielona od nagłówka pustym wierszem sformatowanym zgodnie z polem nagłówka Content-Type . Przykład sformatowanej treści "application/json" będzie wyświetlany w następujący sposób:

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

Wysyłanie żądania

Teraz, gdy masz identyfikator URI żądania usługi i utworzono powiązany nagłówek i treść komunikatu żądania, możesz wysłać żądanie do punktu końcowego usługi REST.

Możesz na przykład wysłać metodę żądania HTTPS GET dla dostawcy usługi Azure Resource Manager przy użyciu pól nagłówka żądania, które są podobne do następujących (zwróć uwagę, że treść żądania jest pusta):

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

<no body>

Możesz również wysłać metodę żądania HTTPS PUT dla dostawcy usługi Azure Resource Manager przy użyciu pól nagłówka żądania i treści podobnych do następującego przykładu:

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"
}

Po wykonaniu żądania zostanie zwrócony nagłówek komunikatu odpowiedzi i opcjonalna treść.

Przetwarzanie komunikatu odpowiedzi

Proces kończy się z dwoma ostatnimi z pięciu składników.

Aby przetworzyć odpowiedź, przeanalizuj nagłówek odpowiedzi i opcjonalnie treść odpowiedzi (w zależności od żądania). W przykładzie HTTPS GET podanym w poprzedniej sekcji użyto punktu końcowego /subscriptions, aby pobrać listę subskrypcji dla użytkownika. Zakładając, że odpowiedź zakończyła się pomyślnie, powinny zostać wyświetlone pola nagłówka odpowiedzi podobne do następującego przykładu:

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

Otrzymasz treść odpowiedzi zawierającą listę subskrypcji platformy Azure i ich poszczególne właściwości zakodowane w formacie JSON, podobnie jak:

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

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

Podobnie w przypadku przykładu HTTPS PUT powinien zostać wyświetlony nagłówek odpowiedzi podobny do poniższego, potwierdzając, że operacja PUT w celu dodania elementu "ExampleResourceGroup" zakończyła się pomyślnie:

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

Powinna zostać wyświetlona treść odpowiedzi, która potwierdza zawartość nowo dodanej grupy zasobów zakodowanej w formacie JSON, podobnie jak:

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

Podobnie jak w przypadku żądania, większość języków programowania i struktur ułatwia przetwarzanie komunikatu odpowiedzi. Zazwyczaj zwracają te informacje do aplikacji po żądaniu, umożliwiając przetwarzanie ich w formacie typowym/ustrukturyzowanym. Głównie interesuje Cię potwierdzenie kodu stanu HTTP w nagłówku odpowiedzi i analizowanie treści odpowiedzi zgodnie ze specyfikacją interfejsu API (lub Content-Type polami nagłówka odpowiedzi i Content-Length ).

Operacje asynchroniczne, ograniczanie przepustowości i stronicowanie

Wzorzec tworzenia/wysyłania/przetwarzania odpowiedzi omówiony w tym artykule jest synchroniczny i ma zastosowanie do wszystkich komunikatów REST. Jednak niektóre usługi obsługują również wzorzec asynchroniczny, który wymaga dodatkowego przetwarzania nagłówków odpowiedzi w celu monitorowania lub ukończenia żądania asynchronicznego. Aby uzyskać więcej informacji, zobacz Śledzenie asynchronicznych operacji platformy Azure.

Resource Manager stosuje limit liczby żądań odczytu i zapisu na godzinę, aby uniemożliwić aplikacji wysyłanie zbyt wielu żądań. Jeśli aplikacja przekroczy te limity, żądania są ograniczane. Nagłówek odpowiedzi zawiera liczbę pozostałych żądań dla zakresu. Aby uzyskać więcej informacji, zobacz Ograniczanie żądań usługi Resource Manager.

Niektóre operacje listy zwracają właściwość wywoływaną nextLink w treści odpowiedzi. Ta właściwość jest widoczna, gdy wyniki są zbyt duże, aby zwrócić jedną odpowiedź. Zazwyczaj odpowiedź zawiera właściwość nextLink, gdy operacja listy zwraca więcej niż 1000 elementów. Gdy element NextLink nie jest obecny w wynikach, zwrócone wyniki zostaną ukończone. Gdy element NextLink zawiera adres URL, zwrócone wyniki są tylko częścią całkowitego zestawu wyników.

Odpowiedź jest w formacie:

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

Aby uzyskać następną stronę wyników, wyślij żądanie GET do adresu URL we właściwości nextLink. Adres URL zawiera token kontynuacji, aby wskazać, gdzie znajdujesz się w wynikach. Kontynuuj wysyłanie żądań do adresu URL nextLink, dopóki nie będzie już zawierać adresu URL w zwróconych wynikach.

Odporność interfejsów API platformy Azure

Interfejsy API REST platformy Azure zostały zaprojektowane pod kątem odporności i ciągłej dostępności. Operacje płaszczyzny sterowania (żądania wysyłane do management.azure.com) w interfejsie API REST to:

• Rozproszone między regionami. Niektóre usługi są regionalne.

• Rozproszone w Strefy dostępności (a także w regionach) w lokalizacjach, które mają wiele Strefy dostępności.

• Nie zależy od jednego logicznego centrum danych.

• Nigdy nie zdjęte na potrzeby działań konserwacyjnych.

Zawartość pokrewna

To wszystko. Po zarejestrowaniu aplikacji Microsoft Entra i uzyskaniu modułowej techniki uzyskiwania tokenu dostępu i obsługi żądań HTTP można dość łatwo replikować kod, aby korzystać z nowych interfejsów API REST. Aby uzyskać więcej informacji na temat rejestracji aplikacji i modelu programowania Microsoft Entra, zobacz dokumentację Platforma tożsamości Microsoft.

Aby uzyskać informacje na temat testowania żądań/odpowiedzi HTTP, zobacz:

• Fiddler. Jest to bezpłatny internetowy serwer proxy debugowania, który pozwala przechwytywać żądania REST, co ułatwia diagnozowanie komunikatów żądania/odpowiedzi HTTP.
• JWT.ms, co ułatwia szybkie i łatwe zrzuty oświadczeń w tokenie elementu nośnego, aby można było zweryfikować ich zawartość.