Kimlik bilgilerini API istekleriniz genelinde paylaşmak, performansı artırır ve hız sınırı hatalarına neden olabilecek aşırı ek yükü önler. Bu kılavuzda, uygulamanızın Google Ads API ile etkili bir şekilde etkileşim kurabilmesi için OAuth2 kimlik bilgisi yönetimini nasıl optimize edeceğiniz açıklanmaktadır.
Kimlik bilgisi paylaşma stratejiniz, uygulamanızın çok iş parçacıklı veya çok işlemli (ya da dağıtılmış) olmasına bağlıdır. Her işlem içinde hem çok işlemli hem de çok iş parçacıklı bir uygulama her iki stratejiyi de kullanmalıdır. Bu stratejiler birden fazla Google Ads hesabına da uyarlanabilir.
Çok iş parçacıklı
İş parçacığı tarafından çekilen her oturum veya kullanıcı, aynı kimlik bilgisi nesnesini kullanmalıdır. Yarış koşullarından kaçınmak için, erişim jetonu yenilemeleri de eşzamanlı olarak gerçekleştirilmelidir.
İstemci kitaplıklarımız, kimlik bilgisinin, erişim jetonunun süresi dolduğunda kendisini eşzamanlı olarak yenileyen iş parçacığı güvenli bir nesne olmasını sağlar. İstemci kitaplıklarımızın her birinin, kullanım ömrü boyunca yeniden kullandığı bir kimlik bilgisine sahip oturum (veya kullanıcı) nesnesi bulunur. Kimlik bilgisini iş parçacıkları arasında paylaşmak için her oturumu aynı kimlik bilgisini kullanarak oluşturmanız yeterlidir. Örneğin, Java istemci kitaplığında bir Credential teklisi oluşturup bunu tüm oturumlarda paylaşırsınız.
Çoklu işlem veya dağıtılmış
Çok işlemli veya dağıtılmış işlemlerde, kimlik bilgilerini paylaşabilmek için öncelikle bunların saklanması gerekir. Birden fazla işlemin veya sunucunun kimlik bilgilerini aynı anda yenilemeye çalışmadığından ve bu nedenle aşırı yenileme isteklerine yol açmadığından emin olmak için yenilemeyi tek bir işleme atamanız gerekir.
Örneğin, kimlik bilgilerinin düzenli olarak yenilenmesinden ve sunucu havuzu tarafından paylaşılan bir veri deposuna proaktif olarak aktarılmasından ayrı bir iş ya da hizmet sorumlu olabilir. Böylece her sunucu, bir API isteği yaparken kimlik bilgisini veri deposundan alabilir.
İşi yenile
Yenileme işi, yenileme başlatmadan önce mevcut kimlik bilgilerinin süresinin dolmasını beklememelidir. Bu, uygulamanın geçerli bir kimlik bilgisi eksikliği nedeniyle beklemesine neden olabilir. Bununla birlikte, API isteği işlenirken bir kimlik bilgisinin erişim jetonunun süresi dolarsa istek yine de tamamlanıp sonuçlar döndürülür.
Erişim jetonunuzun en son ne zaman yenilendiğini takip etmenizi ve geçerlilik süresinin bitmesine 5 dakikadan az zaman kalmışsa yenilemenin zorlanmasını öneririz.
Erişim jetonunun en son ne zaman yenilendiğini bilmiyorsanız süresinin dolduğunu varsayarak jetonu yenilemeyi deneyebilirsiniz. Erişim jetonu neredeyse tamamen kullanılmayacaksa sunucu aynı erişim jetonunu, jetonun süresi dolana kadar kalan milisaniye sayısıyla birlikte döndürür.
Veri deposu
Mevcut bir veri deposundan yararlanabilir veya sunucular arasında kimlik bilgilerinin paylaşımına özel bir veri deposunu dağıtabilirsiniz. Çözümler arasında Memcached veya Infinispan gibi önbelleğe alma sunucuları ya da MongoDB gibi NoSQL veri depoları bulunur.
Yazma isteklerinden çok daha fazla okuma isteği olacağı için veri deposu, hızlı okuma işlemleri için optimize edilmelidir. Ayrıca kimlik bilgilerinin güvenli bir şekilde depolanması gerekir.
Kimlik bilgisini depolarken, hesaplanan expiry_time (şu anda + expires_in) ve refresh_token değerlerini access_token ile birlikte saklamanız gerekir. expiry_time, access_token yenileme isteğinin zamanı ile expires_in süresinin toplamı olarak hesaplanır.
Sunucu havuzu
Havuzdaki her sunucu veya işlem, istekte bulunmadan önce veri deposundan en son kimlik bilgisini alır. Yenileme işi düzgün çalıştığı sürece kimlik bilgileri geçerli olur. Ancak yenileme işi veya veri deposu başarısız olursa bir yedek mekanizmanız olmalıdır.
Bir sunucu veya işlem, veri deposundan kimlik bilgisi alamazsa ya da kimlik bilgilerinin süresi dolmuşsa uygulama sorun çözülene kadar API ile çalışmaya devam edebilmek için sunucu kendi kimlik bilgilerini yenilemelidir.
Birden fazla hesap için kimlik bilgisi yönetimi
Google Ads yönetici hesabı için oluşturulan kimlik bilgileri, hesabın tüm alt hesaplarına erişmek amacıyla kullanılabilir. Bu nedenle, tek bir yönetici hesabı hiyerarşisine sahip kullanıcılar için genellikle, üst düzey yönetici hesabı için kimlik bilgilerinin, altındaki tüm Google Ads hesaplarında kullanılmak üzere oluşturulması yeterlidir.
Uygulamanızın herhangi bir yönetici hesabı hiyerarşisinde birbiriyle ilişkili olmayan Google Ads hesaplarına erişmesi gerekiyorsa farklı hesaplar (ör. eriştiğiniz her Google Ads müşteri hesabı veya eriştiğiniz bağımsız hiyerarşilerdeki her üst düzey yönetici hesabı) için farklı kimlik bilgileri oluşturmalı ve saklamalısınız.
Küçük değişiklikler içeren çok iş parçacıklı veya çok işlemli / dağıtılmış uygulamalar için aynı stratejileri uygulayabilirsiniz. Paylaşılan bir veri deposu kullanırken kimlik bilgilerinin doğru hesapla ilişkilendirildiğinden emin olmak için kimlik bilgilerinin customerId hesap kimliği tarafından dizine eklenmesi gerekir.
Ayrıca, yenileme işi tüm kimlik bilgilerinin yenilenmiş kalmasını sağlamalıdır. Yeni bir hesap bağlanırsa yenileme işinin tetiklenmesi gerekebilir.
Son olarak, çok iş parçacıklı uygulamalarda kimlik bilgisi nesnesini yalnızca kimlik bilgisi nesnesinin ilişkilendirildiği hesapta çalışan iş parçacıkları arasında paylaşmanız gerekir.