Migliora le prestazioni

Compressione con gzip

Un modo semplice e pratico per ridurre la larghezza di banda necessaria per ogni richiesta è attivare la compressione gzip. Sebbene questo richieda tempo CPU aggiuntivo per decomprimere i risultati, il trade-off con i costi di rete di solito lo rende molto utile.

Per ricevere una risposta con codifica gzip, devi fare due cose: impostare un'intestazione Accept-Encoding e modificare l'user agent in modo che contenga la stringa gzip. Ecco un esempio di intestazioni HTTP formattate correttamente per attivare la compressione gzip:

Accept-Encoding: gzip
User-Agent: my program (gzip)

Lavorare con risorse parziali

Un altro modo per migliorare le prestazioni delle chiamate API è inviare e ricevere solo la parte di dati che ti interessa. In questo modo, l'applicazione evita di trasferire, analizzare e memorizzare campi non necessari, in modo da poter utilizzare in modo più efficiente le risorse, tra cui rete, CPU e memoria.

Esistono due tipi di richieste parziali:

• Risposta parziale: una richiesta in cui specifichi i campi da includere nella risposta (utilizza il parametro di richiesta fields).
• Patch: una richiesta di aggiornamento in cui invii solo i campi che vuoi modificare (utilizza il verbo HTTP PATCH).

Ulteriori dettagli su come effettuare richieste parziali sono disponibili nelle sezioni seguenti.

Risposta parziale

Per impostazione predefinita, il server restituisce la rappresentazione completa di una risorsa dopo aver elaborato le richieste. Per migliorare le prestazioni, puoi chiedere al server di inviare solo i campi di cui hai realmente bisogno e ricevere una risposta parziale.

Per richiedere una risposta parziale, utilizza il parametro di richiesta fields per specificare i campi che vuoi che vengano restituiti. Puoi utilizzare questo parametro con qualsiasi richiesta che restituisce dati di risposta.

Tieni presente che il parametro fields influisce solo sui dati di risposta e non sui dati che devi inviare, se presenti. Per ridurre la quantità di dati inviati quando modifichi le risorse, utilizza una richiesta di patch.

Esempio

L'esempio seguente mostra l'utilizzo del parametro fields con un'API "Demo" generica (inventariata).

Richiesta semplice: questa richiesta HTTP GET omette il parametro fields e restituisce la risorsa completa.

https://www.googleapis.com/demo/v1

Risposta completa della risorsa:i dati completi della risorsa includono i seguenti campi, oltre a molti altri che sono stati omessi per brevità.

{
  "kind": "demo",
  ...
  "items": [
  {
    "title": "First title",
    "comment": "First comment.",
    "characteristics": {
      "length": "short",
      "accuracy": "high",
      "followers": ["Jo", "Will"],
    },
    "status": "active",
    ...
  },
  {
    "title": "Second title",
    "comment": "Second comment.",
    "characteristics": {
      "length": "long",
      "accuracy": "medium"
      "followers": [ ],
    },
    "status": "pending",
    ...
  },
  ...
  ]
}

Richiesta di una risposta parziale: la seguente richiesta per la stessa risorsa utilizza il parametro fields per ridurre in modo significativo la quantità di dati restituiti.

https://www.googleapis.com/demo/v1?fields=kind,items(title,characteristics/length)

Risposta parziale: in risposta alla richiesta precedente, il server invia una risposta contenente solo le informazioni sul tipo, oltre a un array di elementi ridotto che include solo le informazioni sulle caratteristiche del titolo e della lunghezza HTML in ogni elemento.

200 OK

{
  "kind": "demo",
  "items": [{
    "title": "First title",
    "characteristics": {
      "length": "short"
    }
  }, {
    "title": "Second title",
    "characteristics": {
      "length": "long"
    }
  },
  ...
  ]
}

Tieni presente che la risposta è un oggetto JSON che include solo i campi selezionati e gli oggetti principali che li contengono.

Di seguito sono riportati i dettagli su come formattare il parametro fields, seguiti da ulteriori dettagli su cosa viene restituito esattamente nella risposta.

Riepilogo della sintassi del parametro Fields

