Mejorar el rendimiento

Compresión con gzip

Una forma fácil y conveniente de reducir el ancho de banda necesario para cada solicitud es habilitar la compresión gzip. Aunque esto requiere un tiempo de CPU adicional para descomprimir los resultados, la compensación con los costos de la red suele hacer que valga la pena.

Si quieres recibir una respuesta codificada en gzip, debes establecer un encabezado de Accept-Encoding y modificar tu usuario-agente para que contenga la string gzip. A continuación, se presenta un ejemplo de encabezados HTTP formados de manera correcta para habilitar la compresión gzip:

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

Trabaja con recursos parciales

Otra forma de mejorar el rendimiento de tus llamadas a la API es enviar y recibir solo la parte de los datos que te interesa. Esto permite que tu aplicación evite la transferencia, el análisis y el almacenamiento de campos innecesarios, por lo que pueda usar recursos como la red, la CPU y la memoria con más eficiencia.

Existen los siguientes dos tipos de solicitudes parciales:

• Respuesta parcial: una solicitud en la que especificas qué campos incluir en la respuesta (usa el parámetro de la solicitud de fields).
• Parche: una solicitud de actualización en la que envías solo los campos que deseas cambiar (usa el verbo HTTP PATCH).

En las siguientes secciones, se proporcionan más detalles sobre cómo realizar solicitudes parciales.

Respuesta parcial

De forma predeterminada, el servidor muestra la representación completa de un recurso después de procesar las solicitudes. Para lograr un mejor rendimiento, puedes pedirle al servidor que envíe solo los campos que realmente necesitas y obtener una respuesta parcial en su lugar.

Si quieres solicitar una respuesta parcial, usa el parámetro de solicitud de fields para especificar los campos que deseas que se muestren. Puedes usar este parámetro con cualquier solicitud que muestre datos de respuesta.

Ten en cuenta que el parámetro de fields solo afecta a los datos de respuesta; no afecta a los datos que necesitas enviar, si los hay. Para reducir la cantidad de datos que envías cuando modificas recursos, usa una solicitud de parche.

Ejemplo

En el siguiente ejemplo, se muestra el uso del parámetro de fields con una API “de demostración” genérica (ficticia).

Solicitud simple: esta solicitud HTTP GET omite el parámetro de fields y muestra el recurso completo.

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

Respuesta de recursos completos: los datos de recursos completos incluyen los siguientes campos, junto con muchos otros que se omitieron para abreviar.

{
  "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",
    ...
  },
  ...
  ]
}

Solicitud de una respuesta parcial: la siguiente solicitud de este mismo recurso usa el parámetro de fields para reducir la cantidad de datos que se muestran de manera significativa.

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

Respuesta parcial: en respuesta a la solicitud anterior, el servidor envía una respuesta que contiene solo información similar junto con un arreglo de elementos reducido que incluye solo el título HTML y la información de característica de longitud en cada elemento.

200 OK

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

Ten en cuenta que la respuesta es un objeto JSON que incluye solo los campos seleccionados y sus objetos superiores adjuntos.

A continuación, se presentan los detalles sobre cómo dar formato al parámetro de fields. Luego, se presentan más detalles sobre qué es lo que se muestra en la respuesta.

Resumen de la sintaxis de los parámetros de campos

El formato del valor del parámetro de solicitud de fields se basa de manera general en la sintaxis de XPath. La sintaxis compatible se resume a continuación y se proporcionan ejemplos adicionales en la siguiente sección.

• Usa una lista separada por comas para seleccionar varios campos.
• Usa a/b si quieres seleccionar un campo b que se anida en el campo a; usa a/b/c para seleccionar un campo c anidado en b.
  

  Excepción: En cuanto a las respuestas a la API que usan wrappers de “datos”, en los que la respuesta se anida en un objeto data que luce como data: { ... }, no incluyas “data” en la especificación fields. Incluir el objeto de datos con una especificación de campos como data/a/b provoca un error. En su lugar, solo usa una especificación de fields como a/b.

