(0) exportieren Drucken
Alle erweitern
Dieser Artikel wurde noch nicht bewertet - Dieses Thema bewerten.

Put Block List (REST-API)

Letzte Aktualisierung: November 2013

Der Put Block List-Vorgang schreibt ein BLOB, indem die Liste der Block-IDs angegeben wird, aus denen sich das BLOB zusammensetzt. Wenn ein Block als Teil eines BLOB geschrieben werden soll, muss er zuvor erfolgreich in einem Put Block (REST-API)-Vorgang auf den Server geschrieben worden sein.

Sie können Put Block List aufrufen, um ein BLOB zu aktualisieren, indem Sie nur die Blöcke mit Änderungen hochladen und anschließend für die neuen und vorhandenen Blöcke einen Commit ausführen. Dies erreichen Sie, indem Sie angeben, ob für einen Block aus der Liste der Blöcke mit ausgeführtem Commit oder der Liste der Blöcke ohne ausgeführten Commit ein Commit ausgeführt werden soll, oder ob für die zuletzt hochgeladene Version des Blocks ein Commit ausgeführt werden soll, je nachdem, in welcher Liste der Block enthalten ist.

Die Put Block List-Anforderung kann wie folgt erstellt werden. HTTPS wird empfohlen. Ersetzen Sie myaccount durch den Namen des Speicherkontos:

 

  Anforderungs-URI für PUT-Methode HTTP-Version

https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist

HTTP/1.1

URI des emulierten Speicherdiensts

Wenn Sie eine Anforderung für den emulierten Speicherdienst ausführen, geben Sie den Emulatorhostnamen und den Port des Blob-Diensts mit 127.0.0.1:10000 an, gefolgt vom Namen des emulierten Speicherkontos:

 

  Anforderungs-URI für PUT-Methode HTTP-Version

http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist

HTTP/1.1

Beachten Sie, dass der Speicheremulator nur BLOB-Größen bis zu 2 GB unterstützt.

Weitere Informationen finden Sie unter About Development Storage und Unterschiede zwischen dem Speicheremulator und den Windows Azure-Speicherdiensten.

URI-Parameter

Im Anforderungs-URI können die folgenden zusätzlichen Parameter angegeben werden.

 

Parameter Beschreibung

timeout

Optional. Der timeout-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob-Dienstvorgänge.

Anforderungsheader

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

 

Anforderungsheader Beschreibung

Authorization

Erforderlich. Gibt das Authentifizierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Authentifizierung für die Windows Azure-Speicherdienste.

Date - oder - x-ms-date

Erforderlich. Gibt die Uhrzeit der Anforderung in koordinierter Weltzeit (UTC) an. Weitere Informationen finden Sie unter Authentifizierung für die Windows Azure-Speicherdienste.

x-ms-version

Erforderlich für alle authentifizierten Anforderungen. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für den Blob-Dienst, den Warteschlangendienst und den Tabellendienst in Windows Azure.

Content-Length

Erforderlich. Die Länge des Anforderungsinhalts in Byte. Beachten Sie, dass dieser Header auf die Inhaltslänge der Liste der Blöcke und nicht auf die des BLOB selbst verweist.

Content-MD5

Optional. Ein MD5-Hash des Anforderungsinhalts. Mithilfe des Hash wird die Integrität des Anforderungsinhalts während der Übertragung überprüft. Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl.

Beachten Sie, dass dieser Header dem Anforderungsinhalt und nicht dem Inhalt des BLOB selbst zugeordnet ist.

x-ms-blob-cache-control

Optional. Legt das Cachesteuerelement des BLOB fest. Sofern angegeben, wird diese Eigenschaft mit dem BLOB gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn diese Eigenschaft nicht mit der Anforderung angegeben ist, wird sie für das BLOB gelöscht, wenn die Anforderung erfolgreich ausgeführt wurde.

x-ms-blob-content-type

