Ajouter un sceau d’objet blob
L’objectif de l’opération Append Blob Seal
est de permettre aux utilisateurs et aux applications de sceller des objets blob d’ajout, en les marquant comme en lecture seule. Ce document décrit les spécifications de l’API REST proposées pour cette fonctionnalité.
Requête
Vous pouvez construire la Append Blob Seal
requête comme suit. HTTPS est recommandé. Remplacez myaccount
par le nom de votre compte de stockage.
URI de requête de méthode PUT | Version HTTP |
---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=seal |
HTTP/1.1 |
En-têtes
Append Blob Seal
retourne des en-têtes d’API courants, ETag
/LMT
(heure de la dernière modification), x-ms-request-id
, x-ms-version
, content-length
et .Date
Append Blob Seal
ne modifie pas le ETag
/LMT
.
En-tête de réponse | Valeur | Description |
---|---|---|
x-ms-blob-sealed |
true/false | facultatif. False par défaut. Si l’objet blob est scellé, cet en-tête est inclus dans la réponse lorsque vous scellez et obtenez les propriétés d’un objet blob. Cet en-tête doit apparaître dans GetBlob , GetBlobProperties , AppendBlobSeal et ListBlobs pour les objets blob d’ajout. |
Paramètres de requête
Aucun paramètre d’URI supplémentaire.
Corps de la demande
Aucun.
response
La réponse inclut un code de status HTTP et une liste d’en-têtes de réponse.
Code d’état
Vous pouvez recevoir l’un des codes status suivants :
200 (Réussite) : l’objet blob est scellé. L’appel est idempotent et réussit si l’objet blob est déjà scellé.
409 (InvalidBlobType) : le service retourne ce code status si l’appel se trouve sur un objet blob de pages ou un objet blob de blocs existant.
404 (BlobNotFound) : le service retourne ce code status si l’appel se trouve sur un objet blob inexistant.
Autorisation
Une autorisation est requise lors de l’appel d’une opération d’accès aux données dans stockage Azure. Vous pouvez autoriser l’opération Append Blob Seal
comme décrit ci-dessous.
Important
Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour autoriser les demandes dans le stockage Azure. Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures par rapport à l’autorisation de clé partagée.
Le Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les demandes de données blob. Avec Microsoft Entra ID, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée Azure. Le principal de sécurité est authentifié par Microsoft Entra ID pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une requête auprès du service BLOB.
Pour en savoir plus sur l’autorisation à l’aide de Microsoft Entra ID, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID.
Autorisations
Vous trouverez ci-dessous l’action RBAC nécessaire pour qu’un utilisateur, un groupe, une identité managée ou un principal de service Microsoft Entra appelle l’opérationAppend Blob Seal
, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :
- Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- Rôle intégré avec privilèges minimum :Contributeur aux données Blob de stockage
Pour en savoir plus sur l’attribution de rôles à l’aide d’Azure RBAC, consultez Attribuer un rôle Azure pour accéder aux données blob.
Remarques
Si un objet blob d’ajout a un bail, vous avez besoin d’un ID de bail pour sceller l’objet blob.
Une fois que vous avez scellé un objet blob, vous pouvez toujours mettre à jour les propriétés, les balises d’index d’objet blob et les métadonnées. La suppression réversible d’un objet blob scellé conserve l’état scellé. Vous pouvez remplacer les objets blob scellés.
Si vous prenez une instantané d’un objet blob scellé, le instantané inclut l’indicateur scellé. Pour les instantanés existants dans la nouvelle version, Microsoft retourne la propriété .
Lorsque vous copiez un objet blob scellé, l’indicateur scellé est propagé par défaut. Un en-tête est exposé qui permet de remplacer l’indicateur.
Un nouvel élément XML est ajouté à la ListBlob
réponse, nommé Sealed
. La valeur peut être true
ou false
.
Si vous appelez AppendBlock
sur un objet blob déjà scellé, le service retourne le message d’erreur indiqué dans le tableau suivant. Cela s’applique aux versions antérieures de l’API.
Code d’erreur | Code d’état HTTP | Message utilisateur |
---|---|---|
BlobIsSealed | Conflit (409) | L’objet blob spécifié est scellé et son contenu ne peut pas être modifié, sauf si l’objet blob est recréé après une suppression. |
Si vous appelez Append Blob Seal
sur un objet blob d’ajout qui a déjà été scellé, vous voyez simplement un code status de 200 (Réussite).
Facturation
Les demandes de tarification peuvent provenir de clients qui utilisent les API Stockage Blob, soit directement via l’API REST Stockage Blob, soit à partir d’une bibliothèque cliente stockage Azure. Ces demandes accumulent des frais par transaction. Le type de transaction affecte la façon dont le compte est facturé. Par exemple, les transactions de lecture s’accumulent dans une catégorie de facturation différente de celle des transactions d’écriture. Le tableau suivant montre la catégorie de facturation pour Append Blob Seal
les demandes en fonction du type de compte de stockage :
Opération | Type de compte de stockage | Catégorie de facturation |
---|---|---|
Ajouter un sceau d’objet blob | Objet blob de blocs Premium Usage général v2 Standard Usage général v1 standard |
Opérations d’écriture |
Pour en savoir plus sur la tarification de la catégorie de facturation spécifiée, consultez tarification Stockage Blob Azure.