Il formato del valore del parametro di richiesta fields si basa liberamente sulla sintassi XPath. La sintassi supportata è riassunta di seguito e altri esempi sono forniti nella sezione seguente.

• Utilizza un elenco separato da virgole per selezionare più campi.
• Utilizza a/b per selezionare un campo b nidificato all'interno del campo a; utilizza a/b/c per selezionare un campo c nidificato all'interno di b.
  

  Eccezione: per le risposte dell'API che utilizzano wrapper "data", in cui la risposta è nidificata all'interno di un oggetto data simile a data: { ... }, non includere "data" nella specifica fields. L'inclusione dell'oggetto dati con una specifica dei campi come data/a/b causa un errore. Utilizza invece una specifica fields come a/b.

• Utilizza un selettore secondario per richiedere un insieme di sottocampi specifici di array o oggetti inserendo le espressioni tra parentesi "( )".

  Ad esempio, fields=items(id,author/email) restituisce solo l'ID articolo e l'email dell'autore per ogni elemento nell'array di articoli. Puoi anche specificare un singolo sottocampo, dove fields=items(id) è equivalente a fields=items/id.

• Utilizza i caratteri jolly nelle selezioni dei campi, se necessario.

  Ad esempio, fields=items/pagemap/* seleziona tutti gli oggetti in una mappa di pagine.

Altri esempi di utilizzo del parametro fields

Gli esempi riportati di seguito includono descrizioni dell'impatto del valore del parametro fields sulla risposta.

Nota:come per tutti i valori dei parametri di query, il valore del parametro fields deve essere codificato nell'URL. Per una maggiore leggibilità, gli esempi in questo documento omettono la codifica.

Identifica i campi che vuoi che vengano restituiti o effettua selezioni di campi.

Il valore del parametro di richiesta fields è un elenco di campi separati da virgole e ogni campo è specificato in base alla radice della risposta. Pertanto, se esegui un'operazione list, la risposta è una raccolta e in genere include un array di risorse. Se stai eseguendo un'operazione che restituisce una singola risorsa, i campi vengono specificati in base a quella risorsa. Se il campo selezionato è (o fa parte di) un array, il server restituisce la parte selezionata di tutti gli elementi dell'array.

Ecco alcuni esempi a livello di raccolta:

Esempi	Effetto
items	Restituisce tutti gli elementi nell'array items, inclusi tutti i campi di ogni elemento, ma nessun altro campo.
etag,items	Restituisce sia il campo etag sia tutti gli elementi nell'array items.
items/title	Restituisce solo il campo title per tutti gli elementi nell'array di elementi. Ogni volta che viene restituito un campo nidificato, la risposta include gli oggetti principali che lo contengono. I campi principali non includono altri campi secondari, a meno che non siano selezionati anche in modo esplicito.
context/facets/label	Restituisce solo il campo label per tutti i membri dell'array facets, che è a sua volta nidificato nell'oggetto context.
items/pagemap/*/title	Per ogni elemento dell'array items, restituisce solo il campo title (se presente) di tutti gli oggetti secondari di pagemap.

Ecco alcuni esempi a livello di risorsa:

