Lote de Blobs

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.

Parâmetros URI

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

Cabeçalhos do pedido

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

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 Microsoft Entra. 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 Microsoft Entra. 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.

Faturação

O Blob Batch pedido REST é contabilizado como uma transação e cada sub-pedido 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:

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

Observações

Uma das principais vantagens de utilizar 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.
• Suporta apenas 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 lote.
• 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 a execução de pedidos de contas de armazenamento diferentes.
• 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 a SAS da Conta é o único tipo de assinatura de acesso partilhado suportado por Blob Batch, quando o lote não está a utilizar .restype=container

Definir o â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 o âmbito de sub-requisitos para um contentor especificado. Quando o URI do pedido inclui o nome do contentor e o restype=container parâmetro , cada sub-pedido tem de ser aplicado ao mesmo contentor. Se o nome do contentor especificado para um subrequesto 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 no âmbito do contentor. Cada subrequesto envia um cabeçalho de autorização para o serviço.

Ver também

Autorizar pedidos para o Estado do Armazenamento do Azuree códigos de erro Códigos de erro do Armazenamento de BlobsDefinir tempos limite para operações do Armazenamento de Blobs