O compartilhamento de credenciais nas solicitações de API melhora o desempenho e evita a sobrecarga excessiva que pode resultar em erros de limitação de taxa. Neste guia, explicamos como otimizar o gerenciamento de credenciais do OAuth2 para que seu app possa interagir de maneira eficiente com a API Google Ads.
Sua estratégia de compartilhamento de credenciais vai depender do app ser multithread ou multiprocesso (ou distribuído). Um app que usa vários processos e várias linhas de execução em cada processo precisa usar 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 desenhado 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 maneira síncrona para evitar disputas.
Nossas bibliotecas de cliente garantem que a credencial seja um objeto seguro para linhas de execução que
é atualizado de maneira síncrona quando o token de acesso expira. 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 conversas, basta
criar cada sessão usando a mesma credencial. Por exemplo, na biblioteca de cliente Java, você criaria um Singleton Credential e o compartilharia em todas as sessões.
Multiprocessos ou distribuídos
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 excesso de solicitações de atualização, 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 armazenamento de dados compartilhado por um pool de servidores. Assim, cada servidor poderá 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 resultar na paralisação do app 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 serão retornados.
Recomendamos monitorar a hora em que seu 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. Se o token de acesso não estiver perto de expirar, o servidor retornará o mesmo token de acesso e os milissegundos restantes até o token expirar.
Armazenamento 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 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ápida, já que 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 os valores de expiry_time
(agora + expires_in) e refresh_token calculados junto com o access_token. O
expiry_time é calculado como o horário da solicitação de atualização access_token
mais o tempo expires_in.
Grupo de servidores
Cada servidor ou processo no pool recupera a credencial mais recente do armazenamento de dados antes de fazer uma solicitação. Contanto que o job de atualização esteja sendo executado corretamente, a credencial será válida. No entanto, se o job de atualização ou o armazenamento de dados falhar, é 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 trabalhando 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 contas secundárias. Portanto, para usuários com uma única hierarquia de conta de administrador, normalmente é suficiente gerar uma credencial para a conta de administrador de nível superior, que será usada em todas as contas do Google Ads abaixo dela.
Se o seu aplicativo precisar acessar contas do Google Ads que não estão relacionadas em qualquer hierarquia de contas de administrador, gere e mantenha credenciais diferentes para contas diferentes, como para cada conta de cliente do Google Ads que você acessa ou cada conta de administrador de nível superior nas hierarquias independentes que você acessa.
É possível seguir as mesmas estratégias para apps com várias linhas de execução ou
vários processos / distribuídos com pequenas modificações. Ao usar um repositório de dados compartilhado, as credenciais precisam ser indexadas pelo identificador de conta customerId para garantir que elas sejam 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 conversas, você só precisa compartilhar o objeto de credencial em conversas que operam na conta a que o objeto de credencial está associado.