Melhorar desempenho

Este documento aborda algumas técnicas que você pode usar para melhorar o desempenho do aplicativo. Em alguns casos, exemplos de outras APIs ou de APIs genéricas são usados para ilustrar as ideias apresentadas. No entanto, os mesmos conceitos se aplicam à API Compute Engine.

Compactação usando gzip

Uma maneira fácil e conveniente de reduzir a largura de banda necessária a cada solicitação é ativar a compactação gzip. Embora isso exija mais tempo de CPU para descompactar os resultados, a redução dos custos de rede normalmente faz com que esse método valha muito a pena.

Para receber uma resposta codificada em gzip, você precisa definir um cabeçalho Accept-Encoding e modificar seu user agent para conter a string gzip. Veja um exemplo de cabeçalhos HTTP formados devidamente para permitir a compactação gzip:

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

Como trabalhar com recursos parciais

Outra maneira de melhorar o desempenho das chamadas da API é enviar e receber somente a parte dos dados que você quer. Assim, evita-se a transferência, a análise e o armazenamento de campos desnecessários no aplicativo para que recursos como rede, CPU e memória sejam usados de maneira mais eficiente.

Há dois tipos de solicitações parciais:

• Resposta parcial: uma solicitação em que você especifica quais campos serão incluídos na resposta. Use o parâmetro de solicitação fields.
• Patch: uma solicitação de atualização em que você envia somente os campos que serão alterados. Use o verbo HTTP PATCH.

Nas seções a seguir são fornecidos mais detalhes sobre como fazer solicitações parciais.

Resposta parcial

Por padrão, depois de processar as solicitações, o servidor envia de volta a representação completa de um recurso. Para melhorar o desempenho, solicite ao servidor o envio apenas dos campos realmente necessários para receber uma resposta parcial.

Para solicitar uma resposta parcial, use o parâmetro de solicitação fields para especificar os campos a serem retornados. Use esse parâmetro com qualquer solicitação que retorne dados de resposta.

Observe que o parâmetro fields afeta apenas os dados de resposta. Ele não afeta os dados que você precisa enviar, se houver. Para reduzir a quantidade de dados enviados durante a modificação de recursos, use uma solicitação de patch.

Exemplo

O exemplo a seguir mostra o uso do parâmetro fields com uma API "Demo" genérica (fictícia).

Solicitação simples: essa solicitação HTTP GET omite o parâmetro fields e retorna o recurso completo.

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

Resposta de recursos completos: os dados de recursos completos incluem os campos a seguir, além de muitos outros omitidos para agilizar o processo.

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

Solicitação de uma resposta parcial: na solicitação a seguir, para esse mesmo recurso, o parâmetro fields é usado para reduzir de modo significativo a quantidade de dados retornados.

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

Resposta parcial: em reação à solicitação acima, o servidor envia de volta uma resposta que contém somente as informações de tipo, além de uma matriz de itens pareados com características de tamanho e título HTML em cada item.

200 OK

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

Observe que a resposta é um objeto JSON que contém apenas os campos selecionados e os respectivos objetos pais.

Veja detalhes sobre como formatar o parâmetro fields a seguir, seguidos por mais detalhes sobre o que exatamente é retornado na resposta.

Resumo da sintaxe do parâmetro "Campos"

O formato do valor do parâmetro da solicitação fields baseia-se vagamente na sintaxe XPath. Veja abaixo um resumo da sintaxe compatível e outros exemplos.

• Use uma lista separada por vírgulas para selecionar diversos campos.
• Use a/b para selecionar um campo b aninhado no campo a. Use a/b/c para selecionar um campo c aninhado em b.
  

  Exceção: Para respostas da API que usam wrappers "data", em que a resposta é aninhada em um objeto data semelhante a data: { ... }, não inclua "data" na especificação fields. A inclusão do objeto de dados com uma especificação de campos como data/a/b causa um erro. Em vez disso, basta usar uma especificação fields como a/b.

• Use um sub-seletor para solicitar um conjunto de subcampos específicos de matrizes ou objetos. Basta colocar expressões entre parênteses "( )".

  Por exemplo: fields=items(id,author/email) retorna apenas o ID do item e o e-mail do autor para cada elemento na matriz de itens. Também é possível especificar um único subcampo, em que fields=items(id) é equivalente a fields=items/id.

