Questo documento mostra come effettuare chiamate API JSON in batch per ridurre il numero di connessioni HTTP che il tuo client deve effettuare quando accede a Cloud Storage.
Panoramica delle richieste batch
Ogni connessione HTTP effettuata dal client comporta un determinato overhead. L'API JSON di Cloud Storage supporta le richieste batch, che consentono al client di raggruppare più chiamate API in una singola richiesta HTTP. Il raggruppamento di più chiamate API in una singola richiesta consente di ridurre l'overhead di rete e la latenza quando devi eseguire molte operazioni.
Esempi di operazioni per cui potresti voler utilizzare le richieste batch:
- Aggiornamento dei metadati, ad esempio delle autorizzazioni, su molti oggetti
- Eliminazione di molti oggetti
Cloud Storage non supporta le operazioni batch per il caricamento o il download.
Struttura delle richieste batch
Una richiesta batch è una singola richiesta HTTP standard contenente più chiamate all'API JSON di Cloud Storage. La richiesta batch esterna utilizza multipart/mixed nell'intestazione della richiesta Content-Type, con un corpo composto da più parti, ognuna delle quali contiene una singola sotto-richiesta HTTP.
La richiesta batch esterna viene inviata all'endpoint batch:
https://storage.googleapis.com/batch/storage/v1
Ogni sotto-richiesta all'interno del corpo batch specifica un percorso di richiesta API JSON di Cloud Storage standard, ad esempio:
https://storage.googleapis.com/storage/v1/BUCKET_NAME/o/OBJECT_NAME
Per visualizzare il formato di una richiesta batch di esempio, consulta Esempio.
Non devi includere più di 100 chiamate in una singola richiesta batch per evitare errori HTTP 400, timeout del gateway e connessioni interrotte. Se devi effettuare più di 100 chiamate, utilizza più richieste batch. Il payload totale della richiesta batch deve essere inferiore a 10 MB. Le richieste più grandi vengono rifiutate da Cloud Storage.
Formato delle richieste batch
Questa sezione descrive il formato di una richiesta batch.
All'interno del corpo della richiesta esterna, ogni parte inizia con la propria intestazione HTTP Content-Type: application/http. La parte può anche avere un'intestazione Content-ID facoltativa. Queste intestazioni contrassegnano l'inizio della parte, ma sono separate dalla richiesta HTTP nidificata. Ciò significa che, dopo che il server ha scomposto la richiesta batch in richieste separate, le intestazioni delle parti vengono ignorate.
Il corpo di ogni parte è una richiesta HTTP completa, con verbo, URL, intestazioni e corpo. Queste richieste HTTP devono contenere solo la parte di percorso dell'URL; gli URL completi possono avere un comportamento indefinito.
Le intestazioni HTTP per la richiesta batch esterna, ad eccezione delle Content- intestazioni
come Content-Type, si applicano anche a ogni richiesta nidificata. Tuttavia, se specifichi una determinata intestazione HTTP sia nella richiesta esterna che in una richiesta nidificata, il valore dell'intestazione della richiesta nidificata esegue l'override del valore dell'intestazione della richiesta batch esterna per quella richiesta specifica.
Ad esempio, se fornisci un'intestazione Authorization per una richiesta nidificata specifica, questa intestazione si applica solo alla richiesta che l'ha specificata. Se fornisci un'intestazione Authorization per la richiesta esterna, questa intestazione si applica a tutte le richieste nidificate, a meno che non venga sostituita da un'intestazione Authorization propria.
Quando Cloud Storage riceve la richiesta raggruppata in batch, applica i parametri di ricerca e le intestazioni della richiesta esterna (se opportuno) a ogni parte e poi tratta ogni parte come se fosse una richiesta HTTP separata.
Risposta a una richiesta batch
La risposta di Cloud Storage è una singola risposta HTTP standard con un tipo di contenuto multipart/mixed; ogni parte di questa risposta principale è la risposta a una delle richieste nella richiesta raggruppata in batch. L'ordine delle risposte è lo stesso delle richieste.
Come tutte le parti di una richiesta, ogni parte della risposta contiene una risposta HTTP completa, inclusi un codice di stato, le intestazioni e un corpo. E come le parti della richiesta, ogni parte della risposta è preceduta da un'intestazione Content-Type che contrassegna l'inizio della parte. Per ulteriori informazioni sui codici di stato, consulta
Codici di stato ed errore HTTP per l'API JSON di Cloud Storage.
Se una determinata parte della richiesta aveva un'intestazione Content-ID, la parte corrispondente della risposta ha un'intestazione Content-ID corrispondente. L'Content-ID header
della risposta inizia con response-, seguita dal valore Content-ID utilizzato nella richiesta, come mostrato nell'esempio.
Esempio
Il seguente esempio di batch aggiorna i metadati personalizzati per tre oggetti
in example-bucket.
Esempio di richiesta HTTP batch
HTTP
POST /batch/storage/v1 HTTP/1.1
Host: storage.googleapis.com
Content-Length: 960
Content-Type: multipart/mixed; boundary="===============7330845974216740156=="
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg
--===============7330845974216740156==
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: <b29c5de2-0db4-490b-b421-6a51b598bd22+1>
PATCH /storage/v1/b/example-bucket/o/obj1 HTTP/1.1
Content-Type: application/json
accept: application/json
content-length: 31
{"metadata": {"type": "tabby"}}
--===============7330845974216740156==
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: <b29c5de2-0db4-490b-b421-6a51b598bd22+2>
PATCH /storage/v1/b/example-bucket/o/obj2 HTTP/1.1
Content-Type: application/json
accept: application/json
content-length: 32
{"metadata": {"type": "tuxedo"}}
--===============7330845974216740156==
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: <b29c5de2-0db4-490b-b421-6a51b598bd22+3>
PATCH /storage/v1/b/example-bucket/o/obj3 HTTP/1.1
Content-Type: application/json
accept: application/json
content-length: 32
{"metadata": {"type": "calico"}}
--===============7330845974216740156==--
Librerie client
C++
La libreria client C++ non supporta le richieste batch.
C#
La libreria client C# non supporta le richieste batch.
Vai
La libreria client Go non supporta le richieste batch.
Java
Per saperne di più, consulta la documentazione di riferimento dell'API Java di Cloud Storage.
Node.js
La libreria client Node.js non supporta le richieste batch.
PHP
La libreria client PHP non supporta le richieste batch.
Python
Per saperne di più, consulta la documentazione di riferimento dell'API Python di Cloud Storage.
Ruby
Per scoprire come effettuare una richiesta batch utilizzando Ruby, consulta la documentazione di riferimento dell'API Ruby di Cloud Storage.
Rust
La libreria client Rust non supporta le richieste batch.
Esempio di risposta HTTP batch
Questa è la risposta alla richiesta HTTP di esempio nella sezione precedente.
HTTP/1.1 200 OK
Content-Type: multipart/mixed; boundary=batch_pK7JBAk73-E=_AA5eFwv4m2Q=
Date: Mon, 22 Jan 2018 18:56:00 GMT
Expires: Mon, 22 Jan 2018 18:56:00 GMT
Cache-Control: private, max-age=0
Content-Length: 3767
--batch_pK7JBAk73-E=_AA5eFwv4m2Q=
Content-Type: application/http
Content-ID: <response-b29c5de2-0db4-490b-b421-6a51b598bd22+1>
HTTP/1.1 200 OK
ETag: "lGaP-E0memYDumK16YuUDM_6Gf0/V43j6azD55CPRGb9b6uytDYl61Y"
Content-Type: application/json; charset=UTF-8
Date: Mon, 22 Jan 2018 18:56:00 GMT
Expires: Mon, 22 Jan 2018 18:56:00 GMT
Cache-Control: private, max-age=0
Content-Length: 846
{
"kind": "storage#object",
"id": "example-bucket/obj1/1495822576643790",
.
.
.
"metadata": {
"type": "tabby"
},
.
.
.
}
--batch_pK7JBAk73-E=_AA5eFwv4m2Q=
Content-Type: application/http
Content-ID: <response-b29c5de2-0db4-490b-b421-6a51b598bd22+2>
HTTP/1.1 200 OK
ETag: "lGaP-E0memYDumK16YuUDM_6Gf0/91POdd-sxSAkJnS8Dm7wMxBSDKk"
Content-Type: application/json; charset=UTF-8
Date: Mon, 22 Jan 2018 18:56:00 GMT
Expires: Mon, 22 Jan 2018 18:56:00 GMT
Cache-Control: private, max-age=0
Content-Length: 846
{
"kind": "storage#object",
"id": "example-bucket/obj2/1495822576643790",
.
.
.
"metadata": {
"type": "tuxedo"
},
.
.
.
}
--batch_pK7JBAk73-E=_AA5eFwv4m2Q=
Content-Type: application/http
Content-ID: <response-b29c5de2-0db4-490b-b421-6a51b598bd22+3>
HTTP/1.1 200 OK
ETag: "lGaP-E0memYDumK16YuUDM_6Gf0/d2Z1F1_ZVbB1dC0YKM9rX5VAgIQ"
Content-Type: application/json; charset=UTF-8
Date: Mon, 22 Jan 2018 18:56:00 GMT
Expires: Mon, 22 Jan 2018 18:56:00 GMT
Cache-Control: private, max-age=0
Content-Length: 846
{
"kind": "storage#object",
"id": "example-bucket/obj3/1495822576643790",
.
.
.
"metadata": {
"type": "calico"
},
.
.
.
}
--batch_pK7JBAk73-E=_AA5eFwv4m2Q=--
Se la richiesta complessiva non è formattata correttamente e Cloud Storage
non è in grado di analizzarla in sotto-richieste, riceverai un errore 400. In caso contrario, Cloud Storage restituisce un codice di stato 200, anche se alcune o tutte le sotto-richieste non vanno a buon fine.
Quando la richiesta complessiva restituisce un codice di stato 200, la risposta contiene i risultati per ogni sotto-richiesta, incluso un codice di stato per ciascuna, che indica se la sotto-richiesta è andata a buon fine o meno. Ad esempio, quando elimini oggetti in batch, ogni sotto-richiesta riuscita contiene un codice di stato 204 No Content.