Optional. Legt den Inhaltstyp des BLOB fest. Sofern angegeben, wird diese Eigenschaft mit dem BLOB gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn der Inhaltstyp nicht angegeben ist, wird er auf den Standardwert application/octet-stream festgelegt.

x-ms-blob-content-encoding

Optional. Legt die Inhaltscodierung des BLOB fest. Sofern angegeben, wird diese Eigenschaft mit dem BLOB gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn diese Eigenschaft nicht mit der Anforderung angegeben ist, wird sie für das BLOB gelöscht, wenn die Anforderung erfolgreich ausgeführt wurde.

x-ms-blob-content-language

Optional. Legt die Sprache für den Inhalt des BLOB fest. Sofern angegeben, wird diese Eigenschaft mit dem BLOB gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn diese Eigenschaft nicht mit der Anforderung angegeben ist, wird sie für das BLOB gelöscht, wenn die Anforderung erfolgreich ausgeführt wurde.

x-ms-blob-content-md5

Optional. Ein MD5-Hash des BLOB-Inhalts. Beachten Sie, dass dieser Hash nicht überprüft wird, da die Hashes für die einzelnen Blöcke beim Hochladen der Blöcke überprüft wurden.

Der Get Blob (REST-API) Vorgang gibt den Wert dieses Headers im Content-MD5-Antwortheader zurück.

Wenn diese Eigenschaft nicht mit der Anforderung angegeben ist, wird sie für das BLOB gelöscht, wenn die Anforderung erfolgreich ausgeführt wurde.

x-ms-meta-name:value

Optional. Benutzerdefinierte Name-Wert-Paare, die dem BLOB zugeordnet sind.

Beachten Sie, dass ab Version 2009-09-19 Metadatennamen den Benennungsregeln für C#-Bezeichner entsprechen müssen.

x-ms-lease-id:<ID>

Erforderlich, wenn das BLOB über eine aktive Lease verfügt. Um diesen Vorgang für ein BLOB mit einer aktiven Lease auszuführen, geben Sie die gültige Lease-ID für diesen Header an.

x-ms-client-request-id

Optional. Stellt einen vom Client generierten, nicht transparenten Wert mit einer Zeichenbeschränkung von 1 KB bereit, der bei Aktivierung der Speicheranalyse-Protokollierung in den Analyseprotokollen erfasst wird. Die Verwendung dieses Headers wird dringend empfohlen, um clientseitige Aktivitäten mit den vom Server empfangenen Anforderungen zu korrelieren. Weitere Informationen finden Sie unter Informationen zur Protokollierung durch die Speicheranalyse und Windows Azure-Speicherprotokollierung: Verwenden von Protokollen zur Nachverfolgung von Speicheranforderungen.

Dieser Vorgang unterstützt zudem die Verwendung von bedingten Headern zum Ausführen eines Commits für das BLOB; hierfür muss jedoch eine angegebene Bedingung erfüllt sein. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Vorgänge des Blob-Diensts.

Anforderungstext

Im Anforderungstext können Sie angeben, welche Blockliste der Blob-Dienst für den angeforderten Block überprüfen soll. Auf diese Weise können Sie ein vorhandenes BLOB aktualisieren, indem Sie einzelne Blöcke einfügen, ersetzen oder löschen, anstatt das gesamte BLOB erneut hochzuladen. Sobald Sie den geänderten Block bzw. die geänderten Blöcke hochgeladen haben, können Sie einen Commit einer neuen Version des BLOB ausführen, indem einen Commit für die neuen Blöcke und die vorhandenen, beizubehaltenden Blöcke ausführen.

