Lote de Blobs

Artigo
02/03/2024

A Blob Batch operação permite que várias chamadas à API sejam incorporadas num único pedido HTTP. Esta API suporta dois tipos de sub-requisitos: Definir Camada de Blobs para blobs de blocos e Eliminar Blob. A resposta devolvida pelo servidor para um pedido em lote contém os resultados de cada subrequesto no lote. O pedido em lote e a resposta utilizam a sintaxe da especificação de OData processamento em lote, com modificações à semântica. Esta API está disponível a partir da versão 2018-11-09.

Pedir

Pode construir o pedido da Blob Batch seguinte forma. É recomendado HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento.

Método	URI do pedido	Versão HTTP
`POST`	`https://myaccount.blob.core.windows.net/?comp=batch` `https://myaccount.blob.core.windows.net/containername?restype=container&comp=batch`	HTTP/1.1

Parâmetros URI

Pode especificar os seguintes parâmetros adicionais no URI do pedido.

Parâmetro	Description
`timeout`	Opcional. O parâmetro de tempo limite é expresso em segundos, com um valor máximo de 120 segundos. Para obter mais informações, veja Definir tempos limite para operações de Armazenamento de Blobs.
`restype`	Opcional, versão 2020-04-08 e posterior. O único valor suportado para o `restype` parâmetro é `container`. Quando este parâmetro é especificado, o URI tem de incluir o nome do contentor. Quaisquer sub-requisitos têm de estar no âmbito do mesmo contentor.

Cabeçalhos do pedido

A tabela seguinte descreve os cabeçalhos de pedido obrigatórios e opcionais.

Cabeçalho do pedido	Description
`Authorization`	Obrigatório. Especifica o esquema de autorização, o nome da conta de armazenamento e a assinatura. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure.
`Date` ou `x-ms-date`	Obrigatório. Especifica a Hora Universal Coordenada (UTC) do pedido. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure.
`x-ms-version`	Necessário para todos os pedidos autorizados. Especifica a versão da operação a utilizar para este pedido. Esta versão será utilizada para todos os sub-requisitos. Para obter mais informações, veja Controlo de versões dos serviços de Armazenamento do Azure.
`Content-Length`	Obrigatório. A duração do pedido.
`Content-Type`	Obrigatório. O valor deste cabeçalho tem de ser `multipart/mixed`, com um limite de lote. Valor do cabeçalho de exemplo: `multipart/mixed; boundary=batch_a81786c8-e301-4e42-a729-a32ca24ae252`.
`x-ms-client-request-id`	Opcional. Fornece um valor opaco gerado pelo cliente com um limite de carateres de 1 kibibyte (KiB) que é registado nos registos quando o registo é configurado. Recomendamos vivamente que utilize este cabeçalho para correlacionar as atividades do lado do cliente com os pedidos que o servidor recebe. Para obter mais informações, veja Monitorizar Armazenamento de Blobs do Azure.

Corpo do pedido

O corpo do pedido para um lote de blobs contém uma lista de todos os sub-requisitos. O formato utiliza a sintaxe da especificação do OData lote, com modificações à semântica.

O corpo do pedido começa com um limite de lote, seguido de dois cabeçalhos obrigatórios: o Content-Type cabeçalho com o valor application/httpe o Content-Transfer-Encoding cabeçalho com o valor binary. Segue-se um cabeçalho opcional Content-ID , com um valor de cadeia para controlar cada um dos sub-requisitos. A resposta contém o Content-ID cabeçalho para cada resposta de subrequeto correspondente a utilizar para controlo.

Estes cabeçalhos de pedido são seguidos por uma linha vazia obrigatória e, em seguida, a definição para cada sub-requisito. O corpo de cada sub-pedido é um pedido HTTP completo com um verbo, URL, cabeçalhos e corpo necessários para o pedido. Tenha em atenção as seguintes ressalvas:

Os sub-requisitos não devem ter o x-ms-version header. Todos os sub-requisitos são executados com a versão de pedido de lote de nível superior.
O URL do sub-requisito deve ter apenas o caminho do URL (sem o anfitrião).
Cada pedido de lote suporta um máximo de 256 sub-requisitos.
Todos os sub-requisitos têm de ter o mesmo tipo de pedido.
Cada subrequesto é autorizado separadamente, com as informações fornecidas no subrequesto.
Cada linha no corpo do pedido deve terminar com \r\n carateres.