• Puedes usar un subselector para solicitar un conjunto de subcampos específicos de objetos o arreglos, si colocas las expresiones entre paréntesis “( )”.

  Por ejemplo: fields=items(id,author/email) solo muestra el ID del elemento y el correo electrónico del autor para cada elemento del arreglo de elementos. También puedes especificar un subcampo único, en el que fields=items(id) es equivalente a fields=items/id.

• Usa comodines en las selecciones de campo, si es necesario.

  Por ejemplo: fields=items/pagemap/* selecciona todos los objetos en un pagemap.

Más ejemplos del uso del parámetro de campos

En los siguientes ejemplos, se incluyen descripciones de cómo el valor del parámetro de fields afecta la respuesta.

Nota: Al igual que con todos los valores de los parámetros de búsqueda, el valor del parámetro de fields debe estar codificado como URL. Para facilitar la lectura, en los ejemplos de este documento se omite la codificación.

Identifica los campos que deseas que se muestren o realiza selecciones de campo.

El valor del parámetro de solicitud de fields es una lista de campos separada por comas y cada campo se especifica en relación con la raíz de la respuesta. Por lo tanto, si realizas una operación de lista, la respuesta es una colección y suele incluir un arreglo de recursos. Si realizas una operación que muestra un recurso único, los campos se especifican en relación con ese recurso. Si el campo que seleccionas es un arreglo, o es parte de uno, el servidor muestra la parte seleccionada de todos los elementos del arreglo.

A continuación, se presentan algunos ejemplos a nivel de colección:

Ejemplos	Efecto
items	Muestra todos los elementos del arreglo de elementos, incluidos todos los campos de cada elemento, pero ningún otro campo.
etag,items	Muestra el campo etag y todos los elementos del arreglo de elementos.
items/title	Muestra solo el campo title para todos los elementos del arreglo de elementos. Cada vez que se muestra un campo anidado, la respuesta incluye los objetos superiores adjuntos. Los campos superiores no incluyen ningún otro campo secundario, a menos que también se seleccionen de manera explícita.
context/facets/label	Muestra solo el campo label para todos los miembros del arreglo facets, que se anida en el objeto context.
items/pagemap/*/title	Para cada elemento del arreglo de elementos, muestra solo el campo title (si está presente) de todos los objetos que son secundarios de pagemap.

A continuación, se presentan algunos ejemplos a nivel de recursos:

