Práticas recomendadas

Autorização

Todas as solicitações para a API Google Photos Library precisam ser autorizadas por um usuário autenticado.

Os detalhes do processo de autorização para o OAuth 2.0 variam um pouco, dependendo sobre o tipo de aplicativo que você está criando. O processo geral a seguir se aplica a todos os tipos de aplicativos:

  1. Para se preparar para o processo de autorização, faça o seguinte:
  2. Para acessar os dados do usuário, o aplicativo solicita ao Google um escopo de acesso específico.
  3. O Google exibe uma tela de consentimento ao usuário para que ele autorize a para solicitar alguns de seus dados.
  4. Se o usuário aprovar, o Google fornecerá ao aplicativo um token de acesso que expira após um breve período.
  5. O aplicativo faz uma solicitação pelos dados do usuário, anexando o token de acesso à solicitação.
  6. Se o Google determinar que a solicitação e o token são válidos, ele retornará o os dados solicitados.

Para determinar quais escopos são adequados para seu aplicativo, consulte Autorização escopos.

O processo para alguns tipos de aplicativo inclui etapas adicionais, como usar para adquirir novos tokens de acesso. Para informações detalhadas sobre para vários tipos de aplicativos, consulte Uso do OAuth 2.0 para acessar recursos APIs do Google.

Armazenamento em cache

Mantenha os dados atualizados.

Se você precisar armazenar mídia temporariamente (como miniaturas, fotos ou vídeos) Por motivos de desempenho, não armazene em cache por mais de 60 minutos de acordo diretrizes.

Também não armazene baseUrls, que expira após aproximadamente 60 minutos.

IDs de itens de mídia e de álbuns que identificam de forma exclusiva o conteúdo na biblioteca de um usuário estão isentos da restrição de armazenamento em cache. Esses IDs podem ser armazenados indefinidamente. (sujeito à política de privacidade do seu aplicativo). Usar IDs de itens de mídia e de álbuns para recuperar URLs e dados acessíveis novamente usando os endpoints apropriados. Para Para mais informações, consulte Receber um link de item ou listagem álbuns.

Se você tiver muitos itens de mídia para atualizar, pode ser mais eficiente armazenar o parâmetros de pesquisa que retornaram os itens de mídia e reenvie a consulta para atualizar dados.

Acesso SSL

O HTTPS é necessário para todas as solicitações de serviço da Web da API Library usando o seguinte URL:

https://photoslibrary.googleapis.com/v1/service/output?parameters

As solicitações feitas por HTTP são rejeitadas.

Tratamento de erros

Para saber como lidar com erros retornados pela API, consulte o Cloud Processamento de APIs erros.

Novas tentativas de solicitações com falha

Os clientes precisam tentar novamente em caso de erros 5xx com espera exponencial, conforme descrito em Espera exponencial. O atraso mínimo precisa ser 1 s salvo documentação contrária.

Para erros 429, o cliente pode tentar novamente com um atraso mínimo de 30s. Para todos os outros erros, a nova tentativa pode não ser aplicável. Verifique se a solicitação é idempotente e confira a mensagem de erro para orientação.

Espera exponencial

Em casos raros, algo pode dar errado ao atender à sua solicitação. Código de resposta HTTP 4XX ou 5XX, ou a conexão TCP pode falhar em algum lugar entre o cliente e o servidor do Google. Muitas vezes, vale a pena tentar o solicitação. A solicitação de acompanhamento poderá ser bem-sucedida quando a original falhar. No entanto, é importante não ficar em loop, fazendo solicitações repetidas aos servidores do Google. Isso o comportamento de looping pode sobrecarregar a rede entre seu cliente e o Google e causar problemas para muitas partes.

Uma melhor abordagem é tentar novamente com intervalos maiores entre as tentativas. Normalmente, o atraso é aumentado por um fator multiplicativo a cada tentativa, uma abordagem conhecido como Exponencial espera.

Você também deve tomar cuidado para que não haja códigos de nova tentativa em níveis superiores no aplicativo. de chamada que leva a solicitações repetidas em rápida sucessão.

Uso adequado das APIs do Google

Clientes de API mal projetados podem colocar mais carga do que o necessário nos Internet e nos servidores do Google. Esta seção contém algumas práticas recomendadas para clientes das APIs. Seguir essas práticas recomendadas pode ajudar você a evitar aplicativo sendo bloqueado por abuso inadvertido das APIs.

Solicitações sincronizadas

Um grande número de solicitações sincronizadas para as APIs do Google pode parecer um um ataque distribuído de negação de serviço (DDoS) na infraestrutura do Google e tratados adequadamente. Para evitar isso, verifique se as solicitações de API estão não sincronizados entre os clientes.

Por exemplo, considere um aplicativo que exibe a hora no horário atual zona. Este aplicativo provavelmente definirá um alarme no sistema operacional do cliente ativá-la no início do minuto para que a hora exibida possa ser atualizado. O aplicativo não deve fazer chamadas de API como parte do processamento. associada ao alarme.

Fazer chamadas de API em resposta a um alarme fixo é ruim porque resulta no Chamadas de API sincronizadas no início do minuto, mesmo entre diferentes dispositivos em vez de serem distribuídos uniformemente com o tempo. Uma abordagem mal projetada aplicativo que faça isso produz um pico de tráfego sessenta vezes os níveis normais no início de cada minuto.

Em vez disso, um bom design possível é ter um segundo alarme definido para um horário escolhido. Quando esse segundo alarme é acionado, o aplicativo faz chamadas para qualquer APIs necessárias e armazena os resultados. Para atualizar a exibição no início do minuto, o aplicativo usa resultados armazenados anteriormente em vez de chamar o API novamente. Com esta abordagem, chamas de API são espalhadas igualmente com o decorrer do tempo. Além disso, as chamadas de API não atrasam a renderização quando a tela está sendo atualizada.

Além do início do minuto, outros momentos de sincronização comuns que você deve ter cuidado para não segmentar estão no início de uma hora e no início todos os dias à meia-noite.