Esempi	Effetto
title	Restituisce il campo title della risorsa richiesta.
author/uri	Restituisce il sottocampo uri dell'oggetto author nella risorsa richiesta.
links/*/href	Restituisce il campo href di tutti gli oggetti che sono figli di links.

Richiedi solo parti di campi specifici utilizzando le sottoselezioni.

Per impostazione predefinita, se la richiesta specifica campi specifici, il server restituisce gli oggetti o gli elementi dell'array nella loro interezza. Puoi specificare una risposta che includa solo determinati sottocampi. A tale scopo, utilizza la sintassi di sottosezione "( )", come nell'esempio seguente.

Esempio	Effetto
items(title,author/uri)	Restituisce solo i valori di title e uri dell'autore per ogni elemento dell'array di elementi.

Gestione delle risposte parziali

Dopo che un server ha elaborato una richiesta valida che include il parametro di query fields, restituisce un codice di stato HTTP 200 OK insieme ai dati richiesti. Se il parametro di query fields contiene un errore o non è valido, il server restituisce un codice di stato HTTP 400 Bad Request, insieme a un messaggio di errore che indica all'utente il problema con la selezione dei campi (ad es. "Invalid field selection a/b").

Ecco l'esempio di risposta parziale mostrato nella sezione introduttiva sopra. La richiesta utilizza il parametro fields per specificare i campi da restituire.

https://www.googleapis.com/demo/v1?fields=kind,items(title,characteristics/length)

La risposta parziale è la seguente:

200 OK

{
  "kind": "demo",
  "items": [{
    "title": "First title",
    "characteristics": {
      "length": "short"
    }
  }, {
    "title": "Second title",
    "characteristics": {
      "length": "long"
    }
  },
  ...
  ]
}

Nota:per le API che supportano i parametri di query per la paginazione dei dati (ad es. maxResults e nextPageToken), utilizza questi parametri per ridurre i risultati di ogni query a dimensioni gestibili. In caso contrario, i miglioramenti delle prestazioni possibili con la risposta parziale potrebbero non essere realizzati.

Patch (aggiornamento parziale)

Puoi anche evitare di inviare dati non necessari quando modifichi le risorse. Per inviare i dati aggiornati solo per i campi specifici che stai modificando, utilizza il verbo HTTP PATCH. La semantica delle patch descritta in questo documento è diversa (e più semplice) rispetto a quella dell'implementazione precedente di GData dell'aggiornamento parziale.

L'esempio breve riportato di seguito mostra come l'utilizzo di patch riduce al minimo i dati da inviare per apportare un piccolo aggiornamento.

Esempio

Questo esempio mostra una semplice richiesta di patch per aggiornare solo il titolo di una risorsa API "Demo" generica (inventariata). La risorsa contiene anche un commento, un insieme di caratteristiche, lo stato e molti altri campi, ma questa richiesta invia solo il campo title, poiché è l'unico campo modificato:

PATCH https://www.googleapis.com/demo/v1/324
Authorization: Bearer your_auth_token
Content-Type: application/json

{
  "title": "New title"
}

Risposta:

200 OK

{
  "title": "New title",
  "comment": "First comment.",
  "characteristics": {
    "length": "short",
    "accuracy": "high",
    "followers": ["Jo", "Will"],
  },
  "status": "active",
  ...
}

Il server restituisce un codice di stato 200 OK, insieme alla rappresentazione completa della risorsa aggiornata. Poiché nella richiesta di patch è stato incluso solo il campo title, questo è l'unico valore diverso da prima.

Nota: se utilizzi il parametro fields di risposta parziale in combinazione con patch, puoi aumentare ulteriormente l'efficienza delle richieste di aggiornamento. Una richiesta di patch riduce solo le dimensioni della richiesta. Una risposta parziale riduce le dimensioni della risposta. Pertanto, per ridurre la quantità di dati inviati in entrambe le direzioni, utilizza una richiesta di patch con il parametro fields.

Semantica di una richiesta di patch

Il corpo della richiesta di patch include solo i campi della risorsa che vuoi modificare. Quando specifichi un campo, devi includere tutti gli oggetti principali di contenimento, così come gli oggetti principali di contenimento vengono restituiti con una risposta parziale. I dati modificati che invii vengono uniti ai dati dell'oggetto principale, se presente.

• Aggiungi:per aggiungere un campo che non esiste già, specifica il nuovo campo e il relativo valore.
• Modifica:per modificare il valore di un campo esistente, specificalo e impostalo sul nuovo valore.
  
• Elimina:per eliminare un campo, specificalo e impostalo su null. Ad esempio: "comment": null. Puoi anche eliminare un intero oggetto (se è mutabile) impostandolo su null. Se utilizzi la libreria client API per Java, utilizza Data.NULL_STRING. Per maggiori dettagli, consulta JSON null.

Nota sugli array:le richieste di patch che contengono array sostituiscono l'array esistente con quello fornito. Non puoi modificare, aggiungere o eliminare elementi in un array in modo frazionato.

Utilizzo di patch in un ciclo di lettura, modifica e scrittura

Può essere utile iniziare recuperando una risposta parziale con i dati che vuoi modificare. Questo è particolarmente importante per le risorse che utilizzano gli ETag, poiché devi fornire il valore ETag corrente nell'intestazione HTTP If-Match per aggiornare correttamente la risorsa. Dopo aver recuperato i dati, puoi modificare i valori che vuoi cambiare e inviare nuovamente la rappresentazione parziale modificata con una richiesta di patch. Ecco un esempio che presuppone che la risorsa Demo utilizzi gli ETag:

GET https://www.googleapis.com/demo/v1/324?fields=etag,title,comment,characteristics
Authorization: Bearer your_auth_token

Questa è la risposta parziale:

200 OK

{
  "etag": "ETagString"
  "title": "New title"
  "comment": "First comment.",
  "characteristics": {
    "length": "short",
    "level": "5",
    "followers": ["Jo", "Will"],
  }
}

La seguente richiesta di patch si basa su questa risposta. Come mostrato di seguito, utilizza anche il parametro fields per limitare i dati restituiti nella risposta alla patch:

PATCH https://www.googleapis.com/demo/v1/324?fields=etag,title,comment,characteristics
Authorization: Bearer your_auth_token
Content-Type: application/json
If-Match: "ETagString"

{
  "etag": "ETagString"
  "title": "",                  /* Clear the value of the title by setting it to the empty string. */
  "comment": null,              /* Delete the comment by replacing its value with null. */
  "characteristics": {
    "length": "short",
    "level": "10",              /* Modify the level value. */
    "followers": ["Jo", "Liz"], /* Replace the followers array to delete Will and add Liz. */
    "accuracy": "high"          /* Add a new characteristic. */
  },
}