Ejemplos	Efecto
title	Muestra el campo title del recurso solicitado.
author/uri	Muestra el subcampo uri del objeto author en el recurso solicitado.
links/*/href	Muestra el campo href de todos los objetos que son secundarios de links.

Solicita solo las partes de los campos específicos mediante subselecciones.

De forma predeterminada, si tu solicitud especifica campos particulares, el servidor muestra los objetos o los elementos del arreglo en su totalidad. Puedes especificar una respuesta que incluya solo ciertos subcampos. Para hacerlo, usa la sintaxis de la subselección de “( )”, como se muestra en el siguiente ejemplo.

Ejemplo	Efecto
items(title,author/uri)	Muestra solo los valores del title y el uri del autor para cada elemento del arreglo de elementos.

Controla las respuestas parciales

Después de que un servidor procesa una solicitud válida que incluye el parámetro de búsqueda de fields, devuelve un código de estado HTTP 200 OK, junto con los datos solicitados. Si el parámetro de búsqueda de fields tiene un error o no es válido, el servidor muestra un código de estado HTTP 400 Bad Request, junto con un mensaje de error en el que se comunica al usuario qué fue lo que falló con su selección de campos (por ejemplo, "Invalid field selection a/b").

A continuación, se presenta el ejemplo de una respuesta parcial que se muestra en la sección de introducción anterior. La solicitud usa el parámetro de fields para especificar qué campos mostrar.

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

La respuesta parcial se ve de la siguiente manera:

200 OK

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

Nota: En cuanto a las API que admiten parámetros de búsqueda para la paginación de datos (maxResults y nextPageToken, por ejemplo), usa esos parámetros a fin de reducir los resultados de cada búsqueda a un tamaño administrable. De lo contrario, los aumentos del rendimiento posibles con una respuesta parcial podrían no realizarse.

Parche (actualización parcial)

También puedes evitar el envío de datos innecesarios cuando modificas recursos. Si quieres enviar datos actualizados solo para los campos específicos que modificas, usa el verbo HTTP PATCH. La semántica de parches descrita en este documento es diferente (y más simple) de lo que era para la implementación anterior de GData de actualización parcial.

En el siguiente ejemplo, se muestra cómo el uso de un parche minimiza los datos que necesitas enviar para realizar una actualización pequeña.

Ejemplo

En este ejemplo, se muestra una solicitud de parche simple para actualizar solo el título de un recurso de API “de demostración” genérica (ficticia). El recurso también tiene un comentario, un conjunto de características, un estado y muchos otros campos, pero esta solicitud solo envía el campo title, ya que ese es el único campo que se modifica:

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

{
  "title": "New title"
}

Respuesta:

200 OK

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

El servidor muestra un código de estado 200 OK junto con la representación completa del recurso actualizado. Debido a que solo se incluyó el campo title en la solicitud de parche, ese es el único valor diferente al anterior.

Nota: Si usas el parámetro de fields de la respuesta parcial en combinación con el parche, puedes aumentar aún más la eficiencia de tu solicitud de actualización. Una solicitud de parche solo reduce el tamaño de la solicitud. Una respuesta parcial reduce el tamaño de la respuesta. Entonces, para reducir la cantidad de datos enviados en ambas direcciones, usa una solicitud de parche con el parámetro de fields.

Semántica de una solicitud de parche

El cuerpo de la solicitud de parche incluye solo los campos de recursos que deseas modificar. Cuando especificas un campo, debes incluir cualquier objeto superior adjunto, como los superiores adjuntos se muestran con una respuesta parcial. Los datos modificados que envíes se combinan con los datos para el objeto superior, si es que hay uno.

• Agrega: para agregar un campo que aún no existe, especifica el campo nuevo y su valor.
• Modifica: para modificar el valor de un campo existente, especifica el campo y configúralo en el valor nuevo.
  
• Borra: para borrar un campo, especifícalo y configúralo como null. Por ejemplo, "comment": null. También puedes borrar un objeto completo (si es mutable), si lo configuras como null. Si usas la biblioteca cliente de la API de Java, usa Data.NULL_STRING. Para obtener más información, consulta la página sobre JSON null.

Nota sobre los arreglos: Las solicitudes de parche que contienen arreglos reemplazan el arreglo existente por el que proporcionaste. No puedes modificar, agregar o borrar elementos de un arreglo por etapas.

Usa parches en un ciclo de lectura, modificación, escritura

Comenzar por recuperar una respuesta parcial con los datos que deseas modificar puede ser una práctica útil. En particular, esto es importante para los recursos que usan ETags, ya que debes proporcionar el valor de ETag actual en el encabezado HTTP If-Match para actualizar el recurso con éxito. Después de obtener los datos, puedes modificar los valores que deseas cambiar y enviar la representación parcial modificada con una solicitud de parche. A continuación, se presenta un ejemplo en el que se supone que el recurso de demostración usa ETags:

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

La respuesta parcial es la siguiente información:

200 OK

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

La siguiente solicitud de parche se basa en esa respuesta. Como se muestra a continuación, también usa el parámetro de fields para limitar los datos que se muestran en la respuesta del parche:

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. */
  },
}

El servidor responde con un código de estado HTTP 200 OK y la representación parcial del recurso actualizado:

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. */
  }
}

Crea una solicitud de parche directamente

En cuanto a algunas solicitudes de parches, debes realizarlas en función de los datos que recuperaste antes. Por ejemplo, si deseas agregar un elemento a un arreglo y no quieres perder ninguno de los elementos del arreglo existentes, primero debes obtener los datos existentes. De manera similar, si una API usa ETags, debes enviar el valor de ETag anterior con tu solicitud para actualizar el recurso de manera correcta.

