API istekleriniz genelinde kimlik bilgilerini 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 verimli bir şekilde etkileşim kurabilmesi için OAuth2 kimlik bilgisi yönetimini nasıl optimize edeceğiniz açıklanmaktadır.
Kimlik bilgisi paylaşım stratejiniz, uygulamanızın çok iş parçacıklı mı yoksa çok işlemli (ya da dağıtılmış) olmasına göre değişir. Her işlemde hem çok işlemli hem de çok iş parçacıklı bir uygulama her iki stratejiyi de kullanmalıdır. Bu stratejiler, birden çok Google Ads hesabına da uyarlanabilir.
Çok iş parçacıklı
Bir iş parçacığı tarafından çizilen her oturum veya kullanıcı, aynı kimlik bilgisi nesnesini kullanmalıdır. Erişim jetonu yenilemeleri, yarış koşullarını önlemek için eşzamanlı olarak yapılmalıdır.
İstemci kitaplıklarımız, kimlik bilgisinin, erişim jetonunun süresi dolduğunda eşzamanlı olarak kendini yenileyen, iş parçacığı açısından güvenli bir nesne olmasını sağlar. İstemci kitaplıklarımızın her biri, kullanım ömrü boyunca yeniden kullandığı kimlik bilgilerine sahip bir oturum (veya kullanıcı) nesnesine sahiptir. Kimlik bilgisini ileti dizileri arasında paylaşmak için her oturumu aynı kimlik bilgisini kullanarak oluşturmanız yeterlidir. Örneğin, Java istemci kitaplığında bir Credential single'ı oluşturur ve bunu tüm oturumlarda paylaşırsınız.
Çoklu işlenmiş veya dağıtılmış
Çok işlemli veya dağıtılmış işlemlerde, kimlik bilgisini paylaşmadan önce kullanmaya devam etmeniz gerekir. Birden fazla işlemin veya sunucunun kimlik bilgilerini aynı anda yenilemeye çalışmamasını ve bu nedenle aşırı yenileme isteklerine yol açmamasını sağlamak için yenilemeyi tek bir işleme atamanız gerekir.
Örneğin, kimlik bilgilerini düzenli olarak yenilemek ve sunucu havuzu tarafından paylaşılan veri deposuna proaktif olarak aktarmak ayrı bir iş veya hizmetten sorumlu olabilir. Daha sonra her sunucu, API isteğinde bulunurken veri deposundan kimlik bilgisini alabilir.
İşi yenile
Yenileme işi, yenileme başlatmadan önce mevcut kimlik bilgilerinin süresinin dolmasını beklememelidir. Bu durum, geçerli bir kimlik bilgisinin olmaması nedeniyle uygulamanın duraklatılmasına neden olabilir. Ancak API isteği işlenirken bir kimlik bilgisinin erişim jetonunun süresi dolarsa istek yine de tamamlanır ve sonuçlar döndürülür.
Erişim jetonunuzun en son yenilenme zamanını takip etmenizi ve geçerlilik süresinin bitmesine 5 dakikadan az bir süre kalmışsa yenileme yapmaya zorlamanızı öneririz.
Erişim jetonunun en son ne zaman yenilendiğini bilmiyorsanız süresinin dolduğunu varsayarak yenilemeyi deneyebilirsiniz. Erişim jetonu sona erme yakın değilse sunucu, aynı erişim jetonunu, jetonun süresi dolana kadar kalan milisaniye sayısı ile birlikte döndürür.
Veri deposu
Mevcut bir veri deposundan yararlanabilir veya kimlik bilgilerinin sunucular arasında paylaşımına özel bir veri deposu dağıtabilirsiniz. Çözümler arasında, Memcached veya Infinispan gibi önbelleğe alma sunucuları ya da MongoDB gibi NoSQL veri depoları yer alır.
Veri deposu, yazma işleminden çok daha fazla okuma isteği olacağı için hızlı okuma işlemleri için optimize edilmelidir. Kimlik bilgilerinin güvenli bir şekilde depolanması gerekir.
Kimlik bilgisini depolarken hesaplanan expiry_time
(şimdi + expires_in) ve refresh_token değerlerini access_token ile birlikte depolamanız gerekir. expiry_time, access_token yenileme isteğinin süresi ile expires_in süresi toplanarak hesaplanır.
Sunucu havuzu
Havuzdaki her sunucu veya işlem, istekte bulunmadan önce veri deposundan en son kimlik bilgilerini alır. Yenileme işi düzgün şekilde çalıştığı sürece kimlik bilgisi geçerli olur. Ancak yenileme işi veya veri deposu başarısız olursa yedek mekanizmanız olmalıdır.
Bir sunucu veya işlem, veri deposundan kimlik bilgisi alamazsa ya da kimlik bilgilerinin süresi dolmuşsa sunucu, uygulamanın sorun çözülene kadar API ile çalışmaya devam etmesini sağlamak için kendi kimlik bilgilerini yenilemelidir.
Birden fazla hesap için kimlik bilgisi yönetimi
Google Ads yönetici hesabı için oluşturulan kimlik bilgisi, tüm alt hesaplara erişmek amacıyla kullanılabilir. Bu nedenle, tek bir yönetici hesabı hiyerarşisi olan kullanıcılar için üst düzey yönetici hesabı için kimlik bilgisi oluşturmak genellikle yeterlidir. Kimlik bilgisi, altındaki tüm Google Ads hesapları için kullanılabilir.
Uygulamanızın, herhangi bir yönetici hesabı hiyerarşisinde birbiriyle alakalı olmayan Google Ads hesaplarına erişmesi gerekiyorsa farklı hesaplar (ör. eriştiğiniz her Google Ads müşteri hesabı veya eriştiğiniz her bağımsız hiyerarşideki her üst düzey yönetici hesabı için) için farklı kimlik bilgileri oluşturmalı ve saklamalısınız.
Küçük değişiklikler yaparak çok iş parçacıklı veya çok işlemli / dağıtılmış uygulamalar için aynı stratejileri uygulayabilirsiniz. Paylaşılan bir veri deposu kullanılırken kimlik bilgilerinin doğru hesapla ilişkilendirildiğinden emin olmak için kimlik bilgilerinin customerId hesap tanımlayıcısı tarafından dizine eklenmesi gerekir.
Ayrıca, yenileme işi, tüm kimlik bilgilerinin yenilenmesini 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 ileti dizileri genelinde paylaşmanız gerekir.