• Se necessário, use caracteres curinga em seleções de campo.

  Por exemplo: fields=items/pagemap/* seleciona todos os objetos em um pagemap.

Mais exemplos do uso do parâmetro fields

Os exemplos abaixo incluem descrições de como o valor do parâmetro fields afeta a resposta.

Observação: assim como com todos os valores de parâmetro de consulta, fields também precisa ter codificação de URL. Para facilitar a leitura, os exemplos neste documento estão sem a codificação.

Identifique os campos a serem retornados ou faça seleções de campos.

O valor de parâmetro da solicitação fields é uma lista de campos separados por vírgulas e cada campo é especificado em relação à raiz da resposta. Portanto, se você estiver executando uma operação de lista, a resposta será uma coleção que, geralmente, inclui uma matriz de recursos. Se você estiver executando uma operação que retorne um único recurso, os campos serão especificados em relação a esse recurso. Se o campo selecionado for uma matriz, ou parte dela, o servidor retornará a parte selecionada de todos os elementos na matriz.

Veja alguns exemplos do nível de coleção:

Exemplos	Efeito
items	Retorna todos os elementos da matriz de itens, incluindo todos os campos em cada elemento, mas nenhum outro campo.
etag,items	Retorna o campo etag e todos os elementos na estrutura de itens.
items/title	Retorna apenas o campo de title para todos os elementos da matriz de itens. Sempre que um campo aninhado for retornado, a resposta incluirá os respectivos objetos pais. Os campos pai não incluem outro campo filho, a menos que eles também sejam selecionados explicitamente.
context/facets/label	Retorna apenas o campo label para todos os membros da matriz facets, que é aninhada sob o objeto context.
items/pagemap/*/title	Para cada elemento na matriz de itens, retorna apenas o campo title, se presente, de todos os objetos filhos de pagemap.

Veja alguns exemplos no nível do recurso:

Exemplos	Efeito
title	Retorna o campo title do recurso solicitado.
author/uri	Retorna o subcampo uri do objeto author no recurso solicitado.
links/*/href	Retorna o campo href de todos os objetos filhos de links.

Solicite apenas partes de campos específicos usando subseleções.

Por padrão, se houver campos particulares especificados na solicitação, todos os objetos ou elementos da matriz serão retornados pelo servidor. É possível especificar uma resposta que inclua apenas determinados subcampos. Para isso, use a sintaxe de subseleção "( )", como no exemplo abaixo.

Exemplo	Efeito
items(title,author/uri)	Retorna apenas os valores de title e uri do autor para cada elemento na matriz de itens.

Como processar respostas parciais

Depois que o servidor processar uma solicitação válida que inclua o parâmetro de consulta fields, ele retorna um código de status 200 OK HTTP, junto com os dados solicitados. Se o parâmetro de consulta fields tiver um erro ou for inválido, o servidor retornará um código de status HTTP 400 Bad Request com uma mensagem informando ao usuário o que havia de errado com a seleção de campos. Por exemplo, "Invalid field selection a/b".

Veja o exemplo de resposta parcial mostrado na seção introdutória acima. A solicitação usa o parâmetro fields para especificar os campos que precisam ser retornados.

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

A resposta parcial é semelhante a esta:

200 OK

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

Observação: em APIs compatíveis com parâmetros de consulta para paginação de dados (por exemplo, maxResults e nextPageToken), use esses parâmetros para reduzir os resultados de cada consulta a um tamanho administrável. Caso contrário, os possíveis ganhos de desempenho talvez não se concretizem.

Patch (atualização parcial)

É possível também evitar o envio de dados desnecessários ao modificar recursos. Para enviar dados atualizados apenas nos campos que estiverem sendo alterados, use o verbo HTTP PATCH. A semântica do patch descrita neste documento é diferente e mais simples do que aquela da implementação de atualização parcial do GData, que é mais antiga.

Veja no pequeno exemplo abaixo como o uso do patch minimiza os dados necessários para fazer uma pequena atualização.

Exemplo

Neste exemplo, há uma solicitação simples de patch para atualizar apenas o título do recurso de uma "Demo" API genérica (fictícia). O recurso também tem um comentário, um conjunto de características, status e muitos outros campos, mas essa solicitação envia apenas o campo title, porque esse é o único campo que está sendo modificado:

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

{
  "title": "New title"
}

Resposta:

200 OK

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

O servidor retorna um código de status 200 OK e a representação completa do recurso atualizado. Como apenas o campo title foi incluído na solicitação de patch, esse é o único valor diferente de antes.

Observação: se você usar o parâmetro fields da resposta parcial em combinação com um patch, será possível aumentar ainda mais a eficiência de suas solicitações de atualização. Uma solicitação de correção só reduz o tamanho da solicitação. Uma resposta parcial reduz o tamanho da resposta. Portanto, para reduzir a quantidade de dados enviados nas duas direções, use uma solicitação de patch com o parâmetro fields.

Semântica de uma solicitação de patch

O corpo da solicitação de patch inclui somente os campos do recurso que você quer modificar. Ao especificar um campo, é necessário incluir qualquer objeto pai que tiver sido inserido, assim como os pais inseridos são retornados com uma resposta parcial. Os dados modificados que você envia são mesclados com os dados do objeto pai, se houver um.

• Adicionar: para adicionar um campo que ainda não existe, especifique o novo campo e o valor correspondente.
• Modificar: para alterar o valor de um campo existente, especifique o campo e configure-o como o novo valor.
  
• Excluir: para excluir um campo, especifique-o e configure-o como null. Por exemplo, "comment": null. Você também pode excluir um objeto inteiro (se for mutável) configurando-o como null. Se você estiver usando a biblioteca de cliente da API Java, use Data.NULL_STRING. Para mais detalhes, consulte JSON null.

Observação sobre matrizes: solicitações de patch que contenham matrizes substituem a matriz existente pela fornecida por você. Não é possível modificar, adicionar ou excluir itens em uma matriz facilmente.

Como usar patch em um ciclo de leitura-modificação-gravação

Pode ser útil começar com a recuperação de uma resposta parcial com os dados que quer modificar. Isso é especialmente importante para recursos que usam ETags, porque é preciso fornecer o valor de ETag atual no cabeçalho HTTP If-Match para atualizar o recurso com êxito. Depois de receber os dados, você poderá modificar os valores que quer alterar e reenviar a representação parcial modificada com uma solicitação de correção. Veja um exemplo que pressupõe que o recurso de demonstração usa ETags:

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

Esta é a resposta parcial:

200 OK

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

A solicitação de patch a seguir é baseada nessa resposta. Como mostrado abaixo, ela também usa o parâmetro fields para limitar os dados retornados na resposta do 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. */
  },
}

