Abrufen von Kontoinformationen

Der Get Account Information Vorgang gibt den SKU-Namen und die Kontoart für das angegebene Konto zurück. Es ist ab Version 2018-03-28 des Diensts verfügbar.

Anforderung

Sie können die Get Account Information Anforderung erstellen, indem Sie eine gültige Anforderung verwenden, die über die Sas-Autorisierung (Shared Access Signature, Shared Access Signature) autorisiert ist.

Wenn Sie einen restype Wert von account und hinzufügenpropertiescomp, verwendet die Anforderung den Get Account Information Vorgang. Die folgende Tabelle enthält Beispiele:

Methode Anforderungs-URI HTTP-Version
GET/HEAD https://myaccount.blob.core.windows.net/?restype=account&comp=properties HTTP/1.1
GET/HEAD https://myaccount.blob.core.windows.net/?restype=account&comp=properties&sv=myvalidsastoken HTTP/1.1
GET/HEAD https://myaccount.blob.core.windows.net/mycontainer/?restype=account&comp=properties&sv=myvalidsastoken HTTP/1.1
GET/HEAD https://myaccount.blob.core.windows.net/mycontainer/myblob?restype=account&comp=properties&sv=myvalidsastoken HTTP/1.1

URI-Parameter

Sie können im Anforderungs-URI die folgenden zusätzlichen Parameter angeben:

Parameter BESCHREIBUNG
restype Erforderlich. Der restype Parameterwert muss sein account.
comp Erforderlich. Der comp Parameterwert muss sein properties.

Anforderungsheader

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben:

