Udostępnij za pośrednictwem

Pobieranie metadanych kontenera

  • Artykuł

Operacja Get Container Metadata zwraca wszystkie metadane zdefiniowane przez użytkownika dla kontenera.

Żądanie

Żądanie Get Container Metadata może być skonstruowane w następujący sposób. Zalecamy korzystanie z protokołu HTTPS. Zastąp ciąg myaccount nazwą konta magazynu:

Metoda Identyfikator URI żądania Wersja PROTOKOŁU HTTP
GET/HEAD https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata HTTP/1.1

Żądanie usługi magazynu emulowanego

Gdy wysyłasz żądanie względem emulowanej usługi magazynu, określ nazwę hosta emulatora i Azure Blob Storage port jako 127.0.0.1:10000, a następnie nazwę emulowanego konta magazynu:

Metoda Identyfikator URI żądania Wersja PROTOKOŁU HTTP
GET/HEAD http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=metadata HTTP/1.1

Aby uzyskać więcej informacji, zobacz Use the Azurite emulator for local Azure Storage development (Używanie emulatora Azurite do lokalnego programowania w usłudze Azure Storage).

Parametry identyfikatora URI

Dla identyfikatora URI żądania można określić następujące dodatkowe parametry:

Parametr Opis
timeout Opcjonalny. Parametr jest wyrażony timeout w sekundach. Aby uzyskać więcej informacji, zobacz Ustawianie limitów czasu dla operacji usługi Blob Storage.

Nagłówki żądań

W poniższej tabeli opisano wymagane i opcjonalne nagłówki żądań.

Nagłówek żądania Opis
Authorization Wymagane. Określa schemat autoryzacji, nazwę konta i podpis. Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage.
Date lub x-ms-date Wymagane. Określa dla żądania godzinę w formacie uniwersalnego czasu koordynowanego (UTC). Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage.
x-ms-lease-id: <ID> Opcjonalnie, wersja 2012-02-12 lub nowsza. Jeśli jest określony, powiedzie się tylko wtedy, Get Container Metadata gdy dzierżawa kontenera jest aktywna i jest zgodna z tym identyfikatorem. Jeśli nie ma aktywnej dzierżawy lub identyfikator nie jest zgodny, zostanie zwrócony kod błędu 412 (Niepowodzenie warunku wstępnego).
x-ms-version Wymagane dla wszystkich autoryzowanych żądań, opcjonalnie dla żądań anonimowych. Określa wersję operacji do użycia dla tego żądania. Aby uzyskać więcej informacji, zobacz Przechowywanie wersji dla usług Azure Storage.
x-ms-client-request-id Opcjonalny. Zapewnia nieprzezroczystą wartość wygenerowaną przez klienta z limitem znaków 1-kibibyte (KiB) rejestrowanym w dziennikach podczas konfigurowania rejestrowania. Zdecydowanie zalecamy używanie tego nagłówka do korelowania działań po stronie klienta z żądaniami odbieranymi przez serwer. Aby uzyskać więcej informacji, zobacz Monitorowanie Azure Blob Storage.

Treść żądania

Brak.

Reakcja

Odpowiedź zawiera kod stanu HTTP i zestaw nagłówków odpowiedzi.

Kod stanu

Pomyślna operacja zwraca kod stanu 200 (OK).

Aby uzyskać informacje o kodach stanu, zobacz Kody stanu i błędów.

Nagłówki odpowiedzi

Odpowiedź na tę operację zawiera następujące nagłówki. Odpowiedź może również zawierać dodatkowe standardowe nagłówki HTTP. Wszystkie standardowe nagłówki są zgodne ze specyfikacją protokołu HTTP/1.1.

Składnia Opis
x-ms-meta-name:value Zwraca ciąg zawierający parę nazwa-wartość skojarzona z kontenerem jako metadane.
ETag Tag jednostki dla kontenera. Jeśli wersja żądania to 2011-08-18 lub nowsza, wartość elementu ETag jest ujęta w cudzysłów.
Last-Modified Zwraca datę i godzinę ostatniej modyfikacji kontenera. Format daty jest zgodny z dokumentem RFC 1123. Aby uzyskać więcej informacji, zobacz Reprezentacja wartości Date-Time w nagłówkach.

Każda operacja modyfikując kontener lub jego właściwości lub metadane aktualizuje czas ostatniej modyfikacji. Operacje na obiektach blob nie mają wpływu na czas ostatniej modyfikacji kontenera.
x-ms-request-id Ten nagłówek jednoznacznie identyfikuje żądanie, które zostało wykonane i może służyć do rozwiązywania problemów z żądaniem. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z operacjami interfejsu API.
x-ms-version Wersja usługi, która została użyta do wykonania żądania. Ten nagłówek jest zwracany w przypadku żądań wysyłanych w wersji 2009-09-19 lub nowszej.