Zum Aktualisieren eines BLOB können Sie angeben, dass der Dienst in der Liste der Blöcke mit ausgeführtem Commit, in der Liste der Blöcke ohne ausgeführten Commit oder zuerst in der Liste der Blöcke ohne ausgeführten Commit und anschließend in der Liste der Blöcke mit ausgeführtem Commit nach einer Block-ID suchen soll. Geben Sie zum Festlegen der gewünschten Vorgehensweise wie folgt die Block-ID im entsprechenden XML-Element im Anforderungstext an:

  • Geben Sie die Block-ID im Committed-Element an, um anzugeben, dass der Blob-Dienst nur die Liste der Blöcke mit ausgeführtem Commit nach dem benannten Block durchsuchen soll. Wird der Block nicht in der Liste der Blöcke mit ausgeführtem Commit gefunden, wird er nicht als Teil des BLOB geschrieben, und der Blob-Dienst gibt Statuscode 400 (Ungültige Anforderung) zurück.

  • Geben Sie die Block-ID im Uncommitted-Element an, um anzugeben, dass der Blob-Dienst nur die Liste der Blöcke ohne ausgeführten Commit nach dem benannten Block durchsuchen soll. Wird der Block nicht in der Liste der Blöcke ohne ausgeführten Commit gefunden, wird er nicht als Teil des BLOB geschrieben, und der Blob-Dienst gibt Statuscode 400 (Ungültige Anforderung) zurück.

  • Geben Sie die Block-ID im Latest-Element an, um anzugeben, dass der Blob-Dienst zuerst die Liste der Blöcke ohne ausgeführten Commit durchsuchen soll. Wird der Block nicht in der Liste der Blöcke ohne ausgeführten Commit gefunden, handelt es sich bei dieser Version des Blocks um die aktuelle Version, die in das BLOB geschrieben werden sollte. Wird der Block nicht in der Liste der Blöcke ohne ausgeführten Commit gefunden, durchsucht der Dienst die Liste der Blöcke mit ausgeführtem Commit nach dem benannten Block und schreibt den Block in das BLOB, sofern er gefunden wird.

Der Anforderungstext für diese Version von Put Block List verwendet folgendes XML-Format:

<?xml version="1.0" encoding="utf-8"?>
<BlockList>
  <Committed>first-base64-encoded-block-id</Committed>
  <Uncommitted>second-base64-encoded-block-id</Uncommitted>
  <Latest>third-base64-encoded-block-id</Latest>
  ...
</BlockList>

Beispielanforderung

Zur Veranschaulichung von Put Block List wird angenommen, dass drei Blöcke hochgeladen wurden, für die ein Commit ausgeführt werden soll. Im folgenden Beispiel wird ein Commit für ein neues BLOB ausgeführt. Dabei wird angegeben, dass die neueste Version jedes aufgelisteten Blocks verwendet werden soll. Dabei muss nicht bekannt sein, ob bereits ein Commit für diese Blöcke ausgeführt wurde.


Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1

Request Headers:
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT
x-ms-version: 2011-08-18
Content-Type: text/plain; charset=UTF-8
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=
Content-Length: 133

Request Body:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
  <Latest>AAAAAA==</Latest>
  <Latest>AQAAAA==</Latest>
  <Latest>AZAAAA==</Latest>
</BlockList>

Nehmen wir als Nächstes an, dass Sie das BLOB aktualisieren möchten. Das neue BLOB weist die folgenden Änderungen auf:

  • Ein neuer Block mit der ID ANAAAA==. Dieser Block muss zunächst mit einem Aufruf von Put Block (REST-API) hochgeladen werden, und er wird bis zum Aufruf von Put Block List in der Liste der Blöcke ohne ausgeführten Commit angezeigt.

  • Eine aktualisierte Version des Blocks mit der ID AZAAAA==. Dieser Block muss zunächst mit einem Aufruf von Put Block (REST-API) hochgeladen werden, und er wird bis zum Aufruf von Put Block List in der Liste der Blöcke ohne ausgeführten Commit angezeigt.

  • Entfernen des Blocks mit der ID AAAAAA==. Angesichts des Umstands, dass dieser Block nicht im nächsten Aufruf von Put Block List enthalten ist, wird der Block effektiv aus dem BLOB entfernt.

Im folgenden Beispiel wird der Aufruf von Put Block List veranschaulicht, durch den das BLOB aktualisiert wird:


Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1

Request Headers:
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT
x-ms-version: 2011-08-18
Content-Type: text/plain; charset=UTF-8
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=
Content-Length: 133