Anforderungsheader BESCHREIBUNG
Authorization Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Date or x-ms-date Erforderlich. Gibt die koordinierte Weltzeit (Coordinated Universal Time, UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Erforderlich für alle autorisierten Anforderungen. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Für diesen Vorgang muss die Version 2018-03-28 oder höher sein. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
x-ms-client-request-id Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (KiB) bereit, der beim Konfigurieren der Protokollierung in den Protokollen aufgezeichnet wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt.

Anforderungstext

Keine.

Antwort

Die Antwort enthält den HTTP-Statuscode und einen Satz von Antwortheadern.

Statuscode

Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben.

Informationen zu status Codes finden Sie unter Status- und Fehlercodes.

Antwortheader

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort kann auch zusätzliche HTTP-Standardheader enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Antwortheader BESCHREIBUNG
x-ms-request-id Identifiziert eindeutig die Anforderung, die gestellt wurde. Sie können es verwenden, um die Problembehandlung für die Anforderung zu beheben. Weitere Informationen finden Sie unter Problembehandlung bei API-Vorgängen.
x-ms-version Version 2009-09-19 und höher. Gibt die Version von Azure Blob Storage an, die zum Ausführen der Anforderung verwendet wird.
Date Ein UTC-Datums-/Uhrzeitwert, der die Uhrzeit angibt, zu der der Dienst die Antwort gesendet hat.
Content-Length Gibt die Länge des Anforderungstexts an. Bei diesem Vorgang ist die Inhaltslänge immer 0.
x-ms-sku-name Gibt den SKU-Namen des angegebenen Kontos an.
x-ms-account-kind Gibt die Kontoart des angegebenen Kontos an. Die möglichen Werte sind Storage, BlobStorage und StorageV2. Der Header unterscheidet zwischen Universell v1 (GPv1) und Universell v2 -Speicherkonten (GPv2), indem die Teilzeichenfolge V2 für GPv2-Konten verwendet wird.
x-ms-client-request-id Kann verwendet werden, um Anforderungen und entsprechende Antworten zu behandeln. Der Wert dieses Headers ist gleich dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist und der Wert höchstens 1.024 sichtbare ASCII-Zeichen aufweist. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist dieser Header in der Antwort nicht vorhanden.
x-ms-is-hns-enabled Version 2019-07-07 und höher. Gibt an, ob für das Konto ein hierarchischer Namespace aktiviert ist.

Antworttext

Keine.

Beispiel für eine Antwort

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Date: Sat, 28 Mar 2018 12:43:08 GMT  
x-ms-version: 2018-03-28  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
Content-Length: 0  
x-ms-sku-name: Standard_LRS  
x-ms-account-kind: StorageV2  

Authorization

Beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage ist eine Autorisierung erforderlich. Sie können den Get Account Information Vorgang wie unten beschrieben autorisieren.

Dieser Vorgang unterstützt keine OAuth-basierte Autorisierung über ein Zugriffstoken aus Azure Active Directory/MSI oder eine Benutzerdelegierungs-SAS.

Eine SAS (Shared Access Signature) bietet sicheren delegierten Zugriff auf Ressourcen in einem Speicherkonto. Mit einer SAS haben Sie eine präzise Kontrolle darüber, wie ein Client auf Daten zugreifen kann. Sie können angeben, auf welche Ressource der Client zugreifen darf, welche Berechtigungen er für diese Ressourcen hat und wie lange die SAS gültig ist.

Der Get Account Information Vorgang unterstützt die Autorisierung mithilfe einer Konto-SAS oder einer Dienst-SAS mit mindestens einer verfügbaren Berechtigung.

Konto-SAS

Eine Konto-SAS wird mit dem Speicherkontoschlüssel geschützt. Eine Konto-SAS delegiert den Zugriff auf Ressourcen in einem oder mehreren der Speicherdienste. Alle Vorgänge, die über eine Dienst-SAS oder eine SAS für die Benutzerdelegierung verfügbar sind, sind auch über eine Konto-SAS verfügbar.

Weitere Informationen zur Konto-SAS finden Sie unter Erstellen einer Konto-SAS.

Dienst-SAS

Eine Dienst-SAS wird mit dem Speicherkontoschlüssel geschützt. Eine Dienst-SAS delegiert den Zugriff auf eine Ressource in einem einzelnen Azure Storage-Dienst, z. B. Blob Storage.

Wenn der Zugriff auf gemeinsam genutzte Schlüssel für das Speicherkonto nicht zulässig ist, ist ein Dienst-SAS-Token für eine Anforderung an Blob Storage nicht zulässig. Weitere Informationen finden Sie unter Grundlegendes dazu, wie sich das Aufheben der Zuordnung von freigegebenem Schlüssel auf SAS-Token auswirkt.

Weitere Informationen zur Dienst-SAS finden Sie unter Erstellen einer Dienst-SAS.

Hinweise

Der URL-Pfad der Anforderung wirkt sich nicht auf die Informationen aus, die dieser Vorgang bereitstellt. Ihr Zweck besteht darin, der Anforderung die ordnungsgemäße Autorisierung mit einem SAS-Token zu ermöglichen, das die zulässige Ressource angibt.

Die angegebene Ressource muss nicht vorhanden sein, damit dieser Vorgang erfolgreich ist. Beispielsweise wird ein SAS-Token, das mit einem nicht vorhandenen Blob und gültigen Berechtigungen generiert wird, mit einem URL-Pfad erfolgreich ausgeführt, der den richtigen Kontonamen, den richtigen Containernamen und den Namen des nicht vorhandenen Blobs enthält.

Abrechnung

Preisanforderungen können von Clients stammen, die Blob Storage-APIs verwenden, entweder direkt über die Blob Storage-REST-API oder aus einer Azure Storage-Clientbibliothek. Für diese Anforderungen fallen Gebühren pro Transaktion an. Die Art der Transaktion wirkt sich auf die Belastung des Kontos aus. Beispielsweise werden Lesetransaktionen in eine andere Abrechnungskategorie als das Schreiben von Transaktionen angewendet. Die folgende Tabelle zeigt die Abrechnungskategorie für Get Account Information Anforderungen basierend auf dem Speicherkontotyp:

Vorgang Speicherkontotyp Abrechnungskategorie
Abrufen von Kontoinformationen Premium, Blockblob
Standard „Allgemein v2“
Weitere Vorgänge
Abrufen von Kontoinformationen Standard „Allgemein v1“ Dient zum Lesen von Vorgängen.

Weitere Informationen zu Preisen für die angegebene Abrechnungskategorie finden Sie unter Azure Blob Storage Preise.