Kişileri CardDAV protokolüyle yönetme

Kişilerinizi, Google'ın CardDAV protokolünü kullanarak görüntüleyebilir ve yönetebilirsiniz.

Kişiler, kullanıcının Google Hesabında depolanır. Çoğu Google hizmeti, kişi listesine erişebilir. İstemci uygulamanız yeni kişiler oluşturmak, mevcut kişileri düzenlemek veya silmek ve belirli kriterlerle eşleşen kişileri sorgulamak için CardDAV API'sini kullanabilir.

Özellikler

Tam spesifikasyon uygulanmasa da Apple iOSTM Kişiler ve macOS gibi birçok istemci doğru şekilde birlikte çalışabilir.

İlgili her spesifikasyon için Google'ın CardDAV desteği aşağıdaki gibidir:

Google CardDAV için OAuth 2.0 gerekir

Google'ın CardDAV arayüzü için OAuth 2.0 gerekir. Google API'lerine erişmek için OAuth 2.0'ı kullanma hakkında bilgi edinmek için aşağıdaki bağlantıları verilen belgelere bakın:

Google'ın CardDAV sunucusuna bağlanma

CardDAV protokolü, adres defteri ve kişi kaynakları URI'larının bulunmasını sağlar. İstediğiniz zaman değişebilecekleri için hiçbir URI'ye kod gömmemelisiniz.

İstemci uygulamaları HTTPS kullanmalıdır ve kullanıcının Google hesabı için OAuth 2.0 kimlik doğrulaması sağlanmalıdır. CardDAV sunucusu, Google hesabının OAuth 2.0 kimlik doğrulamasıyla HTTPS üzerinden ulaşmadığı ve uygulamanız DevConsole'da kayıtlı olduğu sürece isteklerin kimliğini doğrulamaz. Temel kimlik doğrulamayla veya bir Google hesabıyla eşleşmeyen bir e-posta/şifre ile HTTP üzerinden bağlanma girişimleri, HTTP 401 Unauthorized yanıt koduyla sonuçlanır.

CardDAV'ı kullanmak için istemci programınızın başlangıçta aşağıdaki cihazlarda bir HTTP PROPFIND işlemi gerçekleştirerek standart keşif yoluna bağlanması gerekir:

https://www.googleapis.com/.well-known/carddav

Bir Adres Defteri Kaynağı'na yönlendirildikten (HTTP 301) sonra istemci programınız, DAV:current-user-principal, DAV:principal-URL ve addressbook-home-set özelliklerini keşfetmek için bu kaynakta bir PROPFIND işlemi gerçekleştirebilir. Daha sonra müşteri programınız, addressbook-home-set üzerinde bir PROPFIND işlemi yapıp addressbook ile collection kaynaklarını arayarak ana adres defterini keşfedebilir. Bu sürecin tam açıklaması bu belgenin kapsamı dışındadır. Daha fazla ayrıntı için rfc6352'ye bakın.

İyi bilinen URI'daki bir PROPFIND aracılığıyla HTTP 301 yanıtında döndürülen yönlendirme yolu, rfc6764'e göre kalıcı olarak önbelleğe alınmamalıdır. Cihazlar, önbelleğe alınan yolun hâlâ güncel olup olmadığını doğrulamak ve yol değişirse yeniden senkronize etmek için iyi bilinen URI keşfini düzenli olarak yeniden denemelidir. Google, 2-4 haftada bir fiyat önerisinde bulunur.

Kaynaklar

CardDAV, REST kavramlarını kullanır. İstemci uygulamaları, URI'ları tarafından belirlenen kaynaklar üzerinde işlem yapar. Mevcut URI yapısı, geliştiricilerin bir sonraki bölümde yer alan kavramları anlamalarına yardımcı olmak için burada belirtilmiştir. Yapı değişebilir ve koda gömülmemelidir. Bunun yerine, kaynaklar RFC'ye göre keşfedilmelidir.

  1. Müdür
    • https://www.googleapis.com/carddav/v1/principals/userEmail
  2. Ev Seti
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists
  3. Adres Defteri
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default
  4. İletişim
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default/contactId

Kişileri Senkronize Etme

Aşağıda, desteklenen işlemlerin genel bir açıklaması yer almaktadır. Geliştiriciler, ilgili RFC'deki ayrıntıları aramalıdır. İstekler ve yanıtlar çoğunlukla XML olarak kodlanır. Senkronizasyon için istemci uygulamaları tarafından kullanılan ana işlemler şunlardır:

  • CTag'i kullanma
    • İstemci programları, sunucuda herhangi bir kişinin değişip değişmediğini ve dolayısıyla bir senkronizasyon gerekip gerekmediğini belirlemek için Adres Defteri kaynağındaki getctag PROPFIND isteğini kullanır. İletişim bilgileri değişirse bu özelliğin değeri mutlaka değişir. İstemci uygulamaları bu değeri depolamalı ve yalnızca ilk senkronizasyonda ve bir sync-token geçersiz kılındığında yedek olarak kullanmalıdır. getctag özelliği için düzenli olarak yoklama yapmak kısıtlamaya neden olur.
  • Senkronizasyon jetonunu kullanma
    • İstemci programları, mevcut durumunu temsil eden sync-token öğesini almak için Adres Defteri'ndeki sync-token PROPFIND isteğini kullanır. İstemci uygulamaları bu değeri depolamalı ve son gönderilen sync-token tarihinden bu yana yapılan değişiklikleri belirlemek için düzenli aralıklarla sync-collection REPORT istekleri göndermelidir. Verilen jetonlar 29 gün boyunca geçerlidir ve REPORT yanıtı yeni bir sync-token içerir.
  • ETag'leri kullanma
    • İstemci uygulamaları, Adres Defteri kaynağında getetag PROPFIND isteği yayınlar (üst bilgisi DEPTH_1 ile aynı olur). İstemci programı, her kişinin ETag değerini koruyarak ETag kişileri değiştirilen kişilerin değerini isteyebilir.DEPTH
  • Kişileri alma
    • İstemci uygulamaları, kişileri addressbook-multiget REPORT isteği göndererek alır. Kişi URI'lerinin bir listesi verildiğinde, rapor istenen tüm kişileri VCard 3.0 değerleri olarak döndürür. Her giriş, kişi için bir ETag içerir.
  • Kişi ekleme
    • İstemci uygulamaları, yeni kişiyle VCard 3.0 biçiminde bir POST isteği gönderir. Yanıtta, yeni kişinin kimliği yer alır.
  • Kişiyi güncelleme
    • İstemci uygulamaları, güncellenmiş kişi ile VCard 3.0 biçiminde bir PUT isteği gönderir. Kişi, adres defterinde zaten varsa güncellenir.
    • İstemci uygulamaları, kişinin bilinen ETag kodunu içeren bir If-Match üstbilgisi içermelidir. Sunucudaki mevcut ETag, istemci programı tarafından gönderilen ETag değerinden farklıysa sunucu PUT isteğini (HTTP 412 ile) reddeder. Bu, güncellemelerin iyimser şekilde serileştirilmesine olanak tanır.
  • Kişi silme
    • İstemci uygulamaları, bir kişiyi kişi URI'sına karşı bir DELETE isteği göndererek siler.