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

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

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

仕様

完全な仕様は実装されていませんが、 Apple iOSTM の連絡先 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 経由で到着しない限り認証する 認証され、アプリケーションは DevConsole基本認証または認証を使用した HTTP 経由での接続の試行 メールアドレスやパスワードが 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 構造は、 次のセクションで説明するコンセプトを理解していることを前提としています。この構造は、 ハードコードしないでください。むしろ、リソースを検出する必要がある 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. 連絡先 <ph type="x-smartling-placeholder">
      </ph>
    • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default/contactId

連絡先を同期する

サポートされているオペレーションの概要は次のとおりです。デベロッパー 関連する RFC で詳細をご確認くださいリクエストとレスポンスは XML でエンコードされていますこれらは、クライアントが使用する主なオペレーションです。 同期するためのアプリケーションを以下に示します。

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