Nota: Puedes usar un encabezado HTTP "If-Match: *" para forzar la aplicación de un parche cuando las ETags están en uso. Si haces esto, no necesitas realizar operaciones de lectura antes de realizar las de escritura.

Para otras situaciones, sin embargo, puedes crear la solicitud de parche directamente, sin recuperar primero los datos existentes. Por ejemplo, puedes configurar con facilidad una solicitud de parche que actualiza un campo a un valor nuevo o agrega un campo nuevo. A continuación, se muestra un ejemplo:

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 esta solicitud, si el campo de comentario tiene un valor existente, el valor nuevo lo reemplaza; de lo contrario, se establece en el valor nuevo. De manera similar, si hubiera una característica de volumen, su valor se reemplaza; si no, se crea. Si está establecido, el campo de precisión se quita.

Controla la respuesta a un parche

Después de procesar una solicitud de parche válida, la API muestra un código de respuesta HTTP 200 OK junto con la representación completa del recurso modificado. Si la API usa ETags, el servidor actualiza los valores de ETag cuando procesa con éxito una solicitud de parche, al igual que lo hace con PUT.

La solicitud de parche muestra la representación de recursos completa, a menos que uses el parámetro de fields para reducir la cantidad de datos que se muestran.

Si una solicitud de parche genera un estado de recursos nuevo que no es válido de manera sintáctica o semántica, el servidor muestra un código de estado HTTP 400 Bad Requesto 422 Unprocessable Entity y el estado de recursos permanece igual. Por ejemplo, si intentas borrar el valor de un campo obligatorio, el servidor muestra un error.

Notación alternativa cuando no se admite el verbo HTTP PATCH

Si tu firewall no permite solicitudes HTTP PATCH, entonces haz una solicitud HTTP POST y configura el encabezado de anulación como PATCH, como se muestra a continuación:

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

Diferencia entre parche y actualización

En la práctica, cuando envías datos para una solicitud de actualización que usa el verbo HTTP PUT, solo necesitas enviar los campos obligatorios o los opcionales; si envías valores para los campos que establece el servidor, se ignoran. Aunque esto puede parecer otra forma de hacer una actualización parcial, este enfoque tiene algunas limitaciones. Con las actualizaciones que usan el verbo HTTP PUT, la solicitud falla si no proporcionas los parámetros obligatorios y borra los datos establecidos antes si no proporcionas los parámetros opcionales.

Por esta razón, es mucho más seguro usar un parche. Solo debes proporcionar datos para los campos que deseas cambiar; los campos que omites no se borran. La única excepción a esta regla se produce con la repetición de elementos o arreglos: si omites todos, se mantienen tal como están; si proporcionas alguno de ellos, todo el conjunto se reemplaza por el conjunto que proporciones.

Descripción general

Cada conexión HTTP que tu cliente realiza da como resultado una cierta cantidad de sobrecarga. La API de Google Drive admite el procesamiento por lotes, a fin de permitir que tu cliente coloque varias llamadas a la API en una sola solicitud HTTP.

A continuación, se detallan algunos ejemplos de situaciones en las que te sería útil usar el procesamiento por lotes:

• Recuperar metadatos de una gran cantidad de archivos
• Actualizar metadatos o propiedades de forma masiva
• Cambiar los permisos de una gran cantidad de archivos, como agregar un usuario o grupo nuevo
• Sincroniza los datos del cliente local por primera vez o después de estar sin conexión durante un período prolongado.

En cada caso, en lugar de enviar cada llamada por separado, puedes agruparlas en una única solicitud HTTP. Todas las solicitudes internas deben ir en la misma API de Google.

Tienes un límite de 100 llamadas por cada solicitud por lotes. Si necesitas hacer más llamadas, usa varias solicitudes por lotes.

Nota: El sistema por lotes para la API de Google Drive emplea la misma sintaxis que el sistema de procesamiento por lotes OData, pero difiere en la semántica.

Entre las restricciones adicionales, se incluyen las siguientes:

• Es posible que las solicitudes por lotes con más de 100 llamadas generen un error.
• Hay un límite de 8,000 caracteres para la longitud de la URL de cada solicitud interna.
• Google Drive no admite operaciones por lotes para contenido multimedia, ya sea para subir o descargar archivos, o para exportarlos.

Detalles del lote

Una solicitud por lotes consta de varias llamadas a la API combinadas en una solicitud HTTP, que pueden enviarse al batchPath especificado en el documento de descubrimiento de la API. La ruta de acceso predeterminada es /batch/api_name/api_version. En esta sección, se describe la sintaxis del lote en detalle; más adelante, se muestra un ejemplo.

Nota: Un conjunto de solicitudes n agrupadas se considera en tu límite de uso como solicitudes n, no como una sola. La solicitud por lotes se divide en un conjunto de solicitudes antes de procesarse.

Formato de una solicitud por lotes

Una solicitud por lotes es una solicitud HTTP estándar que contiene múltiples llamadas a la API de Google Drive, con el tipo de contenido multipart/mixed. Dentro de esa solicitud HTTP principal, cada una de las partes contiene una solicitud HTTP anidada.

Cada parte comienza con su propio encabezado HTTP Content-Type: application/http. También puede tener un encabezado opcional Content-ID. Sin embargo, los encabezados de partes solo están allí para marcar el comienzo de la parte; están separados de la solicitud anidada. Una vez que el servicio desenvuelve la solicitud por lotes en diferentes solicitudes, los encabezados de las partes se ignoran.

El cuerpo de cada parte es en sí mismo una solicitud HTTP completa, con su propio verbo, URL, encabezados y cuerpo. La solicitud HTTP debe contener solamente la parte de la ruta de la URL; no se admiten URL enteras en las solicitudes por lotes.

Los encabezados HTTP para la solicitud por lotes externa, excepto por los encabezados Content-, como Content-Type, se aplican a cada solicitud en el lote. Si especificas cierto encabezado HTTP tanto en la solicitud externa como en una llamada individual, el valor del encabezado de la llamada individual reemplaza el valor del encabezado de la solicitud por lotes externa. Los encabezados de una llamada individual solo se aplican a esa llamada.

Por ejemplo, si proporcionas un encabezado de autorización para una llamada específica, ese encabezado se aplica solamente a esa llamada. Si proporcionas un encabezado de autorización para la solicitud externa, se aplica a todas las llamadas individuales, a menos que la reemplacen con encabezados de autorización propios.

Cuando el servidor recibe la solicitud por lotes, aplica los encabezados y parámetros de consulta de la solicitud externa (según corresponda) a cada parte y, a continuación, trata cada parte como una solicitud HTTP separada.

Respuesta a una solicitud por lotes

La respuesta del servidor es una sola respuesta HTTP estándar con un tipo de contenido multipart/mixed; cada parte es la respuesta a una de las solicitudes de la solicitud por lotes, en el mismo orden que las solicitudes.

Como las partes de la solicitud, cada parte de respuesta contiene una respuesta HTTP completa, que incluye un código de estado, encabezados y un cuerpo. Además, cada una está precedida por un encabezado Content-Type que marca el comienzo de la parte.

Si cierta parte de la solicitud tenía un encabezado Content-ID, la parte correspondiente de la respuesta tendrá un encabezado Content-ID que coincida y un valor original precedido por la string response-, como se muestra en el siguiente ejemplo.

Nota: Es posible que el servidor realice llamadas en cualquier orden. No cuentes con que se ejecutarán en el orden en que las especificaste. Si quieres garantizar que dos llamadas sucedan en un orden determinado, no puedes enviarlas en una misma solicitud; en cambio, envía la primera sola, espera una respuesta y, luego, envía la segunda.

Ejemplo

En el siguiente ejemplo, se muestra el uso del procesamiento por lotes con la API de Google Drive.

Ejemplo de solicitud por lotes

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--

Ejemplo de respuesta por lotes

Esta es la respuesta a la solicitud de ejemplo de la sección anterior.

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--