Nagłówek jest również zwracany dla żądań anonimowych bez określonej wersji, jeśli kontener został oznaczony do dostępu publicznego przy użyciu usługi w wersji 2009-09-19.
Date Wartość daty/godziny UTC wygenerowana przez usługę, która wskazuje godzinę zainicjowania odpowiedzi.
x-ms-client-request-id Może służyć do rozwiązywania problemów z żądaniami i odpowiadającymi odpowiedziami. Wartość tego nagłówka jest równa wartości x-ms-client-request-id nagłówka, jeśli jest obecna w żądaniu, a wartość zawiera nie więcej niż 1024 widoczne znaki ASCII. x-ms-client-request-id Jeśli nagłówek nie znajduje się w żądaniu, ten nagłówek nie jest obecny w odpowiedzi.

Treść odpowiedzi

Brak.

Przykładowa odpowiedź

  
Response Status:  
HTTP/1.1 200 OK  
  
Response headers:  
Transfer-Encoding: chunked  
x-ms-meta-AppName: StorageSample  
Date: Sun, 25 Sep 2011 23:43:08 GMT  
ETag: "0x8CAFB82EFF70C46"  
Last-Modified: Sun, 25 Sep 2011 19:42:18 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Autoryzacja

Autoryzacja jest wymagana podczas wywoływania dowolnej operacji dostępu do danych w usłudze Azure Storage. Możesz autoryzować operację Get Container Metadata zgodnie z poniższym opisem.

Ważne

Firma Microsoft zaleca używanie Tożsamość Microsoft Entra z tożsamościami zarządzanymi w celu autoryzowania żądań do usługi Azure Storage. Tożsamość Microsoft Entra zapewnia doskonałe zabezpieczenia i łatwość użycia w porównaniu z autoryzacją klucza wspólnego.

Usługa Azure Storage obsługuje autoryzację żądań do danych obiektów blob przy użyciu Tożsamość Microsoft Entra. Dzięki Tożsamość Microsoft Entra możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby udzielić uprawnień podmiotowi zabezpieczeń. Podmiot zabezpieczeń może być użytkownikiem, grupą, jednostką usługi aplikacji lub tożsamością zarządzaną platformy Azure. Podmiot zabezpieczeń jest uwierzytelniany przez Tożsamość Microsoft Entra w celu zwrócenia tokenu OAuth 2.0. Token może następnie służyć do autoryzowania żądania względem usługi Blob Service.

Aby dowiedzieć się więcej na temat autoryzacji przy użyciu Tożsamość Microsoft Entra, zobacz Autoryzowanie dostępu do obiektów blob przy użyciu Tożsamość Microsoft Entra.

Uprawnienia

Poniżej przedstawiono akcję RBAC niezbędną dla użytkownika Microsoft Entra, grupy, tożsamości zarządzanej lub jednostki usługi w celu wywołania Get Container Metadata operacji oraz najmniej uprzywilejowanej wbudowanej roli RBAC platformy Azure, która obejmuje tę akcję:

Aby dowiedzieć się więcej na temat przypisywania ról przy użyciu kontroli dostępu opartej na rolach platformy Azure, zobacz Przypisywanie roli platformy Azure w celu uzyskania dostępu do danych obiektów blob.

Uwagi

Ta operacja zwraca tylko metadane zdefiniowane przez użytkownika w kontenerze. Aby zwrócić właściwości systemu, wywołaj polecenie Pobierz właściwości kontenera.

Rozliczenia

Żądania cenowe mogą pochodzić od klientów korzystających z interfejsów API usługi Blob Storage bezpośrednio za pośrednictwem interfejsu API REST usługi Blob Storage lub biblioteki klienta usługi Azure Storage. Te żądania naliczają opłaty za transakcję. Typ transakcji wpływa na sposób naliczania opłat za konto. Na przykład transakcje odczytu są naliczane do innej kategorii rozliczeniowej niż transakcje zapisu. W poniższej tabeli przedstawiono kategorię rozliczeń dla Get Container Metadata żądań na podstawie typu konta magazynu:

Operacja Typ konta magazynu Kategoria rozliczeń
Pobieranie metadanych kontenera Blokowy obiekt blob w warstwie Premium
Standardowa ogólnego przeznaczenia, wersja 2		 Inne operacje
Pobieranie metadanych kontenera Standardowa ogólnego przeznaczenia, wersja 1 Operacje odczytu

Aby dowiedzieć się więcej o cenach dla określonej kategorii rozliczeń, zobacz Azure Blob Storage Cennik.

Zobacz też

Operacje na kontenerach