Request Body:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
  <Uncommitted>ANAAAA==</Uncommitted>
  <Committed>AQAAAA==</Committed>
  <Uncommitted>AZAAAA==</Uncommitted>
</BlockList>

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

Statuscode

Bei einem erfolgreichen Vorgang wird der Statuscode 201 (Erstellt) zurückgegeben.

Weitere Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.

Antwortheader

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort kann außerdem weitere HTTP-Standardheader enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

 

Antwort Beschreibungen

ETag

Das Entitätstag enthält einen Wert, den der Client zum Ausführen von bedingten GET/PUT-Vorgängen mit dem If-Match-Anforderungsheader verwenden kann. Wenn die Anforderungsversion 2011-08-18 oder höher ist, wird der ETag-Wert in Anführungszeichen eingeschlossen.

Last-Modified

Datum/Uhrzeit der letzten Änderung des BLOB. Das Datumsformat entspricht RFC 1123. Weitere Informationen finden Sie unter Darstellung von Datums-/Uhrzeitwerten in Headern.

Durch jeden Vorgang, der das BLOB ändert, einschließlich eines Updates der Metadaten oder Eigenschaften des BLOB, wird der Zeitpunkt der letzten Änderung aktualisiert.

Content-MD5

Dieser Header wird zurückgegeben, damit der Client die Integrität des Nachrichteninhalts überprüfen kann. Dieser Header verweist auf den Inhalt der Anforderung (d. h. in diesem Fall auf die Liste der Blöcke) und nicht auf den Inhalt des BLOB selbst.

x-ms-request-id

Dieser Header identifiziert die erfolgte Anforderung eindeutig und kann für die Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.

x-ms-version

Gibt die Version des Blob-Diensts an, der zum Ausführen der Abfrage verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher erfolgen.

Date

Ein vom Dienst generierter Datums-/Uhrzeitwert in UTC, der angibt, wann die Antwort initiiert wurde.

Beispielantwort

Response Status:
HTTP/1.1 201 Created

Response Headers:
Transfer-Encoding: chunked
Content-MD5: oafL1+HS78x65+e39PGIIg==
Date: Sun, 25 Sep 2011 00:17:44 GMT
ETag: “0x8CB172A360EC34B”
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT
x-ms-version: 2011-08-18
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Dieser Vorgang kann vom Kontobesitzer und von einem Benutzer mit einer SAS (Shared Access Signature) aufgerufen werden, der über die Berechtigung verfügt, in dieses BLOB oder den Container zu schreiben.

Der Put Block List-Vorgang erzwingt die Reihenfolge, in der Blöcke zusammengestellt werden, um ein BLOB zu erstellen.

In der Liste der Blöcke kann ein und dieselbe Block-ID mehrmals angegeben werden. Wenn eine Block-ID mehrmals angegeben ist, stellt sie den Bereich von Bytes an jeder dieser Positionen in der Liste der Blöcke für das endgültige BLOB mit ausgeführtem Commit dar. Wenn eine Block-ID mehr als einmal in der Liste enthalten ist, müssen beide Instanzen der Block-ID innerhalb derselben Liste der Blöcke angegeben werden. Das heißt, beide Instanzen müssen im Committed-Element, im Uncommitted-Element oder im Latest-Element angegeben werden.

Mit Put Block List können Sie ein vorhandenes BLOB ändern, indem Sie einzelne Blöcke einfügen, aktualisieren oder löschen, ohne dass das gesamte BLOB erneut hochgeladen werden muss. Sie können Block-IDs aus der aktuellen Liste der Blöcke mit ausgeführtem Commit und der Liste der Blöcke ohne ausgeführten Commit angeben, um ein neues BLOB zu erstellen oder um den vorhandenen Inhalt eines BLOB zu aktualisieren. Auf diese Weise können Sie ein BLOB aktualisieren, indem Sie einige neue Blöcke aus der Liste der Blöcke ohne ausgeführten Commit und die Blöcke aus der Liste der Blöcke mit ausgeführtem Commit angeben, die bereits Teil des vorhandenen BLOB sind.