Il server risponde con un codice di stato HTTP 200 OK e la rappresentazione parziale della risorsa aggiornata:

200 OK

{
  "etag": "newETagString"
  "title": "",                 /* Title is cleared; deleted comment field is missing. */
  "characteristics": {
    "length": "short",
    "level": "10",             /* Value is updated.*/
    "followers": ["Jo" "Liz"], /* New follower Liz is present; deleted Will is missing. */
    "accuracy": "high"         /* New characteristic is present. */
  }
}

Creazione diretta di una richiesta di patch

Per alcune richieste di patch, devi basarle sui dati recuperati in precedenza. Ad esempio, se vuoi aggiungere un elemento a un array e non vuoi perdere nessuno degli elementi array esistenti, devi prima recuperare i dati esistenti. Analogamente, se un'API utilizza gli ETag, devi inviare il valore ETag precedente con la richiesta per aggiornare correttamente la risorsa.

Nota:puoi utilizzare un'intestazione HTTP "If-Match: *" per forzare l'applicazione di una patch quando sono in uso gli ETag.  In questo caso, non è necessario leggere prima di scrivere.

In altre situazioni, invece, puoi creare direttamente la richiesta di patch, senza prima recuperare i dati esistenti. Ad esempio, puoi configurare facilmente una richiesta di patch che aggiorna un campo con un nuovo valore o aggiunge un nuovo campo. Ecco un esempio:

PATCH https://www.googleapis.com/demo/v1/324?fields=comment,characteristics
Authorization: Bearer your_auth_token
Content-Type: application/json

{
  "comment": "A new comment",
  "characteristics": {
    "volume": "loud",
    "accuracy": null
  }
}

Con questa richiesta, se il campo dei commenti ha un valore esistente, il nuovo valore lo sovrascrive; in caso contrario, viene impostato il nuovo valore. Analogamente, se esiste una caratteristica del volume, il relativo valore viene sovrascritto; in caso contrario, viene creato. Il campo di precisione, se impostato, viene rimosso.

Gestione della risposta a un patch

Dopo aver elaborato una richiesta di patch valida, l'API restituisce un codice di risposta HTTP 200 OK insieme alla rappresentazione completa della risorsa modificata. Se l'API utilizza gli ETag, il server aggiorna i valori ETag quando elabora correttamente una richiesta di patch, come avviene con PUT.