O servidor responde com um código de status HTTP "200 OK" e a representação parcial do recurso atualizado:

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

Como criar uma solicitação de patch diretamente

Algumas solicitações de patch precisam ser baseadas nos dados recuperados anteriormente. Por exemplo, para adicionar um item a uma matriz sem perder elementos dela, primeiro extraia os dados atuais. Da mesma maneira, se uma API usa ETags, é necessário enviar o valor anterior da ETag com sua solicitação para atualizar o recurso corretamente.

Observação: use um cabeçalho HTTP "If-Match: *" para forçar a passagem de um patch quando as ETags forem usadas. Se fizer isso, não será preciso fazer a leitura antes da gravação.

Porém, em outras situações, é possível construir a solicitação de patch diretamente, sem recuperar os dados atuais antes. Por exemplo, é fácil configurar uma solicitação de patch que atualiza um campo com um novo valor ou adiciona um novo campo. Veja um exemplo:

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

Se o campo estiver vazio, essa solicitação definirá um valor, caso contrário, ela substituirá o valor atual. Da mesma maneira, se houvesse uma característica de volume, o valor seria substituído. Caso contrário, um novo seria criado. O campo "accuracy", se definido, seria removido.

Processar resposta para um patch

Após processar uma solicitação de patch válida, a API retorna um código de resposta HTTP 200 OK com a representação completa do recurso modificado. Caso a API use ETags, o servidor atualizará os valores delas durante o processamento de uma solicitação de patch, como acontece com PUT.

A solicitação de correção retorna toda a representação do recurso, a menos que você use o parâmetro fields para reduzir a quantidade de dados retornados.

Se uma solicitação de correção resultar em um novo estado de recurso sintático ou semanticamente inválido, o servidor retornará um código de status HTTP 400 Bad Request ou 422 Unprocessable Entity e o estado do recurso permanecerá inalterado. Por exemplo, ao tentar excluir o valor de um campo obrigatório, o servidor retorna um erro.

Notação alternativa quando não houver suporte para o verbo HTTP PATCH

Caso o firewall não permita solicitações de HTTP PATCH, faça uma solicitação HTTP POST e configure o cabeçalho de substituição como PATCH. Veja o exemplo abaixo:

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

Diferença entre patch e atualização

Na prática, ao enviar dados para uma solicitação de atualização que usa o verbo HTTP PUT, basta enviar os campos obrigatórios ou opcionais. Os valores enviados para campos definidos pelo servidor serão ignorados. Embora possa parecer outro método de se fazer uma atualização parcial, esta abordagem tem algumas limitações. Com atualizações que usam o verbo HTTP PUT, a solicitação falha quando não são fornecidos parâmetros obrigatórios, e remove dados já definidos quando parâmetros opcionais não são informados.

É muito mais seguro usar o patch por esse motivo. Você fornece somente os dados dos campos que quer alterar. Os campos omitidos não são apagados. A única exceção a essa regra ocorre com matrizes ou elementos repetidos. Se você os omite, eles ficam como estão. Se fornece parte deles, o conjunto inteiro é substituído pelo conjunto fornecido.