Exportieren (0) Drucken
Alle erweitern

Referenz zur REST-API der Speicherdienste

Letzte Aktualisierung: Dezember 2014

Die REST-APIs für die Windows® Azure™-Speicherdienste ermöglichen über den Speicheremulator den programmgesteuerten Zugriff auf die BLOB-, Warteschlangen-, Tabellen- und Dateidienste in Azure oder in der Entwicklungsumgebung.

Ü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.

ImportantWichtig
Die Azure-Speicherdienste unterstützen HTTP und HTTPS; die Verwendung von HTTPS wird jedoch dringend empfohlen.

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 außerdem die Grundlage für die Authentifizierung.

Die REST-APIs für Speicherdienste machen das Speicherkonto als Ressource verfügbar.

Informationen zum Erstellen und Verwalten eines Speicherkontos finden Sie unter Verwalten von Konten, Abonnements und Administratorrollen.

Der Blob-Dienst stellt Speicher für Entitäten, z. B. Binärdateien und Textdateien, bereit. Die REST-API für den BLOB-Dienst stellt zwei Ressourcen bereit: Container und BLOBs. Ein Container ist ein Satz von BLOBs. Jedes BLOB muss zu einem Container gehören. Der Blob-Dienst definiert zwei Typen von BLOBs:

  • 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.

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. Beispielsweise beinhalten die BLOB-Namen MyGroup/MyBlob1 und MyGroup/MyBlob2 eine virtuelle Organisationsebene 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. Beispielsweise können Sie alle BLOBs aufzählen, die unter MyGroup/ organisiert sind.

Es gibt zwei Arten, einen Block-BLOB zu erstellen. Block-BLOBs mit einer Größe von bis zu 64 MB können durch Aufruf des Put Blob (REST-API)-Vorgangs hochgeladen werden. Block-BLOBs mit einer Größe von über 64 MB müssen als Satz von Blöcken hochgeladen werden, die jeweils kleiner oder gleich 4 MB groß sind. Ein Satz erfolgreich hochgeladener Blöcke kann durch Aufruf von Put Block List (REST-API) in einer bestimmten Reihenfolge in einem einzelnen zusammenhängenden BLOB assembliert werden. Die derzeit unterstützte maximale Größe für ein Block-BLOB beträgt 200 GB.

Seiten-BLOBs werden durch Aufruf von Put Blob (REST-API) mit einer maximalen Größe erstellt und initialisiert. Um den Inhalt in ein Seiten-BLOB zu schreiben, rufen Sie den Put Page (REST-API)-Vorgang auf. Die derzeit unterstützte maximale Größe für ein Seiten-BLOB beträgt 1 TB.

BLOBs unterstützen bedingte Updatevorgänge, die für Parallelitätssteuerung und effizientes Hochladen hilfreich sein können.

BLOBs können durch Aufruf des Get Blob (REST-API)-Vorgangs gelesen werden. Ein Client kann das gesamte BLOB oder einen beliebigen Bereich von Bytes lesen.

Die API-Referenz für den Blob-Dienst finden Sie unter REST-API des Blob-Diensts.

Der Warteschlangendienst stellt zuverlässiges, persistentes Messaging innerhalb von Diensten und zwischen Diensten bereit. Die REST-API für den Warteschlangendienst stellt zwei Ressourcen bereit: 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 in Version 2011-08-18 auf 64 KB und in früheren Versionen auf 8 KB 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 REST-API des Warteschlangendiensts.

Der Tabellendienst stellt strukturierten Speicher in Form von Tabellen bereit. Der Tabellendienst unterstützt eine REST-API, die das OData-Protokoll implementiert.

Ein Entwickler kann in einem Speicherkonto benannte 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.

Das SMB (Server Message Block)-Protokoll ist derzeit das bevorzugt für lokale Dateifreigaben verwendete Protokoll. 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: 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.

Siehe auch

Anzeigen:
© 2015 Microsoft