Pedido de exemplo

POST http://account.blob.core.windows.net/?comp=batch HTTP/1.1 
Content-Type: multipart/mixed; boundary=batch_357de4f7-6d0b-4e02-8cd2-6361411a9525 
x-ms-version: 2018-11-09 
Authorization: SharedKey account:QvaoYDQ+0VcaA/hKFjUmQmIxXv2RT3XwwTsOTHL39HI=
Host: 127.0.0.1:10000 
Content-Length: 1569 

--batch_357de4f7-6d0b-4e02-8cd2-6361411a9525 
Content-Type: application/http 
Content-Transfer-Encoding: binary 
Content-ID: 0 

DELETE /container0/blob0 HTTP/1.1 
x-ms-date: Thu, 14 Jun 2018 16:46:54 GMT 
Authorization: SharedKey account:G4jjBXA7LI/RnWKIOQ8i9xH4p76pAQ+4Fs4R1VxasaE= 
Content-Length: 0 

--batch_357de4f7-6d0b-4e02-8cd2-6361411a9525 
Content-Type: application/http 
Content-Transfer-Encoding: binary 
Content-ID: 1 

DELETE /container1/blob1 HTTP/1.1 
x-ms-date: Thu, 14 Jun 2018 16:46:54 GMT 
Authorization: SharedKey account:IvCoYDQ+0VcaA/hKFjUmQmIxXv2RT3XwwTsOTHL39HI= 
Content-Length: 0 

--batch_357de4f7-6d0b-4e02-8cd2-6361411a9525 
Content-Type: application/http 
Content-Transfer-Encoding: binary 
Content-ID: 2 

DELETE /container2/blob2 HTTP/1.1 
x-ms-date: Thu, 14 Jun 2018 16:46:54 GMT 
Authorization: SharedKey account:S37N2JTjcmOQVLHLbDmp2johz+KpTJvKhbVc4M7+UqI= 
Content-Length: 0 

--batch_357de4f7-6d0b-4e02-8cd2-6361411a9525--

Resposta

A resposta inclui um código de estado HTTP e um conjunto de cabeçalhos de resposta para o pedido de lote de nível superior. A resposta também inclui informações de resposta para todos os respetivos sub-requisitos.

Corpo da resposta

A resposta em lote é uma multipart/mixed resposta, que contém a resposta para cada subrequeto. A resposta é segmentada. Cada sub-resposta começa com o Content-Type: application/http cabeçalho. Segue-se Content-ID o cabeçalho, se tiver sido fornecido no pedido. Segue-se o código de estado de resposta HTTP e os cabeçalhos de resposta de cada subrequeto.

Para obter informações sobre os cabeçalhos devolvidos por cada sub-requisito, veja a documentação para as operações Eliminar Blob e Definir Camada de Blobs .

Resposta de amostra

HTTP/1.1 202 Accepted 
Transfer-Encoding: chunked 
Content-Type: multipart/mixed; boundary=batchresponse_66925647-d0cb-4109-b6d3-28efe3e1e5ed 
x-ms-request-id: 778fdc83-801e-0000-62ff-033467000000 
x-ms-version: 2018-11-09 

409
--batchresponse_66925647-d0cb-4109-b6d3-28efe3e1e5ed 
Content-Type: application/http 
Content-ID: 0 

HTTP/1.1 202 Accepted 
x-ms-delete-type-permanent: true
x-ms-request-id: 778fdc83-801e-0000-62ff-0334671e284f 
x-ms-version: 2018-11-09 

--batchresponse_66925647-d0cb-4109-b6d3-28efe3e1e5ed 
Content-Type: application/http 
Content-ID: 1 

HTTP/1.1 202 Accepted 
x-ms-delete-type-permanent: true
x-ms-request-id: 778fdc83-801e-0000-62ff-0334671e2851 
x-ms-version: 2018-11-09 

--batchresponse_66925647-d0cb-4109-b6d3-28efe3e1e5ed 
Content-Type: application/http 
Content-ID: 2 

HTTP/1.1 404 The specified blob does not exist. 
x-ms-error-code: BlobNotFound 
x-ms-request-id: 778fdc83-801e-0000-62ff-0334671e2852 
x-ms-version: 2018-11-09 
Content-Length: 216 
Content-Type: application/xml 

