Facebook開発者向けドキュメントの日本語訳とTips

http://developers.facebook.com/docs/ に記載されているdocumentationの和訳と、調べていて分かったノウハウを紹介します。
Life is tough, so are we.
ドキュメント全体の目次はこちら
Facebook関連情報はFacebookページで共有しています。

Open Graph Follows

Open Graph Followsの和訳です。6月28日にOpen Graphのビルトインアクションとして追加されたfollowアクションを紹介しています。独自のOpen Graphアクションを定義する際には一般的で簡潔な動詞を指定するよう勧められていますが、そうして色々なアプリで定義された利用頻度の高いアクションを、Facebook Platformが順次ビルトインアクションとして取り込んでいる印象です。ビルトインアクションとして登録された場合、それまで独自で定義していたアクションからビルトインアクションへの切り替えを強制されますが、Facebook上で最適に表示・拡散されるなどの利点があります。


以下、2012年6月27日 14:45更新分までの本文です。

Facebook上でユーザ投稿を購読するのと同様に、アプリ上での他ユーザのOpen Graphアクティビティをフォローすることができるようになりました。たとえば、映画のレビューサイトでは、ユーザはお気に入りのレビュアーをフォローすることができます。アプリ上でユーザが他ユーザをフォローすると、フォロワーとフォロー相手がFacebookで友だちではなくても、フォロワーのニュースフィードにはフォロー相手の該当アプリでのアクティビティが流れるようになります。(ただし、アクティビティのプライバシー設定で閲覧が許可されている場合に限ります。)



attachment




Publishing Follow Actions

フォロー関係を成立させるには、ビルトインのog.followsアクションを使います。これを使う場合には、App Dashboardで先に設定してください。



attachment2


設定が完了してアクションがアプリに追加されたら、Facebookに申請します(ただし、他のアクションと同じく、申請が通る前でもアプリ管理者, 開発者, テスターはアクションを利用できます)。ユーザのアクティビティをフォローするには以下のエンドポイントにHTTP POSTリクエストを送ります。

https://graph.facebook.com/FOLLOWER_UID/og.follows

FOLLOWER_UIDはフォロワーになるユーザのFacebook User IDです。ユーザのアクセストークンからユーザを割り出すことができるため、FOLLOWER_UIDの代わりにmeというエイリアスを使うことも可能です。

https://graph.facebook.com/me/og.follows

リクエスト時には、Facebook UER IDもしくはURLを示すprofileフィールドも指定します。

profile=8903343
profile=https://www.facebook.com/ola

ここで指定するURLはfacebook.comのURLである必要はなく、以下のような指定もできます。

profile=http://www.rottentomatoes.com/celebrity/tom_hanks/

この場合、指定されたページのメタタグにはfb:profile_idが記述され、Facebook IDが指定されている必要があります。

<meta property="fb:profile_id" content="lbRw_a8fwsz8u7a_-iL5bCxjJ8w" />

このfb:profile_idにはユーザのthird_party_idを指定することをお勧めします。これはGraph APIのUserオブジェクトにアクセスする際に ?fields=third_party_id を追加することで取得できます。

このメタタグは必須ではなく、これが無くてもfollowアクションは成立しますが、その場合はフォロワーのニュースフィードにはアクティビティは流れません。

followが成功すると、購読IDが以下のように返されます。

{
  "id": "10101357697814503"
}

Reading Follow Actions

以下のエンドポイントにHTTP GETリクエストを送信することで、ユーザがフォローしている相手を取得することができます。

