Partager via


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 Sealretourne des en-têtes d’API courants, ETag/LMT (heure de la dernière modification), x-ms-request-id, x-ms-version, content-lengthet .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, AppendBlobSealet 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 :

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.

Voir aussi

codes d’erreur Stockage Blob Azure