Wenn eine Block-ID im Latest-Element angegeben ist und die gleiche Block-ID in der Liste der Blöcke mit ausgeführtem Commit und der Liste der Blöcke ohne ausgeführten Commit vorhanden ist, wird von Put Block List ein Commit für den Block aus der Liste der Blöcke ohne ausgeführten Commit ausgeführt. Wenn die Block-ID in der Liste der Blöcke mit ausgeführtem Commit, jedoch nicht in der Liste der Blöcke ohne ausgeführten Commit enthalten ist, führt Put Block List einen Commit für den Block aus der Liste der Blöcke mit ausgeführtem Commit aus.

Die maximale Anzahl der Blöcke, für die ein Commit ausgeführt werden kann, beträgt 50.000, und die maximale Größe eines BLOB, für den über den Put Block List-Vorgang ein Commit ausgeführt werden kann, beträgt 200 GB. Wenn Sie versuchen, für mehr als 50.000 Blöcke einen Commit auszuführen, gibt der Dienst Statuscode 413 (Anforderungsentität ist zu groß) zurück. Der Dienst gibt in der Antwort auch weitere Informationen zum Fehler zurück, u. a. die maximal zulässige Anzahl von Blöcken.

Die maximale Anzahl der Blöcke ohne ausgeführten Commit, die einem BLOB zugeordnet werden können, beträgt 100.000, und die maximale Größe der Liste der Blöcke ohne ausgeführten Commit ist 400 GB.

Wenn Sie Put Block List aufrufen, um ein vorhandenes BLOB zu aktualisieren, werden die vorhandenen Eigenschaften und Metadaten des BLOB überschrieben. Alle vorhandenen Momentaufnahmen werden jedoch mit dem BLOB beibehalten. Sie können mithilfe der bedingten Anforderungsheader den Vorgang nur dann ausführen, wenn eine bestimmte Bedingung erfüllt ist.

Wenn der Put Block List-Vorgang aufgrund eines fehlenden Blocks fehlschlägt, müssen Sie den fehlenden Block hochladen.

Alle Blöcke ohne ausgeführten Commit werden vom Garbage Collector erfasst, wenn für das BLOB innerhalb einer Woche nach dem letzten erfolgreichen Put Block-Vorgang keine erfolgreichen Aufrufe von Put Block oder Put Block List erfolgen. Wenn Put Blob (REST-API) für das BLOB aufgerufen wird, werden alle Blöcke ohne ausgeführten Commit vom Garbage Collector erfasst.

Wenn das BLOB über eine aktive Lease verfügt, muss der Client zum Ausführen eines Commits der Liste der Blöcke eine gültige Lease-ID in der Anforderung angeben. Wenn der Client keine Lease-ID oder eine ungültige Lease-ID angibt, gibt der Blob-Dienst den Statuscode 412 (Vorbedingung nicht erfüllt) zurück. Wenn der Client eine Lease-ID angibt, aber das BLOB nicht über eine aktive Lease verfügt, gibt der Blob-Dienst ebenfalls Statuscode 412 (Vorbedingung nicht erfüllt) zurück. Wenn der Client eine Lease-ID für ein BLOB angibt, das noch nicht vorhanden ist, gibt der Blob-Dienst den Statuscode 412 (Vorbedingung nicht erfüllt) für Anforderungen zurück, die für Version 2013-08-15 und höher ausgeführt werden; für frühere Versionen gibt der Blob-Dienst den Statuscode 201 (Erstellt) zurück.

Wenn das BLOB über eine aktive Lease verfügt und Sie Put Block List zum Aktualisieren des BLOB aufrufen, wird die Lease für das aktualisierte BLOB beibehalten.

Put Block List ist nur für Block-BLOBs anwendbar. Der Aufruf von Put Block List für ein Seitenblob führt zum Statuscode 400 (Ungültige Anforderung).

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2014 Microsoft. Alle Rechte vorbehalten.