記載されているdocumentationの和訳と、調べていて分かったノウハウを紹介します。we.ドキュメント全体の目次はこちらFacebook関連情報はFacebookページで共有しています。2:認証ダイアログの構成」では、それら2つの認証ダイアログ上での扱いの違いを紹介しました。その過程で、ユーザがアプリをインストールしたからと言って、全部のパーミッションを許可しているとは限らないことや、あとからFacebook上の設定ページでパーミッションが消されうることを話しました。ここでは、それに対応する実装方法を紹介します。与えられたパーミッションを確認する例えば機能の1つとして、ユーザの好きな本一覧を取得し、そこからおススメの本をレコメンドするような機能を提供していたとします。user_likesパーミッションが許可されなかったり消されたりしたら必要なデータを読み込めなくなってしまいますから、算出方法を切り替えるとか、場合によっては該当ユーザへのレコメンド機能自体を非表示にする必要が出てくるかもしれません。それには、ユーザがどのパーミッションを許可してくれているのか、少なくともユーザがサービスを利用する旅に知る必要があります。APIのユーザオブジェクトのpermissionsコネクションを参照します。以下の2種類のいずれかを用います。"https://graph.facebook.com/{USER_ID}/permissions?access_token=APP_ACCESS_TOKEN"返される値は以下のようになります。]}許可されたパーミッションをキー、許可されているか否かの真偽値を値に持ちますが、installedというのだけ若干例外で、アプリをインストール済みか否かを指します。ユーザのアプリインストール時やログイン時、このAPIを利用してどのパーミッションが与えられているのかをチェックすることになります。Requestログイン時の認証の流れは、ザックリと以下のようになります。APIへのリクエストが一回余計に発生してしまいます。Requestでユーザのパーミッション一覧を取得する」で紹介していますので、そちらをご覧ください。API場合によっては、ユーザのログイン時だけでなく、よりリアルタイムにパーミッションの変化を知りたい場合があります。Requestで紹介した方法ではユーザが次にログインするまで削除されたことを知ることができず、定期実行時にエラーが出続けることになります。APIオブジェクトやそのコネクションに変化があった際にリアルタイムに受け取ることが可能です。PubSubHubbubに詳しい方は取っ付きやすいかもしれませんが、渡されるのがJSONだったりするなどの違いがあります。APIの仕様との一貫性などの理由から変更したそうです。APIを用いて設定する必要があります。流れは以下の通りです。Graphオブジェクトのどのフィールドの変化を購読したいのか伝えます。このリクエストに対するレスポンスが返されるより先に、FacebookはアプリのコールバックURLに対して確認用のリクエストを送ってきます。ここで適切なレスポンスを返すと確認手順が完了し、購読が成立して最初のリクエストに対するレスポンスが返されます。それでは詳細を見てみます。リクエスト送信アプリがFacebook側へリクエストを送り、購読の対象を指定します。{APP_ACCESS_TOKEN}"この際のパラメータは以下の通りです。購読する対象のオブジェクトのタイプを指定します。指定できるのはuser、page、permissionsのいずれかです。今回はpermissionsを指定します。上記objectのプロパティもしくはコネクションの中で、購読したいもの。カンマ区切りでパーミッションを指定します。objectとfieldsで指定した対象に変化があったときに通知を受け取るURL。アプリ側で指定するトークンです。Facebookからの確認用リクエストで送られてきます。確認用リクエスト受信FacebookからアプリのコールバックURLへとリクエストが送られてきます。"{CALLBACK_URL}?hub.mode=subscribe&hub.challenge=XXXX&hub.verify_token={APP_GENERATED_TOKEN}"ここで渡されるパラメータは以下の通りです。これは常にsubscribeが渡ります。最初のリクエストでこちらから渡したverify_tokenがそのまま渡ってきます。アプリ側での確認用です。Facebookが生成して渡してくるランダムな文字列。レスポンスとして、status200と共に返します。200とverify_tokenの値を返します。購読状況を確認する購読中の内容を確認するには以下のエンドポイントにアクセスします。"https://graph.facebook.com/{APP_ID}/subscriptions?access_token={APP_ACCESS_TOKEN}"返り値は以下のキャプチャの通りです。nameフィールドを購読していることが分かります。APIのドキュメントに変更があり、userオブジェクトのeventsコネクションも購読できるようになりました。userオブジェクトのドキュメントには反映されていませんが、テストした限りでは、キャプチャの通り購読できているようです。"https://graph.facebook.com/{APP_ID}/subscriptions"objectパラメータを付け忘れると全購読が解除されますので注意してください。POSTリクエストでも代用できます。実際の通知内容は以下のキャプチャのようになります。コネクションが変更されたかのみ通知されます。キャプチャのように配列で渡ってくるのは、変更の都度、完全なリアルタイムで送られてくるわけではなく、5秒に一回、もしくは未通知の変更が1000件を超えたときに一気に送られてくる為です。通知に失敗した場合は、徐々に頻度を下げつつ、24時間の間はリトライされます。APIで最新情報を取得してくることになります。Requestを活用すると効果的です。ユーザがFacebook上でアプリを削除してしまったら?アプリで退会処理を踏まず、Facebook上の設定・管理画面からアプリを削除されてしまうこともあり得ます。いった場合の対処方法は「ユーザがFacebookアプリを削除したときに通知を受けるには」を参照してください。おまけドキュメントの更新が激しくて、それに追いつくの大変ですよねという話をしました。公式ブログのエントリーで、その週に更新されたドキュメントURLがリストアップされていたこともありましたが、該当ページのどの部分が更新されているかを把握するのも面倒でした。前任者が実装したシェアボタンのドキュメントが、シェアボタンといいね!ボタンの統合で消えてしまったりして、あとから追いようが無いという問題もありました。ページをバージョン管理しています。アクセスして確認すると、当時のバージョンのまま遷移もできて少し便利かなと思っています。今後ドキュメントの和訳を更新する際は、githubのコミットログのページか何かへのリンクを張るとかして、どの段階まで対応しているかを明示します。「この和訳の更新が追いついていないんだけど」とかあったらOklahomerページにメッセージ送るなどしてお知らせください。返され方が変わります動画の削除機能はドキュメントの誤りで、実はサポートされてませんでした。