Referenz zur Azure Storage-REST-API
Die REST-APIs für die Microsoft Azure Storage-Dienste bieten programmgesteuerten Zugriff auf die Blob-, Warteschlangen-, Tabellen- und Dateidienste in Azure oder in der Entwicklungsumgebung (über den Speicheremulator).
Über REST-APIs kann auf alle Speicherdienste zugegriffen werden. Der Zugriff auf Speicherdienste kann aus einem Dienst in Azure oder direkt über das Internet aus einer beliebigen Anwendung erfolgen, die eine HTTP-/HTTPS-Anforderung senden und empfangen kann.
Wichtig
Die Azure-Speicherdienste unterstützen HTTP und HTTPS; die Verwendung von HTTPS wird jedoch dringend empfohlen.
Speicherkonto
Sämtlicher Zugriff auf Speicherdienste erfolgt über das Speicherkonto. Das Speicherkonto ist die höchste Ebene des Namespaces für den Zugriff auf die einzelnen grundlegenden Dienste. Es ist auch die Grundlage für die Autorisierung.
Die REST-APIs für Speicherdienste machen das Speicherkonto als Ressource verfügbar.
Blob-Dienst
Der Blob-Dienst stellt Speicher für Entitäten, z. B. Binärdateien und Textdateien, bereit. Die REST-API für den Blob-Dienst macht zwei Ressourcen verfügbar: Container und BLOBs. Ein Container ist wie ein Ordner, der eine Reihe von Blobs enthält. Jedes Blob muss sich in einem Container befinden. Der Blobdienst definiert drei Blobtypen:
Block-BLOBs, die zum Streamen optimiert sind. Dies ist der einzige BLOB-Typ, der in Versionen vor 2009-09-19 verfügbar ist.
Seiten-BLOBs, die für zufällige Lese-/Schreibvorgänge optimiert sind und es ermöglichen, in einen Bereich von Bytes in einem BLOB zu schreiben. Seitenblobs sind ab Version 2009-09-19 verfügbar. Diese werden in erster Linie für die VHD-Dateien verwendet, die die AzureVMs sichern.
Anfügeblobs, die nur für Anfügevorgänge optimiert sind. Anfügeblobs sind nur ab Version 2015-02-21 verfügbar.
Container und BLOBs unterstützen benutzerdefinierte Metadaten in Form von Name-Wert-Paaren, die als Header in einem Anforderungsvorgang angegeben werden.
Entwickler können mit der REST-API für den Blob-Dienst einen hierarchischen Namespace erstellen, der einem Dateisystem ähnelt. In BLOB-Namen kann mit einem konfigurierbaren Pfadtrennzeichen eine Hierarchie codiert werden. Die Blobnamen MyGroup/MyBlob1 und MyGroup/MyBlob2 impliziert beispielsweise eine virtuelle Ebene von organization für Blobs. Bei der Enumeration von BLOBs kann die virtuelle Hierarchie auf ähnliche Weise wie das Dateisystem durchlaufen werden, sodass ein Satz von BLOBs zurückgegebenen werden kann, die unter einer Gruppe angeordnet sind. Sie können beispielsweise alle Blobs aufzählen, die unter MyGroup/ organisiert sind.
Es gibt zwei Arten, einen Block-BLOB zu erstellen. Sie können ein Blob mit einem einzelnen Put Blob-Vorgang hochladen, oder Sie können ein Blob als Satz von Blöcken mit einem Put Block-Vorgang hochladen und die Blöcke mit einem Put Block List-Vorgang in ein Blob committen.
Seitenblobs werden erstellt und mit einer maximalen Größe mit einem Aufruf von Put Blob initialisiert. Um Inhalte in ein Seitenblob zu schreiben, rufen Sie den Vorgang Seite einfügen auf.
Anfügeblobs können durch Aufrufen von Put Blob erstellt werden. Ein Anfügeblob, das mit dem Vorgang Blob put erstellt wurde, enthält keinen Inhalt. Um Inhalte in ein Anfügeblob zu schreiben, fügen Sie Blöcke am Ende des Blobs hinzu, indem Sie den Vorgang Block anfügen aufrufen . Das Aktualisieren oder Löschen vorhandener Blöcke wird nicht unterstützt. Jeder Block kann eine unterschiedliche Größe haben, bis zu einem Maximum von 4 MiB. Die maximale Größe für ein Anfügeblob beträgt 195 GiB, und ein Anfügeblob darf maximal 50.000 Blöcke enthalten.
BLOBs unterstützen bedingte Updatevorgänge, die für Parallelitätssteuerung und effizientes Hochladen hilfreich sein können.
Blobs können durch Aufrufen des Vorgangs Blob abrufen gelesen werden. Ein Client kann das gesamte BLOB oder einen beliebigen Bereich von Bytes lesen.
Die Referenz zur Blobdienst-API finden Sie unter Blob Service REST API.
Warteschlangendienst
Der Warteschlangendienst stellt zuverlässiges, persistentes Messaging innerhalb von Diensten und zwischen Diensten bereit. Die REST-API für den Warteschlangendienst macht zwei Ressourcen verfügbar: Warteschlangen und Nachrichten.
Warteschlangen unterstützen benutzerdefinierte Metadaten in Form von Name-Wert-Paaren, die als Header in einem Anforderungsvorgang angegeben werden.
Jedes Speicherkonto kann über eine unbegrenzte Anzahl von Nachrichtenwarteschlangen verfügen, die innerhalb des Kontos eindeutig benannt sind. Jede Nachrichtenwarteschlange kann eine unbegrenzte Anzahl von Nachrichten enthalten. Die maximale Größe für eine Nachricht ist auf 64 KiB für Version 2011-08-18 und 8 KiB für frühere Versionen beschränkt.
Wenn eine Nachricht aus der Warteschlange gelesen wird, muss der Consumer die Nachricht verarbeiten und dann löschen. Nachdem die Nachricht gelesen wurde, wird sie während eines angegebenen Intervalls für andere Consumer nicht sichtbar gemacht. Wenn die Nachricht bei Ablauf des Intervalls noch nicht gelöscht wurde, wird ihre Sichtbarkeit wiederhergestellt, damit sie von einem anderen Consumer verarbeitet werden kann.
Weitere Informationen zum Warteschlangendienst finden Sie unter Warteschlangendienst-REST-API.
Tabellendienst
Der Tabellendienst stellt strukturierten Speicher in Form von Tabellen bereit. Der Tabellendienst unterstützt eine REST-API, die das OData-Protokoll implementiert.
Innerhalb eines Speicherkontos kann ein Entwickler Tabellen erstellen. In Tabellen werden Daten als Entitäten gespeichert. Eine Entität ist ähnlich wie eine Zeile eine Auflistung benannter Eigenschaften und ihrer Werte. Tabellen sind partitioniert, um den Lastenausgleich zwischen verschiedenen Speicherknoten zu unterstützen. Jede Tabelle weist als erste Eigenschaft einen Partitionsschlüssel auf, der die Partition angibt, zu der eine Entität gehört. Die zweite Eigenschaft ist ein Zeilenschlüssel, der eine Entität in einer bestimmten Partition angibt. Die Kombination von Partitionsschlüssel und Zeilenschlüssel bildet einen Primärschlüssel, der jede Entität in der Tabelle eindeutig identifiziert.
Der Tabellendienst erzwingt kein Schema. Entwickler können ein Schema clientseitig implementieren und erzwingen. Weitere Informationen zum Tabellendienst finden Sie unter Tabellendienst-REST-API.
Dateidienst
Das SMB-Protokoll (Server Message Block) ist das bevorzugte Dateifreigabeprotokoll, das heute lokal verwendet wird. Dank dem Microsoft Azure-Dateidienst können Kunden die Verfügbarkeit und Skalierbarkeit des IaaS (Infrastructure as a Service)-SMBs der Azure-Cloud nutzen, ohne dass SMB-Clientanwendungen umgeschrieben werden müssen.
Der Azure-Dateidienst bietet zudem eine attraktive Alternative zu herkömmlichen DAS (Direct Attached Storage)- und SAN (Storage Area Network)-Lösungen, deren Installation, Konfiguration und Ausführung häufig komplex und teuer ist.
In Azure-Dateidienstfreigaben gespeicherte Dateien sind über das SMB-Protokoll sowie über REST-APIs verfügbar. Der Dateidienst bietet die folgenden vier Ressourcen: das Speicherkonto, Freigaben, Verzeichnisse und Dateien. Freigaben bieten die Möglichkeit, Dateisätze zu organisieren und können außerdem als SMB-Dateifreigabe bereitgestellt werden, die in der Cloud gehostet wird.
Weitere Informationen
Rest-API-Rest-API-Rest-API-Tabellendienst des Blob-Diensts REST-API-Dateidienst-REST-API