<?xml version="1.0" encoding="utf-8"?> 
<Error><Code>BlobNotFound</Code><Message>The specified blob does not exist. 
RequestId:778fdc83-801e-0000-62ff-0334671e2852 
Time:2018-06-14T16:46:54.6040685Z</Message></Error> 
--batchresponse_66925647-d0cb-4109-b6d3-28efe3e1e5ed-- 
0

Código de estado

Se o pedido do batch estiver bem formado e autorizado, a operação devolverá o código de estado 202 (Aceite). Cada sub-pedido tem a sua própria resposta, dependendo do resultado da operação. O estado do sub-pedido é devolvido no corpo da resposta.

Para obter mais informações, veja Códigos de estado e de erro.

Cabeçalhos de resposta

A resposta para esta operação inclui os seguintes cabeçalhos. A resposta também pode incluir cabeçalhos HTTP padrão adicionais. Todos os cabeçalhos padrão estão em conformidade com a especificação do protocolo HTTP/1.1.

Autorização

Quando restype=container for omitido, tem de autorizar o pedido do lote principal através de uma chave partilhada. Pode utilizar a chave de acesso da conta, uma assinatura de acesso partilhado de conta ou o Azure Active Directory. Detalhes para mecanismos de autorização específicos apresentados abaixo.

Quando restype=container estiver incluído no pedido, pode autorizar o pedido do lote principal através de uma chave partilhada ou do Azure Active Directory. Também pode autorizar com uma assinatura de acesso partilhado assinada por qualquer um desses mecanismos de autorização. Detalhes para mecanismos de autorização específicos apresentados abaixo.

Cada subrequesto é autorizado separadamente. Um sub-pedido suporta os mesmos mecanismos de autorização que a operação suporta quando não faz parte de uma operação de lote.

O Armazenamento do Azure suporta a utilização de Microsoft Entra ID para autorizar pedidos para dados de blobs. Com Microsoft Entra ID, pode utilizar o controlo de acesso baseado em funções do Azure (RBAC do Azure) para conceder permissões a um principal de segurança. O principal de segurança pode ser um utilizador, grupo, principal de serviço de aplicação ou identidade gerida do Azure. O principal de segurança é autenticado por Microsoft Entra ID para devolver um token OAuth 2.0. Em seguida, o token pode ser utilizado para autorizar um pedido contra o serviço Blob.

Para saber mais sobre a autorização através de Microsoft Entra ID, veja Autorizar o acesso a blobs com Microsoft Entra ID.

Permissões

Abaixo estão listadas as ações RBAC necessárias para que um utilizador, grupo ou principal de serviço Microsoft Entra faça um Blob Batch pedido principal e a função RBAC do Azure com menos privilégios que inclua esta ação:

Ação RBAC do Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Função incorporada com menos privilégios:Contribuidor de Dados de Blobs de Armazenamento

Para saber mais sobre como atribuir funções com o RBAC do Azure, veja Atribuir uma função do Azure para acesso a dados de blobs.

Uma assinatura de acesso partilhado (SAS) fornece acesso delegado seguro aos recursos numa conta de armazenamento. Com uma SAS, tem controlo granular sobre como um cliente pode aceder aos dados. Pode especificar o recurso a que o cliente pode aceder, que permissões têm para esses recursos e quanto tempo a SAS é válida.

O Blob Batch pedido principal suporta assinaturas de acesso partilhado para os seguintes cenários:

Quando restype=container é omitido: a SAS da Conta é suportada
Quando restype=container é incluído no pedido: SAS de delegação de utilizador,SAS de serviço e SAS de conta são suportados

Como melhor prática de segurança, recomendamos que utilize Microsoft Entra credenciais em vez da chave da conta de armazenamento, que podem ser mais facilmente comprometidas. Se a estrutura da aplicação exigir assinaturas de acesso partilhado, utilize Microsoft Entra credenciais para criar uma SAS de delegação de utilizador, sempre que possível.

Quando o acesso à Chave Partilhada não for permitido para a conta de armazenamento, não será permitido um token de SAS de serviço ou um token de SAS de conta num pedido para o Armazenamento de Blobs. Para saber mais, veja Compreender como a desativação da Chave Partilhada afeta os tokens de SAS.

SAS de delegação de utilizadores

Uma SAS de delegação de utilizador é protegida com credenciais de Microsoft Entra e também pelas permissões especificadas para a SAS.

Um Blob Batch pedido principal que utilize um token de SAS delegado a um contentor ou recurso de blob requer a permissão Escrever (w) como parte do token SAS de delegação de utilizador.