https://graph.facebook.com/FOLLOWER_ID/og.follows
FOLLOWER_IDは先ほど述べたようにmeというエイリアスを指定するとこもできます。返り値は、JSONエンコードされたフォロー相手情報の配列です。
{
  "data": [
    {
      "id": "10101394432772353", 
      "from": {
        "id": "1207059", 
        "name": "Dhiren Patel"
      }, 
      "start_time": "2012-06-27T20:40:16+0000", 
      "end_time": "2012-06-27T20:40:16+0000", 
      "publish_time": "2012-06-27T20:40:16+0000", 
      "application": {
        "id": "138483919580948", 
        "name": "Social Cafe"
      }, 
      "data": {
        "profile": {
          "id": "1681", 
          "url": "https://www.facebook.com/boz", 
          "type": "profile", 
          "title": "Boz"
        }
      }, 
      . . . 

Notifications and Stories for Follow Activity

アプリ上でユーザが他ユーザをフォローすると、フォロワーの最近のアクティビティ欄にフォローアクティビティが追加されます。



attachment3


また、フォロワーの通知欄には、アプリ上で誰かをフォローした旨を伝える通知が流れます。



attachment4


注意:通知はfb:profile_idメタタグが指定された場合で、なおかつアプリをインストール済の場合にのみ流れます。

ユーザAとユーザBが友だちであった場合、ニュースフィードに流れる内容は変わりません。その場合、フォロワーの通知欄には何も流れず、ただ最近のアクティビティ欄にフォローアクティビティが追加されます。また、フォローにはpublish_actionsパーミッションが必要です。

フォローが成立すると、フォロー相手がアプリ上でアクションを行った場合、それがリアルタイムフィードとニュースフィードに流れます。



attachment5



attachment6


ユーザが他ユーザをフォローすると、https://www.facebook.com/<username>/subscribedtoにフォロー相手が追加されます。(ここでは購読とフォローが同じ物として扱われています。)

facebook.com上での購読と同様、ユーザはフォロー相手の投稿に対していいね!やコメントをすることができます。ただし、コメントできるのはフォロー相手がプライバシー設定で許可している場合のみです。


Un-Following

フォローを解除するには、以下のエンドポイントにHTTP DELETEリクエストを送信します。

https://graph.facebook.com/購読ID

解除に成功すればtrue、失敗すればエラーが返されます。


App Center Internationalization

App Center Internationalizationの和訳です。アプリ詳細ページをこの手順に従って翻訳しておくことで、App CenterやFacebook上でユーザのロケールに合わせた翻訳内容を表示できます。



以下、2012年7月10日 15:06更新分までの本文です。

Facebookは現在、多くの言語に対応しています。App Centerもローカライズ対応しているため、ユーザのロケールに合わせて最適なユーザ体験を提供することが可能です。

Localizing your App

1. メインの言語を選択する

アプリ設定ページのApp Centerタブで選択するメインの言語(Primary Language)は、未対応のロケールで閲覧するユーザが見るものとなります。

カスタマイズしたOpen Graphアクションを定義している場合は、この言語はEnglish(US)に指定され、英語に対応していなくてはなりません。もちろん、以下に説明するように別の言語を追加することも可能で、それらの言語で閲覧しているユーザにはその内容が表示されます。



attachment7


2. 追加する言語を選択する

localizeタブを選択し、そこから追加する言語を選びます。アプリユーザの傾向を基に言語がレコメンドされます。レコメンドされた言語、もしくはFacebookがサポートする言語の中から選択してください。



attachment8


3. 翻訳内容を入力する

メインの言語で入力した内容がグレーアウトした状態の入力フォームが表示されます。tagline, description, detailed descriptionをそれぞれ入力してください。追加のパーミッションを要求していて、その内容に関してメインの言語で説明している場合は、その翻訳も必須です。Display nameとPublisherは任意です。

アプリの詳細をApp CenterやFacebook上で閲覧するユーザは、自分のロケールに対応した翻訳があればそれを見ることになります。アプリの情報を翻訳していても、アプリ本体はローカライズされていないという場合、Detailed Descriptionの欄に利用可能言語をリストアップする必要がありますので気をつけてください。



attachment9


4. 保存して提出する

入力が完了したら"Save"をクリックします。サポートしたい全ての言語の入力が完了するまで、"Selected Language"から言語を選択して入力作業を続けてください。

最後に、App Centerタブへ遷移し、Submitで提出します。App Centerへ追加される前に翻訳内容がレビューされ、ガイドラインに準拠しているかチェックされます。

Where your translated App will appear

App Centerが多くの国で利用できるようになるにつれ、ユーザはIPアドレスを基にアクセス地域を判別され、その国で人気のあるアプリが表示されるようになります。この動作はApp Center Settingsのページでカスタマイズでき、自分が選択した国で人気のあるアプリを中心に表示できます。

App Centerで表示されるアプリ詳細ページのデフォルト言語は、閲覧ユーザのロケールです。アプリが翻訳されていない場合は、指定されたメインの言語で表示されます。

英語以外のアプリ詳細ページは、英語で閲覧しているユーザに表示されないことに注意してください。

Facebook Night vol.7 発表内容まとめ 3:Batch RequestとReal-time Update API

Facebook Night vol.7 発表内容まとめ 1:publish_streamとpublish_actions」で主要な2パーミッションの違いを、「Facebook Night vol.7 発表内容まとめ 2:認証ダイアログの構成」では、それら2つの認証ダイアログ上での扱いの違いを紹介しました。その過程で、ユーザがアプリをインストールしたからと言って、全部のパーミッションを許可しているとは限らないことや、あとからFacebook上の設定ページでパーミッションが消されうることを話しました。ここでは、それに対応する実装方法を紹介します。

与えられたパーミッションを確認する

例えば機能の1つとして、ユーザの好きな本一覧を取得し、そこからおススメの本をレコメンドするような機能を提供していたとします。user_likesパーミッションが許可されなかったり消されたりしたら必要なデータを読み込めなくなってしまいますから、算出方法を切り替えるとか、場合によっては該当ユーザへのレコメンド機能自体を非表示にする必要が出てくるかもしれません。
それには、ユーザがどのパーミッションを許可してくれているのか、少なくともユーザがサービスを利用する旅に知る必要があります。これにはGraph APIのユーザオブジェクトのpermissionsコネクションを参照します。
以下の2種類のいずれかを用います。
curl -X GET "https://graph.facebook.com/me/permissions?access_token=USER_ACCESS_TOKEN"
curl -X GET "https://graph.facebook.com/{USER_ID}/permissions?access_token=APP_ACCESS_TOKEN"
返される値は以下のようになります。
{
  "data": [
    {
      "installed": 1,
      "publish_actions": 1,
      "user_likes": 1,
    }
  ]
}
許可されたパーミッションをキー、許可されているか否かの真偽値を値に持ちますが、installedというのだけ若干例外で、アプリをインストール済みか否かを指します。ユーザのアプリインストール時やログイン時、このAPIを利用してどのパーミッションが与えられているのかをチェックすることになります。

Batch Request

ログイン時の認証の流れは、ザックリと以下のようになります。
  • 認証ダイアログのページへリダイレクト
  • 完了後、アプリ側(redirect_uri)へリダイレクト
  • 渡されたcodeパラメータを元にアクセストークン取得
  • ユーザ情報取得
これらの処理の後にパーミッション一覧を取得する手順を挟むと、Grpah APIへのリクエストが一回余計に発生してしまいます。そういった場合に複数のGraph APIリクエストをまとめてしまうのがBatch Requestと呼ばれる物なのですが、Facebook Nightで発表した内容は全て「ログイン時、Batch Requestでユーザのパーミッション一覧を取得する」で紹介していますので、そちらをご覧ください。

Real-time Update API

場合によっては、ユーザのログイン時だけでなく、よりリアルタイムにパーミッションの変化を知りたい場合があります。例えばユーザのステータス投稿を定期的に取得したいならuser_statusパーミッションが必要となりますが、このパーミッションがFacebook上の設定画面から削除されてしまった場合、Batch Requestで紹介した方法ではユーザが次にログインするまで削除されたことを知ることができず、定期実行時にエラーが出続けることになります。
Real-time Update APIを利用すると、Facebook上でGraph APIオブジェクトやそのコネクションに変化があった際にリアルタイムに受け取ることが可能です。PubSubHubbubに詳しい方は取っ付きやすいかもしれませんが、渡されるのがJSONだったりするなどの違いがあります。quoraで紹介されている限りでは、昔はPubSubHubbubで実装されていたものの、他のGraph APIの仕様との一貫性などの理由から変更したそうです。

流れ

どの情報を購読するのか、どのコールバックURLで通知を受けるのかを、Graph APIを用いて設定する必要があります。流れは以下の通りです。
rt
Subscriberであるアプリが、Publisher / HubとなるFacebookへリクエストを送り、どのOpen Graphオブジェクトのどのフィールドの変化を購読したいのか伝えます。このリクエストに対するレスポンスが返されるより先に、FacebookはアプリのコールバックURLに対して確認用のリクエストを送ってきます。ここで適切なレスポンスを返すと確認手順が完了し、購読が成立して最初のリクエストに対するレスポンスが返されます。

それでは詳細を見てみます。

Step1. リクエスト送信

アプリがFacebook側へリクエストを送り、購読の対象を指定します。

curl -X POST http://graph.facebook.com/{APP_ID}subscriptions \

 -F "object=permissions" \                                                                                                                                                       

 -F "fields=email,publish_actions,user_birthday,read_friendlists" \

 -F "callback_url={CALLBACK_URL}" \

 -F "verify_token={APP_GENERATED_TOKEN}" \

 -H "Authorization: OAuth {APP_ACCESS_TOKEN}"

この際のパラメータは以下の通りです。
  • object: 購読する対象のオブジェクトのタイプを指定します。指定できるのはuser、page、permissionsのいずれかです。今回はpermissionsを指定します。
  • fields: 上記objectのプロパティもしくはコネクションの中で、購読したいもの。カンマ区切りでパーミッションを指定します。
  • callback_url: objectとfieldsで指定した対象に変化があったときに通知を受け取るURL。
  • verify_token: アプリ側で指定するトークンです。Facebookからの確認用リクエストで送られてきます。

Step2. 確認用リクエスト受信

FacebookからアプリのコールバックURLへとリクエストが送られてきます。
curl -X GET "{CALLBACK_URL}?hub.mode=subscribe&hub.challenge=XXXX&hub.verify_token={APP_GENERATED_TOKEN}"
ここで渡されるパラメータは以下の通りです。
  • hub.mode: これは常にsubscribeが渡ります。
  • hub.verify_token: 最初のリクエストでこちらから渡したverify_tokenがそのまま渡ってきます。アプリ側での確認用です。
  • hub.challenge: Facebookが生成して渡してくるランダムな文字列。レスポンスとして、status200と共に返します。

Step3. レスポンスを返す

Facebookから渡されたhub.verify_tokenがアプリ側から送信したverify_tokenと一致することを確かめたら、HTTP Status 200とverify_tokenの値を返します。

Step4. 最初のリクエストのレスポンスを受け取る

Step3までが正しく完了すればstatus 200が返り、不備があればstatus 400が返ります。

購読状況を確認する

購読中の内容を確認するには以下のエンドポイントにアクセスします。
curl -X GET "https://graph.facebook.com/{APP_ID}/subscriptions?access_token={APP_ACCESS_TOKEN}"
返り値は以下のキャプチャの通りです。userオブジェクトのevents, locale, nameフィールドを購読していることが分かります。話が逸れてしまいますが、この発表の前の週にReal-time Update APIのドキュメントに変更があり、userオブジェクトのeventsコネクションも購読できるようになりました。userオブジェクトのドキュメントには反映されていませんが、テストした限りでは、キャプチャの通り購読できているようです。

sub

購読の解除

任意のオブジェクトのみ購読解除
curl -X DELETE "https://graph.facebook.com/{APP_ID}/subscriptions?object=XXX"
全購読解除
curl -X DELETE "https://graph.facebook.com/{APP_ID}/subscriptions"
objectパラメータを付け忘れると全購読が解除されますので注意してください。
また、ここに限らず、Graph APIでHTTP DELETEメソッドを使う箇所はmethod=deleteパラメータ指定でのHTTP POSTリクエストでも代用できます。

通知

実際の通知内容は以下のキャプチャのようになります。
20faed988943194f1dc877e756c2a221
ここでは変更内容が伝えられることは無く、どのオブジェクトのどのフィールド / コネクションが変更されたかのみ通知されます。キャプチャのように配列で渡ってくるのは、変更の都度、完全なリアルタイムで送られてくるわけではなく、5秒に一回、もしくは未通知の変更が1000件を超えたときに一気に送られてくる為です。通知に失敗した場合は、徐々に頻度を下げつつ、24時間の間はリトライされます。
こうして通知されたオブジェクトIDとフィールドを元に、Graph APIで最新情報を取得してくることになります。変更されたオブジェクトの情報がある程度まとめて送られてきますので、ここでもBatch Requestを活用すると効果的です。

ユーザがFacebook上でアプリを削除してしまったら?

アプリで退会処理を踏まず、Facebook上の設定・管理画面からアプリを削除されてしまうこともあり得ます。そういった場合の対処方法は「ユーザがFacebookアプリを削除したときに通知を受けるには」を参照してください。

おまけ

ドキュメントの更新が激しくて、それに追いつくの大変ですよねという話をしました。公式ブログのエントリーで、その週に更新されたドキュメントURLがリストアップされていたこともありましたが、該当ページのどの部分が更新されているかを把握するのも面倒でした。また、前任者が実装したシェアボタンのドキュメントが、シェアボタンといいね!ボタンの統合で消えてしまったりして、あとから追いようが無いという問題もありました。
そこで、6月上旬からはFBDocsで https://developers.facebook.com/docs/* のページをバージョン管理しています。左ナビゲーションのリンク先も、ドキュメント内のリンクであれば href="/docs/XXX" に置き換えてありますので、git cloneしてきて確認したいバージョンに戻しておいて、ブラウザで http://localhost/docs/XXX にアクセスして確認すると、当時のバージョンのまま遷移もできて少し便利かなと思っています。
今後ドキュメントの和訳を更新する際は、githubのコミットログのページか何かへのリンクを張るとかして、どの段階まで対応しているかを明示します。「この和訳の更新が追いついていないんだけど」とかあったらOklahomerページにメッセージ送るなどしてお知らせください。

Facebook Night vol.7 発表内容まとめ 2:認証ダイアログの構成

Facebook Night vol.7 発表内容まとめ 1:publish_streamとpublish_actions」ではアプリからの投稿周りで多用するパーミッション2つの違いを紹介しましたので、ここでは認証ダイアログをおさらいして、そこでの両パーミッションの違いを紹介します。

新・認証ダイアログは2画面構成

3/9から強制以降が始まった新・認証ダイアログは、「User and Friends Permissions(ユーザ自身と友だちに関するパーミッション)」と「Extended Permissions(追加のパーミッション)」の2画面構成となっていて、それぞれ役割が違います。ここでは、email, publish_actions, user_birthday, read_friendlistsの4つのパーミッションを要求するものとして進めます。

User and Friends Permissions

これは認証ダイアログの1ページ目にあたる部分です。アプリが要求するパーミッションのうち、ユーザ自身と友だちの情報に関するパーミッションがここに表示されます。最低限の読み込み系が多く、書き込み系のパーミッションはあまり扱われませんが、publish_actionsはここで要求されます
次のステップへ進んでアプリを利用するには、ユーザはここに表示される全部のパーミッションを許可しなくてはなりません。パーミッション一覧や下のキャプチャを見ると分かりますが、ユーザのメールアドレスを求めるemailパーミッションもこのページに表示されます。
auth-test
必要なさそうなパーミッションまで要求されると、ユーザが躊躇してそこで終わってしまいますので、要求しすぎないことが大切です。

Extended Permissions

こちらは2ページ目にあたる部分で、ユーザに取って影響の大きいパーミッションが扱われます。ユーザの友だちリストやメールボックスを読み込むパーミッションや、イベントを作成するパーミッションなどが要求されるほか、publish_streamもここで要求されます
1ページ目との動作の違いは、このページではどのパーミッションを許可するかユーザが選択できる点です。
auth-test2
キャプチャを見ると分かる通り、右側に「x」が表示され、これを押すことで個々のパーミッションリクエストを拒否することができます。
auth-test3
そこで注意しなくてはならないと思うのは以下の2点です。
  • 認証が完了したからと言って、要求したパーミッションが全部与えられているとは限らない
    (私の場合、まだ友だちが使っていないアプリだったりすると、どんな内容が投稿されるのか想像がつかないのでpublish_streamを躊躇ってしまいます。)
  • 拒否したパーミッションは次回移行の認証でも毎回要求されるので、ユーザ自身で選択できて親切とは言え、かなりうっとおしい
拒否した分を次回以降も要求されるので、こちらの場合でもやはり、必要以上に要求しないことが大切です。

パーミッションと認証ダイアログのまとめ

前回の記事と今回の認証ダイアログのまとめは以下の通りです。

ダイアログのページ

まず、認証ダイアログの1ページ目と2ページ目を意識するという点。publish_actionsは認証ダイアログの1ページ目でpublish_streamは2ページ目ですから、投稿系のパーミッションをpublish_actionsですませることが出来れば、認証ダイアログは1ページで済ませられるかもしれません。
また、間違ってpublish_actionsとpublish_streamの両方を要求すると、その要求はpublish_actionsの上位にあたるpublish_streamの要求へとマージされます。これは2ページ目に表示されますので、ユーザは拒否することが可能となってしまい、publish_actionsにしておけば必ず許可してもらえたチャンスを逃してしまいます。

必要なときに必要なパーミッションをリクエスト

もう一点大事なことは、必要なときに必要なパーミッションのみ要求することだと思います。アプリのインストール時には全ユーザに共通して必要となる最低限のパーミッションのみ要求し、あとは設定画面を設けておいて、On / Offの切り替え時に適宜要求するなどです。Kloutは最初のログイン時はフィード読み込みなどのパーミッションしか要求せず、設定画面でFacebook共有をOnにするときに初めて投稿系パーミッションを要求します。自分の影響度という繊細な部分を扱うサービスなので、最初から投稿系パーミッションを要求されると、自分の影響度が勝手に投稿されると感じてためらうユーザもいるでしょうから、そのようなユーザの不安を避ける上でも参考になる実装例だと思います。
On / Offを切り替える際、ユーザがすでに該当するパーミッションを許可しているか否かを把握し、必要に応じてパーミッションを要求する必要がありますが、それに関しては3番目のエントリで紹介します。
(※あとから追加でパーミッションを要求する場合は、追加で要求するパーミッションのみscopeに指定して認証ダイアログに飛ばせば大丈夫です。他のパーミッションをscopeに指定しなかったからといって、既に許可されたパーミッションが消されてしまうことはありません。)

(発表では新・認証ダイアログの詳細な設定については省きましたが、ドキュメントは和訳:Auth Dialogをご覧ください。)

実装する

これらを踏まえてアプリ開発を進めようとすると、publish_streamが許可されなかったのに「友だちのウォールに投稿」ボタンを表示してしまうことが無いよう、認証完了時にユーザがどのパーミッションを許可しているのか把握する必要があります。
また、アプリ利用開始時には許可していたパーミッションでも、Facebook上のプライバシー設定ページから消されてしまうことがありますので、それを把握する必要も出てきます。
それらの実装方法については、「Facebook Night Vol.7 発表内容まとめ3 Batch RequestとReal-time Update API」で紹介します。

Facebook Night vol.7 発表内容まとめ 1:publish_streamとpublish_actions

6/26のFacebook Night Vol.7で登壇しましたので、発表内容をまとめておきます。
話した内容はざっくり以下の3点です。

  • 混同してしまうpublish_streamとpublish_actionsパーミッションの違いを、最近の仕様変更をふまえて紹介する
  • 認証ダイアログの1ページ目と2ページ目の違いと、先述したパーミッションの扱いの違い
  • 実装に落とし込む

30分の発表時間に対して若干詰め込みすぎな感じがありましたので、スライドや発表内容から削った部分も補足しつつ3エントリーに分けて紹介します。

パーミッション取得の現状と問題点

実装の最初の段階でしか考えない

まず現状として、ユーザからのパーミッション取得はアプリのインストール時(利用開始時)の認証ダイアログに頼っている場合が多いと思います。ユーザがログインボタンを押すと以下のようなURLへリダイレクトされ、Facebook認証ダイアログが表示されるような使い方です。
https://www.facebook.com/dialog/oauth?
    client_id=YOUR_APP_ID
   &redirect_uri=YOUR_REDIRECT_URI
   &scope=COMMA_SEPARATED_LIST_OF_PERMISSION_NAMES
   &state=SOME_ARBITRARY_BUT_UNIQUE_STRING
ユーザがアプリをインストールすればscopeで指定したパーミッションが許可され、その権限に従ってアプリはユーザの代理として情報の読み書きが出来ます。ここでパーミッションを取得する仕組みを作り、あとは機能の実装となる為、認証部分の実装以降はパーミッションの扱いはないがしろになってしまいます。

それでも仕様変更は多い

後から見返すことは少ないとはいえ、直近数ヶ月だけでも大きめの変更はたくさんあります。
offline_access廃止に関してはすでに色々な方が話されているので、ここではpublish_streamとpublish_actionsの変更と認証ダイアログの移行についておさらいします。

publish_actionsとpublish_streamパーミッションの変更

以前の仕様

publish_actionsパーミッションは去年9月のf8(参加レポート:Facebook f8に参加してきました!)で発表されたOpen Graphアクションの実装用に追加されたパーミッションで比較的新しい物です。これを取得することで、ユーザのタイムラインに対してOpen Graphアクションを投稿することが可能となります。
それに対しpublish_streamは昔からある物で、ユーザ自身のウォール、友だちのウォール、グループやイベントへ投稿したりできるほか、コメントに対していいね!できるなど、投稿系で必要とされるパーミッションです。
ここで問題となったのは、アプリで画像を生成してそれをユーザのウォールに投稿し、同時にユーザのタイムラインにもOpen Graphアクションを投稿しようとした場合、publish_streamとpublish_actionsパーミッションの両方を求める必要があったという点です。これらの背景については、publish_streamとpublish_actionsパーミッションの統合というエントリーで紹介しています(統合という表現を選んだのを後悔してます)。

変更後の仕様

以前の仕様の問題点を克服するため、publish_actionsとpublish_streamの位置づけが大きく変わりました。それぞれのパーミッションでできることを一覧にしてみます。
publish_actionsでできること
  • Open Graphアクションの投稿
  • ユーザ自身のウォールに投稿
  • ビデオ / 画像の投稿(アルバム作成を含む)
  • ビデオ / 画像へのタグ付け
  • フィードに対していいね! / コメント
publish_streamでできること
  • publish_actionsの全て
  • 友だちのウォールに投稿
  • クエスチョンを投稿
  • ノートを投稿
  • イベント / グループに投稿
見ると分かる通り、publish_actionsはpublish_streamの一部という扱いになった為、publish_streamは publish_actionsの持つ全ての権限を持っています。また、publish_actionsはユーザ自身のウォールに投稿したり、コメント を書き込めるなどの書き込み権限も与えられています。旧仕様に従ってpublish_streamを求めたままになっているアプリでも、大体はpublish_actionsさえ要求すれば事足りるということが分かります。
とりあえずpublish_streamを要求しておけばpublish_actionsの権限もカバーできるので楽ですが、友だちのウォールにまで投稿されてしまうかもしれないpublish_streamと、自分のウォールに限定されるpublish_actionsでは、ユーザにとっての不安の度合いは大きく変わるはずです。1部のスパムアプリのせいでFacebookアプリ全部が疑われてしまうと心配するだけでなく、自分たちも必要最小限のパーミッションのみ要求し、ユーザを不安にさせないアプリ作りをすることが必要なんじゃないかと思っています。

次の「Facebook Night Vol.7 発表内容まとめ 2:認証ダイアログの構成」では、移行後の新・認証ダイアログの構成と、ダイアログ上でのpublish_actions / publish_streamの扱いの違いを紹介します。
記事検索