サイトのトップへ戻る

Twitter 開発者 ドキュメント日本語訳

サイト内検索

ユーザーストリーム

  1. Endpoint
  2. Connections
  3. User Stream messages
    1. Types of messages
    2. Data from accounts the user follows
    3. Replies
    4. Direct messages
  4. Best Practices
    1. User streams and the REST API
    2. filtering Tweets for display


概要

ユーザーストリームを使って、認証ユーザー固有のデータやイベントをストリーム内に取り込むことができます。 ユーザーストリームはサーバ間接続を想定していないので注意してください。同一の装置から、複数のユーザーの代わりにTwitterへ接続する必要がある場合はサイトストリームの使用を検討してください。



エンドポイント



接続

あなたのアプリケーションがユーザーストリームに再接続をする回数は最小限に抑えてください。 IPアドレスに関係なく、各Twitterアカウントが一つのOAuth 認証済みアプリケーションで同時にユーザーストリームに接続できる数は少しの回数に制限されています。 アプリケーションごとの制限を超過すると、最も古い接続が切断されます。 An account logging in from too many instances of the same OAuth application will cycle connections as the application instances reconnect and disconnect each other.

アプリケーションでは、アカウントのログイン頻度が多すぎることを示すHTTP 420エラーコードに対処できるようにしなければなりません。 この応答は、アカウントが上記で説明したアカウントごと-アプリケーションごとの接続制限を超過したことを示しています。 ログイン頻度が多すぎるため、自動的かつ一時的にユーザーストリームから接続が切られたことを示します。 おそらく他の端末上で重複起動させているであろうアプリケーションを終了させ、ストリーミングアクセスを復元することをお勧めします。

各アプリケーションは独自の割り当てを持っているのでApp1 からのログインはApp2へ影響を与えず、逆の場合も影響はありませんが、App1 やApp2を非常に多く重複起動した場合は問題が発生ことがあるので注意してください。また、アプリケーションに関わらずIPアドレスごとに同時に接続できる数も制限があるので注意してください。

複数のTwitter アカウントの同時表示をサポートしているアプリケーションでは、アカウントごとに接続を開くことができます。



ユーザーストリームのメッセージ

メッセージのタイプ

REST APIで取得されるものとは異なったストリーミングメッセージがいくつかあります。詳細についてはストリーミングメッセージのタイプ を参照してください。

ユーザーがフォローしているアカウントからのデータ

withパラメータを使って受信するメッセージのタイプを制御できます。ユーザーストリームの既定では with=followingsが設定されており、ユーザーとそのユーザーがフォローしている相手(認証ユーザーがフォローしているアカウント)のデータを取得します。 with=userを設定すると認証ユーザーに関するイベントのみが送信され、認証ユーザーがフォローしている相手のイベントは送信されません。

リプライ

既定では、 @replies はお互いにフォローしている相手からのみ送られてきます。フォローしている相手の全ての @replies は、replies=all パラメータを設定して使用することができます。例えば、アリスがボブをフォローしており、アリスがキャロルをフォローしていない場合、既定ではボブがキャロルに @replies を送ってもそのツイートはアリスには表示されません。 この既定動作は、twitter.comとapi.twitter.com の動作に準拠しています。アプリケーションで全ての @replies やフィルタ済みの一部@repliesを表示したい場合はreplies=allを使用してください。

ダイレクトメッセージ

ダイレクトメッセージを使うには適切な権限が必要です。the Application Permission Modelを参照してください。



ベストプラクティス

ユーザーストリームと REST API

アプリケーションでユーザーストリームとREST APIの両方を使用すると、汎用性が非常に高くなります。例えば、携帯ネットワークとWiFiを切り替えるモバイルアプリでは、接続が不安定なときはREST APIでポーリングをし、それ以外ではユーザーストリームへ接続し、パフォーマンスを向上させることができます。 An application which connects to a User Stream may also backfill from the REST API to cover disconnected periods.

REST からユーザーストリームへ切り替える時は、ユーザーストリームとの接続確立が成功した後に最後のRSET APIポーリングが行い、データの欠落が起こらないようにしてください。

ユーザーストリームから切断された時は、REST API ポーリングを行うまでに少なくとも1、2分は再接続を試行して下さい。 こうした間を置くことによって、ユーザーストリームAPIで些細なエラーが起きた時だけでREST APIのリクエストが増大してしまうことを防げます。

ストリーミングAPIを使用している間は、REST APIを速度制限一杯まで使うことは避けてください – REST APIはあくまで補助用として最小限の使用にとどめてください。

表示するツイートをフィルタする

Maintain a set of the user’s followings to determine the contents of the home timeline. Apply follow social events to this set to keep the client set synchronized with the server side set. Expect retweets and mentions of the connected user. If you have DM access, expect direct messages from and to the connected user. All remaining tweets are the result of track and location filters, if specified.

Honor deletion messages. If a following deletes a tweet, you must remove the tweet from display and any application/server storage.

Consider obtaining a list of blocked users from the REST API regularly using GET blocks / ids. Blocked accounts are filtered on the server-side in the home timeline. There is no need to fetch or apply the block list if only displaying the home timeline or the user timeline. Track results and @mentions, are not filtered for blocked accounts. Consider optionally grabbing the block list to filter blocked accounts from track results. The block list should be cached locally - the change velocity is usually quite low. If possible, save the cache to disk to avoid polling for the block list upon startup. An update interval of 6 to 24 hours would be reasonable.