現在、古いスクリーンスクレイパーgemを使用して、gmail / yahoo/etcから連絡先をインポートしています。これを更新して、新しいOAuthベースのAPIを使用し、ユーザーがサイトで資格情報を入力する必要がないようにします。PlaxoがGoogleもサポートしているPortableContactsで行っている作業に本当に興味があります。それは読み取り専用アクセスの良い方向であるように感じます、そしてそれはまだOAuthによって支えられています。
ポータブル連絡先ルートを使用する代わりに、これらのプロバイダーの標準OAuth APIを使用するやむを得ない理由はありますか？それを避ける強い理由があるかどうか知りたいのですが。PCをサポートしていないものには引き続きストレートOAuthを使用するので、開発時間の問題ではなく、新しいアプローチに対するサポートと信頼の問題です。
各 OAuth 実装はわずかに異なりますが、Portable Contacts の各実装は同じです。これは、REST API (OAuth) と SOAP API (Portable Contacts -- ただし、OAuth と同じオーバーヘッドがあります) のようなものです。
したがって、理論的には、Portable Contacts Reader を 1 つ作成し、それをサポートする任意のプロバイダーに追加作業なしで接続できるはずです。
実際のところ、おそらくポータブル連絡先と OAuth 非ポータブル エンドポイントの両方を使用する必要があります。(ほとんどの OAuth 非ポータブル プロバイダーは、ポータブル コンタクトに移行することを願っています)。
OAuth コアは、ディスカバリー (ユーザーを OAuth URL に導き、ユーザーがリソースをコンシューマーに承認できるようにする) も、表現 (トークンが提供する承認についてコンシューマーに通知する) も定義しません。Portable Contacts などの仕様がない場合、これらは消費者とプロバイダーによってその場しのぎで合意される必要があります (検出はおそらく既知の URL に単純化されます)。したがって、Portable Contacts は、それらを使用するプロバイダーごとに 1 回、これらの質問に答えているだけです。サポートしていないプロバイダーをサポートしたい場合は、アドホックな回答を解決する必要がありますが、とにかくそれらすべてに同じ OAuth Core 実装を使用することになります。
Portable Contacts 自体は、OAuth Discovery 仕様に基づいて構築されていますが、残念ながら、これは代替品なしで期限切れになっているようです。