La richiesta di patch restituisce l'intera rappresentazione della risorsa, a meno che non utilizzi il parametro fields per ridurre la quantità di dati restituiti.

Se una richiesta di patch genera un nuovo stato della risorsa non valido dal punto di vista sintattico o semantico, il server restituisce un codice di stato HTTP 400 Bad Request o 422 Unprocessable Entity e lo stato della risorsa rimane invariato. Ad esempio, se provi a eliminare il valore di un campo obbligatorio, il server restituisce un errore.

Notazione alternativa quando il verbo HTTP PATCH non è supportato

Se il firewall non consente le richieste HTTP PATCH, effettua una richiesta HTTP POST e imposta l'intestazione di override su PATCH, come mostrato di seguito:

POST https://www.googleapis.com/...
X-HTTP-Method-Override: PATCH
...

Differenza tra patch e aggiornamento

In pratica, quando invii i dati per una richiesta di aggiornamento che utilizza il verbo HTTP PUT, devi inviare solo i campi obbligatori o facoltativi. Se invii valori per i campi impostati dal server, questi vengono ignorati. Anche se potrebbe sembrare un altro modo per eseguire un aggiornamento parziale, questo approccio presenta alcune limitazioni. Con gli aggiornamenti che utilizzano il verbo HTTP PUT, la richiesta non va a buon fine se non fornisci i parametri obbligatori e vengono cancellati i dati impostati in precedenza se non fornisci i parametri facoltativi.

Per questo motivo, è molto più sicuro utilizzare la patch. Fornisci i dati solo per i campi che vuoi modificare; i campi omessi non vengono cancellati. L'unica eccezione a questa regola si verifica con elementi o array ripetuti: se li ometti tutti, rimangono invariati; se ne fornisci uno, l'intero insieme viene sostituito con quello che fornisci.

Panoramica

Ogni connessione HTTP stabilita dal client comporta un determinato overhead. L'API Google Drive supporta il raggruppamento per consentire al client di inserire più chiamate API in un'unica richiesta HTTP.

Esempi di situazioni in cui potresti voler utilizzare il raggruppamento:

• Recupero dei metadati per un numero elevato di file.
• Aggiornamento collettivo di metadati o proprietà.
• Modificare le autorizzazioni per un numero elevato di file, ad esempio l'aggiunta di un nuovo utente o gruppo.
• Sincronizzazione dei dati del client locale per la prima volta o dopo essere stato offline per un periodo di tempo prolungato.

In ogni caso, anziché inviare ogni chiamata separatamente, puoi raggrupparle in un'unica richiesta HTTP. Tutte le richieste interne devono essere indirizzate alla stessa API Google.

Puoi effettuare fino a 100 chiamate in una singola richiesta batch. Se devi effettuare più chiamate, utilizza più richieste collettive.

Nota: il sistema batch per l'API Google Drive utilizza la stessa sintassi del sistema di elaborazione batch OData, ma la semantica è diversa.

Ulteriori vincoli includono:

• Le richieste collettive con più di 100 chiamate potrebbero causare un errore.
• Esiste un limite di 8000 caratteri per la lunghezza dell'URL di ogni richiesta interna.
• Google Drive non supporta le operazioni collettive per i contenuti multimediali, né per il caricamento o il download né per l'esportazione dei file.

Dettagli del batch

Una richiesta batch è composta da più chiamate API combinate in un'unica richiesta HTTP, che può essere inviata all'batchPath specificato nel documento di discovery dell'API. Il percorso predefinito è /batch/api_name/api_version. Questa sezione descrive la sintassi batch in dettaglio; di seguito è riportato un esempio.

Nota: un insieme di n richieste raggruppate viene conteggiato ai fini del limite di utilizzo come n richieste, non come una singola richiesta. La richiesta batch viene suddivisa in un insieme di richieste prima dell'elaborazione.

Formato di una richiesta batch

Una richiesta batch è una singola richiesta HTTP standard contenente più chiamate all'API Google Drive, che utilizza il tipo di contenuto multipart/mixed. All'interno di questa richiesta HTTP principale, ciascuna delle parti contiene una richiesta HTTP nidificata.

