O compartilhamento de credenciais entre suas solicitações de API melhora o desempenho e evita sobrecarga que pode resultar em erros de limitação de taxa. Este guia explica como otimizar o gerenciamento de credenciais do OAuth2 para que seu app possa interagir de forma eficiente com a API Google Ads.
Sua estratégia de compartilhamento de credenciais vai depender do seu app usar várias linhas de execução ou multiprocessos (ou distribuído). Um app com vários processos e com várias linhas de execução dentro de cada processo precisa empregar as duas estratégias. Essas estratégias também podem ser adaptadas para várias contas do Google Ads.
Com várias linhas de execução
Cada sessão ou usuário acessado por uma linha de execução precisa usar o mesmo objeto de credencial. As atualizações do token de acesso também precisam ser realizadas de forma síncrona para evitar disputas.
Nossas bibliotecas de cliente garantem que a credencial seja um objeto seguro para thread que seja atualizado de maneira síncrona quando o token de acesso expirar. Cada uma das nossas bibliotecas de cliente tem um objeto de sessão (ou usuário) com uma credencial que ele reutiliza durante todo o ciclo de vida. Para compartilhar a credencial em várias linhas de execução, basta criar cada sessão usando a mesma credencial. Por exemplo, na biblioteca de cliente
Java, crie um Singleton Credential e o compartilhe em
todas as sessões.
Multiprocesso ou distribuído
Para processos distribuídos ou em vários processos, é necessário manter a credencial antes de compartilhá-la. Para garantir que vários processos ou servidores não tentem atualizar a credencial ao mesmo tempo, resultando em solicitações de atualização excessivas, atribua a atualização a um único processo.
Por exemplo, um job ou serviço separado pode ser responsável por atualizar periodicamente a credencial e enviá-la de maneira proativa para um repositório de dados compartilhado por um pool de servidores. Assim, cada servidor pode recuperar a credencial do armazenamento de dados ao fazer uma solicitação de API.
Tarefa de atualização
O job de atualização não pode esperar até que a credencial atual expire para iniciar uma atualização. Isso pode fazer com que o app seja interrompido por falta de uma credencial válida. No entanto, se o token de acesso de uma credencial expirar enquanto a solicitação de API estiver sendo processada, a solicitação ainda será concluída e os resultados retornarão.
Recomendamos acompanhar a hora em que o token de acesso foi atualizado pela última vez e forçar uma atualização se houver menos de cinco minutos até a expiração.
Se você não souber quando um token de acesso foi atualizado pela última vez, tente atualizá-lo supondo que ele já tenha expirado. Quando isso não acontece, o servidor retorna o mesmo token com os milissegundos restantes até o token expirar.
Repositório de dados
Você pode usar um armazenamento de dados existente ou implantar um específico para o compartilhamento de credenciais entres servidores. As soluções incluem servidores de armazenamento em cache, como o Memcached ou o Infinispan, ou armazenamentos de dados NoSQL, como o MongoDB.
O armazenamento de dados precisa ser otimizado para operações de leitura rápidas, porque haverá muito mais solicitações de leitura do que gravações. Além disso, as credenciais precisam ser armazenadas com segurança.
Ao armazenar a credencial, armazene o expiry_time calculado
(agora + expires_in) e o refresh_token junto com o access_token. O
expiry_time é calculado como o tempo da solicitação de atualização access_token
mais o tempo de expires_in.
Grupo de servidores
Cada servidor ou processo no pool recupera a credencial mais recente do repositório de dados antes de fazer uma solicitação. Desde que o job de atualização esteja sendo executado corretamente, a credencial será válida. No entanto, se a tarefa de atualização ou o repositório de dados falhar, será necessário ter um mecanismo substituto.
Se um servidor ou processo não puder receber uma credencial do repositório de dados ou se a credencial expirar, o servidor precisará atualizar as próprias credenciais para permitir que o app continue funcionando com a API até que o problema seja resolvido.
Gerenciamento de credenciais para várias contas
Uma credencial gerada para uma conta de administrador do Google Ads pode ser usada para acessar todas as suas contas filhas. Assim, para usuários com uma única hierarquia de contas de administrador, geralmente é suficiente gerar uma credencial para a conta de administrador de nível superior e usá-la em todas as contas do Google Ads abaixo dela.
Caso seu app precise acessar contas do Google Ads que não estão relacionadas entre si em nenhuma hierarquia de contas de administrador, gere e mantenha credenciais diferentes para cada conta, por exemplo, para cada conta de cliente do Google Ads acessada ou para cada conta de administrador de nível superior nas hierarquias independentes que você acessa.
Você pode seguir as mesmas estratégias para apps com várias linhas de execução ou
de vários processos / distribuídos com pequenas modificações. Ao usar um armazenamento de dados compartilhado, as credenciais precisam ser indexadas pelo identificador de conta customerId para garantir que as credenciais estejam associadas à conta correta.
Além disso, a tarefa de atualização deve manter todas as credenciais atualizadas. Se uma nova conta for vinculada, talvez seja necessário acionar a tarefa de atualização.
Por fim, em aplicativos com várias linhas de execução, compartilhe o objeto de credencial apenas entre conversas que operam na conta a que o objeto de credencial está associado.