Dicas de desempenho

Este documento abrange algumas técnicas que podem ser usadas para melhorar o desempenho do seu 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 são aplicáveis à API Google Pay for Passes.

Como usar gzip

Uma maneira fácil e prática 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 realizar duas ações: definir um cabeçalho Accept-Encoding e modificar seu user-agent para conter a string gzip. Veja um exemplo de cabeçalhos HTTP devidamente formados para permitir a compactação em 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.

O parâmetro fields só afetará os dados de resposta, e não os de envio, 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 de "demonstração" 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 resposta parcial: na solicitação a seguir, para esse mesmo recurso, o parâmetro fields é usado para reduzir significativamente 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"
    }
  },
  ...
  ]
}

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

Os detalhes sobre como formatar o parâmetro fields são abordados a seguir. Depois há mais informações sobre os elementos retornados na resposta.

Resumo da sintaxe do parâmetro "fields"

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 e a/b/c para um campo c dentro de b.

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

  • Use um subseletor 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 código 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 acontece com todos os valores de parâmetro de consulta, o valor de parâmetro 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 que quer retornar ou faça seleções de campo.
O valor do parâmetro de solicitação fields é uma lista de campos separados por vírgula, e cada um é 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 no 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 da matriz 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 pais não incluem outro campo filho, a menos que eles também sejam selecionados explicitamente.
context/facets/label Retorna somente o campo label para todos os membros da matriz facets, que está aninhada no objeto context.
items/pagemap/*/title Para cada elemento da matriz de itens, a coleção retorna apenas o campo title, se presente, de todos os objetos filhos de pagemap.

Veja alguns exemplos com base no 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 alguns subcampos. Para fazer isso, use a sintaxe de subseleção "( )", como no exemplo abaixo.
Exemplo Efeito
items(title,author/uri) Retorna apenas os valores do title e do uri do autor referentes a cada elemento da matriz de itens.

Como processar respostas parciais

Após um servidor processar uma solicitação válida com o parâmetro de consulta fields, ele enviará de volta um código de status HTTP 200 OK, além dos 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 da resposta parcial apresentado na seção introdutória acima. A seleção utiliza o parâmetro fields para determinar quais campos serão retornados.

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

A resposta parcial tem esta aparência:

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 ganhos de desempenho possíveis com a resposta parcial não serão alcançados.

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 exemplo abaixo como o uso do patch minimiza os dados necessários para fazer uma pequena atualização.

Exemplo

Este exemplo mostra uma solicitação de patch simples para atualizar somente o título de um recurso de uma API de "demonstração" genérica (fictícia). O recurso também tem um comentário, um conjunto de características, um status e muitos outros campos, mas esta solicitação envia apenas o campo title, já que é o único a ser 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 com a representação completa do recurso atualizado. Como foi incluído apenas o campo title na solicitação de patch, esse é o único valor diferente do anterior.

Observação: se o parâmetro fields da resposta parcial for usado com o patch, você aumentará ainda mais a eficiência das suas solicitações de atualização. Uma solicitação de patch apenas reduz o tamanho da solicitação. Já uma resposta parcial reduz o tamanho da resposta. Assim, para reduzir a quantidade de dados enviados em ambos os sentidos, use uma solicitação 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 de recurso que você quer modificar. Ao especificar um campo, é necessário adicionar todos os objetos pai incluídos, da forma como eles são retornados com uma resposta parcial. Os dados modificados que você enviar serão mesclados às informações 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 atual, especifique o novo campo e configure-o como o novo valor.
  • Excluir: para excluir um campo, especifique o campo e configure-o como null. Por exemplo, "comment": null. Você também pode excluir um objeto inteiro (se ele for mutável), configurando-o como null. Se você estiver usando a Biblioteca cliente da API Java, em vez disso, opte por Data.NULL_STRING. Para mais detalhes, consulte JSON null.

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

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, já que é necessário fornecer o valor atual da ETag ao cabeçalho HTTP If-Match para atualizar o recurso. Depois de receber os dados, será possível modificar os valores que quer alterar e devolver a representação parcial modificada com uma solicitação de patch. Veja um exemplo que presume 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, você precisa 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 transmissão de um patch quando as ETags estiverem sendo usadas.  Se fizer isso, você não precisará fazer a leitura antes da gravação.

Porém, em outras situações, você pode 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 novo. 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.

Como processar a 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.

Toda a representação do recurso é retornada pela solicitação de patch, a menos que o parâmetro fields seja usado para reduzir a quantidade de dados retornados.

Quando uma solicitação de patch resulta em um novo estado de recurso sintática ou semanticamente inválido, o servidor retorna um código de status 400 Bad Request ou 422 Unprocessable Entity HTTP e o estado do recurso permanece 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. Isso pode parecer outra maneira de fazer uma atualização parcial, mas essa 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 forem omitidos, eles ficarão como estão. Se você fornecer parte deles, o conjunto inteiro será substituído pelo conjunto que você inseriu.

Enviar comentários sobre…

Google Pay for Passes