Sello de blobs en anexos
El propósito de la Append Blob Seal operación es permitir que los usuarios y las aplicaciones cierren blobs en anexos, lo que los marca como de solo lectura. En este documento se describen las especificaciones de la API REST propuestas para esta característica.
Solicitud
Puede construir la solicitud de la Append Blob Seal siguiente manera. Se recomienda HTTPS. Reemplace myaccount por el nombre de la cuenta de almacenamiento.
| URI de solicitud de método PUT | Versión de HTTP |
|---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=seal |
HTTP/1.1 |
Encabezados
Append Blob Sealdevuelve encabezados de API comunes( ETag/LMT (hora de última modificación), x-ms-request-id, x-ms-versioncontent-length, y .Date
Append Blob Sealno cambia .ETag/LMT
| Encabezado de respuesta | Valor | Descripción |
|---|---|---|
x-ms-blob-sealed |
true/false | Opcional. El valor predeterminado es false. Si el blob está sellado, este encabezado se incluye en la respuesta al sellar y obtener propiedades de un blob. Este encabezado debe aparecer en GetBlob, GetBlobProperties, AppendBlobSealy ListBlobs para blobs en anexos. |
Parámetros de consulta
No hay parámetros de URI adicionales.
Cuerpo de la solicitud
Ninguno.
Response
La respuesta incluye un código de estado HTTP y una lista de encabezados de respuesta.
status code
Puede recibir cualquiera de los siguientes códigos de estado:
200 (correcto): el blob está sellado. La llamada es idempotente y se realizará correctamente si el blob ya está sellado.
409 (InvalidBlobType): el servicio devuelve este código de estado si la llamada está en un blob en páginas o blob en bloques existente.
404 (BlobNotFound): el servicio devuelve este código de estado si la llamada está en un blob no existente.
Authorization
La autorización es necesaria al llamar a cualquier operación de acceso a datos en Azure Storage. Puede autorizar la Append Blob Seal operación como se describe a continuación.
Importante
Microsoft recomienda usar Microsoft Entra ID con identidades administradas para autorizar solicitudes a Azure Storage. Microsoft Entra ID proporciona una mayor seguridad y facilidad de uso en comparación con la autorización de clave compartida.
Azure Storage admite el uso de Microsoft Entra ID para autorizar solicitudes a datos de blobs. Con Microsoft Entra ID, puede usar el control de acceso basado en rol de Azure (RBAC de Azure) para conceder permisos a una entidad de seguridad. La entidad de seguridad puede ser un usuario, un grupo, una entidad de servicio de aplicación o una identidad administrada de Azure. La entidad de seguridad se autentica mediante Microsoft Entra ID para devolver un token de OAuth 2.0. Después, el token se puede usar para autorizar una solicitud en Blob service.
Para más información sobre la autorización mediante Microsoft Entra ID, consulte Autorización del acceso a blobs mediante Microsoft Entra ID.
Permisos
A continuación se muestra la acción de RBAC necesaria para que un usuario, grupo, identidad administrada o entidad de servicio Microsoft Entra llame a la Append Blob Seal operación y el rol RBAC integrado con privilegios mínimos que incluya esta acción:
- Acción RBAC de Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- Rol integrado con privilegios mínimos:Colaborador de datos de Storage Blob
Para más información sobre cómo asignar roles mediante RBAC de Azure, consulte Asignación de un rol de Azure para el acceso a datos de blobs.
Comentarios
Si un blob en anexos tiene una concesión, necesita un identificador de concesión para sellar el blob.
Después de sellar un blob, todavía puede actualizar las propiedades, las etiquetas de índice de blobs y los metadatos. La eliminación temporal de un blob sellado conserva el estado sellado. Puede sobrescribir blobs sellados.
Si toma una instantánea de un blob sellado, la instantánea incluye la marca sealed. Para las instantáneas existentes en la nueva versión, Microsoft devuelve la propiedad .
Al copiar un blob sellado, la marca sellada se propaga de forma predeterminada. Se expone un encabezado que permite sobrescribir la marca.
Se agregará un nuevo elemento XML a la ListBlob respuesta, denominada Sealed. El valor puede ser o true o false.
Si llama a AppendBlock en un blob que ya está sellado, el servicio devuelve el mensaje de error que se muestra en la tabla siguiente. Esto se aplica a las versiones anteriores de la API.
| Código de error | Código de estado HTTP | Mensaje de usuario |
|---|---|---|
| BlobIsSealed | Conflicto (409) | El blob especificado está sellado y su contenido no se puede modificar a menos que el blob se vuelva a crear después de una eliminación. |
Si llama a Append Blob Seal en un blob en anexos que ya se ha sellado, simplemente verá un código de estado de 200 (Correcto).
Facturación
Las solicitudes de precios pueden originarse en clientes que usan API de Blob Storage, ya sea directamente a través de la API REST de Blob Storage o desde una biblioteca cliente de Azure Storage. Estas solicitudes acumulan cargos por transacción. El tipo de transacción afecta a cómo se cobra la cuenta. Por ejemplo, las transacciones de lectura se acumulan en una categoría de facturación diferente a las transacciones de escritura. En la tabla siguiente se muestra la categoría de facturación de Append Blob Seal las solicitudes basadas en el tipo de cuenta de almacenamiento:
| Operación | Tipo de cuenta de almacenamiento | Categoría de facturación |
|---|---|---|
| Sello de blobs en anexos | Blobs en bloques Premium De uso general, estándar, v2 De uso general, estándar, v1 |
Operaciones de escritura |
Para obtener información sobre los precios de la categoría de facturación especificada, consulte precios Azure Blob Storage.