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 saklanır; çoğu Google hizmetinde kişi listesine erişebilir. İstemci uygulamanız CardDAV API'yi kullanarak yeni kişi oluşturma, mevcut kişileri düzenleme veya silme ve kişileri sorgulama reklam grubu da oluşturabilirsiniz.

Özellikler

Tam spesifikasyon uygulanmadı, ancak Apple iOSTM Kişiler ve macOS'in doğru şekilde birlikte çalışması gerekir.

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

Google'ın CardDAV'ı için OAuth 2.0 gerekir

Google'ın CardDAV arayüzü için OAuth 2.0 gereklidir. Bağlantılı şu dokümanları inceleyin:

Google'ın CardDAV sunucusuna bağlanma

CardDAV protokolü, adres defteri ve kişi kaynaklarının URI'lerinin keşfedilmesine olanak tanır. Her an değişebileceği için hiçbir URI'nın kodunu gömmemeniz gerekir.

İstemci uygulamaları HTTPS kullanmalı ve OAuth 2.0 kimlik doğrulaması, (kullanıcının Google hesabı için) CardDAV sunucusu bir istek OAuth 2.0 ile HTTPS üzerinden ulaşmadıkça kimliğini doğrulama bir Google Hesabı'nın kimlik doğrulamasından yararlanabiliyorsanız ve uygulamanız DevConsole. Temel kimlik doğrulaması veya bir Google hesabıyla eşleşmeyen bir e-posta/şifre, HTTP ile sonuçlanıyorsa 401 Unauthorized yanıt kodu.

CardDAV'ı kullanmak için istemci programınızın ilk olarak standart sayfaya bağlanması gerekir şurada bir HTTP PROPFIND gerçekleştirerek keşif yolu:

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

Bir Adres Defteri Kaynağına (HTTP 301) yönlendirildikten sonra istemci programınız daha sonra,PROPFIND DAV:current-user-principal, DAV:principal-URL ve addressbook-home-set özellikler. Böylece istemci programınız ana adres defterini addressbook-home-set cihazında PROPFIND gerçekleştiriyor ve addressbook ve collection kaynakları. Bu sürecin tam açıklaması bu dokümanın kapsamı dışındadır. Daha fazla bilgi için rfc6352 sayfasına bakın.

Şu tarihte bir PROPFIND aracılığıyla HTTP 301 yanıtında döndürülen yönlendirme yolu: iyi bilinen URI kalıcı olarak önbelleğe alınmamalıdır ( rfc6764). 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 bilinen URI keşfini düzenli aralıklarla yeniden denemelidir. Google, 2-4 haftada bir gönderim yapmanızı önerir.

Kaynaklar

CardDAV, REST kavramlarını kullanır. İstemci uygulamaları, URI'leri ile tanımlanan kaynaklar üzerinde işlem yapar. Yardımcı olması için geçerli URI yapısı burada belirtilmiştir geliştiriciler aşağıdaki bölümde yer alan kavramları anlamıştır. Yapı değişebilir ve sabit kodla yazılmamalıdır. Bunun yerine, kaynaklar RFC'ye göre bulunmalıdır.

  1. Müdür
    • https://www.googleapis.com/carddav/v1/principals/userEmail
  2. Ev Ayarlama
    • 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'de ayrıntıları bulabilir. İstekler ve yanıtlar XML'de kodlanır. Bunlar, istemci tarafından kullanılan ana işlemlerdir. senkronizasyon uygulamaları:

  • CTag'i kullanma
    • İstemci programları, Adres Defteri'nde getctag PROPFIND isteğini kullanır ve herhangi bir kişinin sunucuda değişip değişmediğini belirlemek için bir bu nedenle senkronizasyon gerekip gerekmediği. Herhangi bir kişi değişirse bu mülkün değerinin değişeceği garanti edilir. İstemci uygulamaları bu değeri depolamalı ve yalnızca ilk senkronizasyonda ve bir sync-token geçersiz olduğunda yedek olarak kullanmalıdır. getctag mülkü için düzenli olarak yoklama yapılması, mülkün sınırlandırılmasına neden olur.
  • sync-token parametresini kullanma
    • İstemci programları, mevcut durumunu temsil eden sync-token öğesini almak için Adres Defteri'ndeki sync-token PROPFIND isteğini kullanır. Müşteri uygulamalar bu değeri depolamalı ve düzenli olarak sync-collection vermelidir. Son gönderilen tarihten bu yana yapılan değişiklikleri belirlemek için REPORT istek gönderildi sync-token. Verilen jetonlar 29 gün boyunca geçerlidir ve REPORT yanıt yeni bir sync-token içerecek.
  • E-etiketleri kullanma
    • İstemci uygulamaları, Adres Defteri kaynağında (DEPTH başlığı DEPTH_1'a eşit olacak şekilde) bir getetag PROPFIND isteği gönderir. İstemci programı, her kişinin ETag değerini koruyarak ETag değeri değiştirilen kişilerin değerini isteyebilir.
  • Kişileri getirme
    • İstemci uygulamaları, kişileri bir addressbook-multiget REPORT isteği. Rapor, iletişim URI'lerinin bir listesini aldığında istenen tüm kişileri VCard 3.0 değerleri olarak döndürür. Her girişte kişi için bir ETag bulunur.
  • Kişi ekleme
    • İstemci uygulamaları, VCard'daki yeni kişiye bir POST isteği gönderir. 3.0 biçiminde indirilmelidir. Yanıtta yeni kişinin kimliği yer alır.
  • Kişileri güncelleme
    • İstemci uygulamaları, güncellenmiş kişiyi VCard 3.0 biçiminde içeren bir PUT isteği gönderir. Kişi zaten mevcutsa güncellenir yazın.
    • İstemci uygulamaları,If-Match kişinin şu anda bilinen ETag. Sunucudaki mevcut ETag, istemci programı tarafından gönderilen ETag'den farklıysa sunucu PUTisteğini (HTTP 412 ile) reddeder. Bu, güncellemelerin iyimser bir şekilde serileştirilmesine olanak tanır.
  • Kişiyi silme
    • Müşteri uygulamaları, kişi URI'sine karşı bir DELETE isteği göndererek kişiyi siler.