Mengelola kontak dengan protokol CardDAV

Anda dapat melihat dan mengelola kontak menggunakan protokol CardDAV Google.

Kontak disimpan di Akun Google pengguna; sebagian besar layanan Google memiliki akses ke daftar kontak. Aplikasi klien Anda dapat menggunakan CardDAV API untuk membuat kontak baru, mengedit atau menghapus kontak yang ada, dan membuat kueri kontak yang cocok dengan kriteria tertentu.

Spesifikasi

Spesifikasi lengkap tidak diterapkan, tetapi banyak klien seperti Kontak Apple iOSTM dan macOS harus dapat beroperasi dengan benar.

Untuk setiap spesifikasi yang relevan, dukungan CardDAV Google adalah sebagai berikut:

CardDAV Google memerlukan OAuth 2.0

Antarmuka CardDAV Google memerlukan OAuth 2.0. Lihat tautan dokumentasi di bawah ini untuk informasi tentang penggunaan OAuth 2.0 untuk mengakses Google API:

Menghubungkan ke server CardDAV Google

Protokol CardDAV memungkinkan penemuan buku alamat dan referensi kontak URI. Anda tidak boleh melakukan hardcode pada URI mana pun karena URI dapat berubah kapan saja.

Aplikasi klien harus menggunakan HTTPS, dan autentikasi OAuth 2.0 harus yang disediakan untuk Akun Google pengguna. Server CardDAV tidak akan melakukan otentikasi permintaan kecuali diterima melalui HTTPS dengan OAuth 2.0 autentikasi akun Google, dan aplikasi Anda terdaftar di DevConsole. Segala upaya untuk terhubung melalui HTTP dengan otentikasi Dasar atau dengan email/kata sandi yang tidak cocok dengan akun Google menghasilkan permintaan HTTP Kode respons 401 Unauthorized.

Untuk menggunakan CardDAV, program klien Anda harus terlebih dahulu terhubung ke versi kanonis jalur penemuan dengan menjalankan PROPFIND HTTP pada:

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

Setelah dialihkan (HTTP 301) ke Resource Buku Alamat, program klien Anda kemudian dapat melakukan PROPFIND untuk menemukan DAV:current-user-principal, DAV:principal-URL, dan addressbook-home-set properti baru. Program klien Anda kemudian dapat menemukan buku alamat utama dengan melakukan PROPFIND pada addressbook-home-set dan mencari addressbook, dan collection. Deskripsi lengkap proses ini di luar cakupan dokumen ini. Lihat rfc6352 untuk detail selengkapnya.

Jalur pengalihan yang ditampilkan dalam respons HTTP 301 melalui PROPFIND di URI yang dikenal tidak boleh di-cache secara permanen (sesuai dengan rfc6764). Perangkat harus mencoba lagi Penemuan URI secara berkala untuk memverifikasi apakah jalur yang di-cache masih terbaru dan menyinkronkan ulang jika jalur pernah berubah. Google merekomendasikan rasio setiap 2-4 minggu.

Resource

CardDAV menggunakan konsep REST. Aplikasi klien bertindak pada sumber daya yang yang ditentukan oleh URI-nya. Struktur URI saat ini ditentukan di sini untuk membantu developer memahami konsep di bagian berikut ini. Strukturnya mungkin diubah dan tidak boleh di-hardcode. Sebaliknya, sumber daya harus ditemukan sesuai dengan RFC.

  1. Kepala sekolah
    • https://www.googleapis.com/carddav/v1/principals/userEmail
  2. Set Rumah
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists
  3. Buku Alamat
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default
  4. Kontak
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default/contactId

Menyinkronkan Kontak

Berikut adalah deskripsi umum dari operasi yang didukung. Developer harus mencari detail dalam RFC yang relevan. Permintaan dan respons sebagian besar dikodekan dalam XML. Ini adalah operasi utama yang digunakan oleh klien aplikasi untuk sinkronisasi:

  • Menggunakan CTag
    • Program klien menggunakan permintaan getctag PROPFIND di Buku Alamat sumber daya untuk menentukan apakah ada kontak yang berubah di server dan sehingga perlu mengetahui apakah sinkronisasi diperlukan. Nilai properti ini dijamin berubah jika ada perubahan kontak. Aplikasi klien harus menyimpan nilai ini dan menggunakannya hanya pada sinkronisasi awal dan sebagai jika sync-token tidak valid. Lakukan polling secara berkala untuk Properti getctag akan menyebabkan throttling.
  • Menggunakan token sinkronisasi
    • Program klien menggunakan permintaan sync-token PROPFIND di Alamat Buku untuk mendapatkan sync-token yang mewakili statusnya saat ini. Klien aplikasi harus menyimpan nilai ini dan menerbitkan sync-collection berkala REPORT permintaan untuk menentukan perubahan sejak terakhir diterbitkan sync-token. Token yang diterbitkan berlaku selama 29 hari, dan REPORT akan berisi sync-token baru.
  • Menggunakan ETag
    • Aplikasi klien mengajukan permintaan PROPFIND getetag di Alamat Referensi buku (dengan header DEPTH sama dengan DEPTH_1). Dengan mempertahankan nilai ETag dari setiap kontak, program klien dapat meminta nilai tersebut kontak yang ETag-nya berubah.
  • Mengambil kontak
    • Aplikasi klien mengambil kontak dengan mengeluarkan addressbook-multiget permintaan REPORT. Dengan mempertimbangkan daftar URI kontak, laporan mengembalikan semua kontak yang diminta sebagai nilai VCard 3.0. Masing-masing entri menyertakan ETag untuk kontak.
  • Menyisipkan kontak
    • Aplikasi klien mengirimkan permintaan POST dengan kontak baru di VCard dalam format 3.0. Respons akan berisi ID kontak baru.
  • Memperbarui kontak
    • Aplikasi klien mengajukan permintaan PUT dengan kontak yang diperbarui di Format VCard 3.0. Kontak akan diperbarui jika kontak sudah ada di buku alamat.
    • Aplikasi klien harus menyertakan header If-Match dengan atribut kontak yang saat ini dikenal ETag. Server kemudian akan menolak PUT (dengan HTTP 412) jika ETag saat ini di server berbeda dari ETag yang dikirim oleh program klien. Hal ini memungkinkan serialisasi update optimistis.
  • Menghapus kontak
    • Aplikasi klien menghapus kontak dengan mengeluarkan permintaan DELETE terhadap URI kontak.