CardDAV プロトコルで連絡先を管理する

Google の CardDAV プロトコルを使用して、連絡先を表示、管理できます。

連絡先はユーザーの Google アカウントに保存されます。ほとんどの Google サービスは、 アクセスできるようになります。クライアント アプリケーションで CardDAV API を使用して、 新しい連絡先の作成、既存の連絡先の編集または削除、連絡先の検索 フィルタすることもできます

仕様

仕様全体は実装されていませんが、Apple iOS™ の連絡先や macOS など、多くのクライアントは正しく相互運用する必要があります。

関連する各仕様について、Google の CardDAV サポートは次のとおりです。

Google の CardDAV には OAuth 2.0 が必要です

Google の CardDAV インターフェースには OAuth 2.0 が必要です。OAuth 2.0 を使用して Google API にアクセスする方法については、以下のドキュメントをご覧ください。

Google の CardDAV サーバーに接続する

CardDAV プロトコルにより、アドレス帳や連絡先リソースを検出可能 URI などです。URI は随時変更される可能性があるため、ハードコードしないでください。

クライアント アプリケーションで HTTPS を使用し、OAuth 2.0 認証を ユーザー ID 情報です。CardDAV サーバーは リクエストが OAuth 2.0 で HTTPS 経由で到着しない限り認証する 認証され、アプリケーションは DevConsoleHTTP 経由で Basic 認証を使用するか、Google アカウントと一致しないメールアドレスまたはパスワードを使用して接続しようとすると、HTTP 401 Unauthorized レスポンス コードが返されます。

CardDAV を使用するには、まずクライアント プログラムを正規 URL に接続する必要があります 次に対して HTTP PROPFIND を実行して、検出パスを指定します。

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

アドレス帳リソースにリダイレクト（HTTP 301）されたら、クライアント プログラムは PROPFIND を実行して DAV:current-user-principal、DAV:principal-URL、addressbook-home-set プロパティを検出できます。クライアント プログラムは、addressbook-home-set で PROPFIND を実行し、addressbook リソースと collection リソースを検索することで、プリンシパル アドレス帳を検出できます。このプロセスの詳細については、このドキュメントでは説明しません。詳しくは、rfc6352 をご覧ください。

PROPFIND を介して HTTP 301 レスポンスで返されるリダイレクト パス （ rfc6764）。デバイスは既知の方法で再試行する必要があります URI 検出を定期的に行い、キャッシュされたパスが最新の状態であり、 再同期する必要があります。2～4 週間ごとの実施をおすすめします。

リソース

CardDAV は REST のコンセプトを使用します。クライアント アプリケーションは、URI で指定されたリソースに対して動作します。現在の URI 構造は、 次のセクションで説明するコンセプトを理解していることを前提としています。構造は変更される可能性があるため、ハードコードしないでください。代わりに、RFC に従ってリソースを検出する必要があります。

  1. プリンシパル <ph type="x-smartling-placeholder">
      </ph>
    • https://www.googleapis.com/carddav/v1/principals/userEmail
  2. ホームセット <ph type="x-smartling-placeholder">
      </ph>
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists
  3. アドレス帳 <ph type="x-smartling-placeholder">
      </ph>
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default
  4. お問い合わせ
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default/contactId

連絡先を同期する

サポートされているオペレーションの概要は次のとおりです。デベロッパーは、関連する RFC で詳細を確認する必要があります。リクエストとレスポンスはほとんど XML でエンコードされます。クライアント アプリケーションが同期に使用する主なオペレーションは次のとおりです。

  • CTag を使用する <ph type="x-smartling-placeholder">
      </ph>
    • クライアント プログラムは、アドレス帳リソースの getctag PROPFIND リクエストを使用して、サーバーで連絡先が変更されたかどうか、つまり同期が必要かどうかを判断します。このプロパティの値は、連絡先が変更されると必ず変更されます。クライアント アプリケーション この値を保存し、最初の同期でのみ使用し、 sync-token が無効になった場合のフォールバックgetctag プロパティを定期的にポーリングすると、スロットリングが発生します。
  • sync-token の使用 <ph type="x-smartling-placeholder">
      </ph>
    • クライアント プログラムは、アドレス帳に対する sync-token PROPFIND リクエストを使用して、現在の状態を表す sync-token を取得します。クライアント アプリケーションはこの値を保存し、定期的に sync-collection を発行する必要があります。 REPORT リクエストで、前回の発行からの変更を確認 sync-token。発行されたトークンは 29 日間有効で、REPORT レスポンスには新しい sync-token が含まれます。
  • ETag の使用
    • クライアント アプリケーションが Address で getetag PROPFIND リクエストを発行する 予約リソース（DEPTH ヘッダーが DEPTH_1 と等しい）。インフラストラクチャを 各連絡先の ETag 値。クライアント プログラムは値をリクエストできます。 ETag が変更された連絡先の割合。
  • 連絡先の取得
    • クライアント アプリケーションは、 addressbook-multiget REPORT リクエスト。連絡先 URI のリストが指定されている場合、レポートはリクエストされたすべての連絡先を VCard 3.0 値として返します。各エントリには、連絡先の ETag が含まれています。
  • 連絡先を挿入する <ph type="x-smartling-placeholder">
      </ph>
    • クライアント アプリケーションは、VCard 3.0 形式の新しい連絡先を含む POST リクエストを発行します。レスポンスには、新しい連絡先の ID が含まれます。
  • 連絡先の更新
    • クライアント アプリケーションは、更新された連絡先を VCard 3.0 形式で含めて PUT リクエストを発行します。連絡先がアドレス帳にすでに存在する場合、連絡先が更新されます。
    • クライアント アプリケーションには、連絡先の現在知られている ETag を含む If-Match ヘッダーを含める必要があります。その後、サーバーは PUT を拒否します。 サーバーの現在の ETag が次の場合に HTTP 412 をリクエストし、 クライアント プログラムから送信された ETag とは異なります。これにより、更新のオプティミスティック シリアル化が可能になります。
  • 連絡先の削除
    • クライアント アプリケーションが DELETE リクエストを発行して連絡先を削除する 照合されます。