Para saber mais sobre a SAS de delegação de utilizador, veja Criar uma SAS de delegação de utilizador.

SAS de Serviço

Uma SAS de serviço é protegida com a chave da conta de armazenamento. Um serviço SAS delega o acesso a um recurso num único serviço de Armazenamento do Azure, como o armazenamento de blobs.

Um Blob Batch pedido principal que utilize um token de SAS delegado a um contentor ou recurso de blob requer a permissão Escrever (w) como parte do token saS do serviço.

Para saber mais sobre a SAS do serviço, veja Criar uma SAS de serviço.

SAS de Conta

Uma SAS de conta é protegida com a chave da conta de armazenamento. Uma conta SAS delega o acesso aos recursos em um ou mais dos serviços de armazenamento. Todas as operações disponíveis através de um serviço ou saS de delegação de utilizador também estão disponíveis através de uma SAS de conta.

A tabela seguinte indica o tipo de recurso assinado e as permissões assinadas para especificar ao delegar o acesso:

Operação	Serviço assinado	Tipo de recurso assinado	Permissão assinada
Blob Batch (pedido principal)	Blob (b)	Objeto (o)	Escrever (w)

Para saber mais sobre a SAS da conta, consulte Criar uma SAS de conta.

Faturação

O Blob Batch pedido REST é contabilizado como uma transação e cada subrequeto individual também é contabilizado como uma transação. Para saber mais sobre a faturação dos sub-requisitos individuais, veja a documentação para as operações Eliminar Blob e Definir Camada de Blobs .

Os pedidos de preços podem ter origem em clientes que utilizam APIs de Armazenamento de Blobs, diretamente através da API REST do Armazenamento de Blobs ou a partir de uma biblioteca de cliente do Armazenamento do Azure. Estes pedidos acumulam custos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura acumulam-se numa categoria de faturação diferente das transações de escrita. A tabela seguinte mostra a categoria de faturação de um Blob Batch pedido principal com base no tipo de conta de armazenamento:

Operação	Tipo de conta de armazenamento	Categoria de faturação
Blob Batch (Definir Camada de Blobs)	Blob de bloco premium Standard para fins gerais v2	Outras operações

Para saber mais sobre os preços da categoria de faturação especificada, veja Armazenamento de Blobs do Azure Preços.

Observações

Uma das principais vantagens da utilização de um pedido em lote é a redução do número de ligações que um cliente tem de abrir. Tenha em atenção as seguintes restrições:

Os sub-requisitos suportados no lote são Set Blob Tier (para blobs de blocos) e Delete Blob.
Apenas suporta até 256 sub-requisitos num único lote. O tamanho do corpo de um pedido em lote não pode exceder os 4 MB.
Um pedido em lote vazio falha com o código 400 (Pedido Incorreto).
Não existem garantias sobre a ordem de execução dos sub-requisitos do batch.
A execução de sub-requisitos do Batch não é atómica. Cada sub-requisito é executado de forma independente.
Cada subrequesto tem de ser para um recurso na mesma conta de armazenamento. Um único pedido em lote não suporta pedidos em execução de diferentes contas de armazenamento.
Um corpo de pedido aninhado não é suportado.
Se o servidor não analisar o corpo do pedido, todo o lote falhará e nenhum pedido será executado.
Tenha em atenção que o SAS da Conta é o único tipo de assinatura de acesso partilhado suportado pelo Blob Batch, quando o lote não está a utilizar .restype=container

Âmbito de todos os sub-requisitos para um contentor específico

A partir da versão REST 2020-04-08, a Blob Batch API suporta sub-requisitos de âmbito para um contentor especificado. Quando o URI do pedido inclui o nome do contentor e o restype=container parâmetro, cada subrequesto tem de ser aplicado ao mesmo contentor. Se o nome do contentor especificado para um sub-pedido não corresponder ao nome do contentor fornecido no URI, o serviço devolve o código de erro 400 (Pedido Incorreto).

Todos os mecanismos de autorização suportados para um contentor são válidos para uma Blob Batch operação que está no âmbito do contentor. Cada subrequeto envia um cabeçalho de autorização para o serviço.

Ver também

Autorizar pedidos para o Estado do Armazenamento do Azure e códigos de erro Códigos de erro do Armazenamento de Blobs Definição de tempos limite para operações de Armazenamento de Blobs