Ogni parte inizia con la propria intestazione HTTP Content-Type: application/http. Può anche avere un'intestazione Content-ID facoltativa. Tuttavia, le intestazioni della parte servono solo a contrassegnare l'inizio della parte e sono separate dalla richiesta nidificata. Dopo che il server ha scompattato 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. La richiesta HTTP deve contenere solo la parte di percorso dell'URL; gli URL completi non sono consentiti nelle richieste collettive.

Le intestazioni HTTP per la richiesta batch esterna, ad eccezione delle intestazioni Content- come Content-Type, si applicano a ogni richiesta del batch. Se specifichi una determinata intestazione HTTP sia nella richiesta esterna sia in una singola chiamata, il valore dell'intestazione della singola chiamata sostituisce il valore dell'intestazione della richiesta batch esterna. Le intestazioni di una singola chiamata si applicano solo a quella chiamata.

Ad esempio, se fornisci un'intestazione Authorization per una chiamata specifica, questa intestazione si applica solo a quella chiamata. Se fornisci un'intestazione Authorization per la richiesta esterna, questa intestazione si applica a tutte le singole chiamate, a meno che non vengano sostituite con intestazioni Authorization proprie.

Quando il server riceve la richiesta raggruppata, applica i parametri di query e le intestazioni della richiesta esterna (se appropriato) a ogni parte e poi tratta ogni parte come se fosse una richiesta HTTP separata.

Risposta a una richiesta batch

La risposta del server è una singola risposta HTTP standard con un tipo di contenuto multipart/mixed; ogni parte è la risposta a una delle richieste nella richiesta raggruppata, nello stesso ordine delle richieste.

Come le parti della richiesta, ogni parte della risposta contiene una risposta HTTP completa, inclusi un codice di stato, le intestazioni e il corpo. Come le parti nella richiesta, ogni parte della risposta è preceduta da un'intestazione Content-Type che ne indica l'inizio.

Se una determinata parte della richiesta aveva un'intestazione Content-ID, la parte corrispondente della risposta ha un'intestazione Content-ID corrispondente, con il valore originale preceduto dalla stringa response-, come mostrato nell'esempio seguente.

Nota: il server potrebbe eseguire le chiamate in qualsiasi ordine. Non aspettarti che vengano eseguite nell'ordine in cui le hai specificate. Se vuoi assicurarti che due chiamate vengano eseguite in un determinato ordine, non puoi inviarle in una singola richiesta; invia invece la prima da sola, quindi attendi la risposta alla prima prima di inviare la seconda.

Esempio

L'esempio seguente mostra l'utilizzo del raggruppamento con l'API Google Drive.

Esempio di richiesta batch

POST https://www.googleapis.com/batch/drive/v3
Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)
Content-Type: multipart/mixed; boundary=END_OF_PART
Content-Length: 963


--END_OF_PART
Content-Length: 337
Content-Type: application/http
content-id: 1
content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id
Authorization: Bearer authorization_token
Content-Length: 70
Content-Type: application/json; charset=UTF-8

{
  "emailAddress":"example@appsrocks.com",
  "role":"writer",
  "type":"user"
}
--END_OF_PART
Content-Length: 353
Content-Type: application/http
content-id: 2
content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false
Authorization: Bearer authorization_token
Content-Length: 58
Content-Type: application/json; charset=UTF-8

{
   "domain":"appsrocks.com",
   "role":"reader",
   "type":"domain"
}
--END_OF_PART--

Esempio di risposta batch

Questa è la risposta alla richiesta di esempio nella sezione precedente.

HTTP/1.1 200 OK
Alt-Svc: quic=":443"; p="1"; ma=604800
Server: GSE
Alternate-Protocol: 443:quic,p=1
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
X-XSS-Protection: 1; mode=block
Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Date: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Vary: X-Origin
Vary: Origin
Expires: Fri, 13 Nov 2015 19:28:59 GMT


--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-1

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35

{
 "id": "12218244892818058021i"
}

--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-2

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35

{
 "id": "04109509152946699072k"
}

--batch_6VIxXCQbJoQ_AATxy_GgFUk--