Skip to main content

リストメンバーのルックアップ: Standard v1.1 と X API v2 の比較

standard v1.1 の GET lists/members および GET lists/memberships エンドポイントを使用している場合、このガイドは、standard v1.1 と X API v2 のリストメンバー用エンドポイントの共通点と相違点を理解するのに役立ちます。
  • 共通点
    • 認証方法
  • 相違点
    • エンドポイント URL
    • レート制限
    • App および Project の要件
    • 1 リクエストあたりのデータオブジェクト数の上限
    • レスポンスデータ形式
    • リクエストパラメータ

類似点

認証 どちらのバージョンのエンドポイントも、OAuth 1.0a User ContextApp only の両方をサポートしています。したがって、これまで標準 v1.1 の List メンバーエンドポイントのいずれかを利用していた場合でも、X API v2 版へ移行しても同じ認証方法をそのまま使い続けることができます。 利用している認証ライブラリ/パッケージにもよりますが、App only 認証はおそらく最も簡単に使い始められる方法であり、シンプルなリクエストヘッダーを設定するだけで利用できます。App only Access Token の生成方法については、この App only ガイドを参照してください。

違い

エンドポイント URL レート制限
Standard v1.1X API v2
/1.1/lists/members.json

OAuth 1.0a User Context 利用時、15 分間に 900 リクエスト

App のみ利用時、15 分間に 15 リクエスト
/2/lists/:id/members

OAuth 1.0a User Context 利用時、15 分間に 900 リクエスト

OAuth 2.0 Authorization Code with PKCE 利用時、15 分間に 900 リクエスト

App のみ利用時、15 分間に 900 リクエスト
/1.1/lists/memberships.json

OAuth 1.0a User Context 利用時、15 分間に 15 リクエスト

App のみ利用時、15 分間に 15 リクエスト
/2/users/:id/list_memberships

OAuth 1.0a User Context 利用時、15 分間に 15 リクエスト

OAuth 2.0 Authorization Code with PKCE 利用時、15 分間に 15 リクエスト

App のみ利用時、15 分間に 15 リクエスト
App と Project の要件 X API v2 エンドポイントでは、リクエストの認証時に developer App の認証情報を使用する必要があり、その App は Project に関連付けられている必要があります。すべての X API v1.1 エンドポイントは、Project に関連付けられていない App と Project に関連付けられた App のいずれの認証情報も使用できます。 1 リクエストあたりのデータオブジェクトの上限 標準 v1.1 の /1.1/lists/members エンドポイントでは、1 リクエストあたり最大 5000 ユーザーを返すことができます。新しい v2 エンドポイントでは、1 リクエストあたり最大 100 ユーザーを返すことができます。デフォルトでは 100 個のユーザーオブジェクトが返されます。結果数を変更するには、クエリパラメーター max_results= に 1〜100 の数値を指定する必要があります。その後、レスポンスペイロードで返される next_token を次のリクエストの pagination_token クエリパラメーターに渡すことでページネーションを行えます。 さらに、/1.1/lists/memberships エンドポイントでは、1 リクエストあたり最大 1000 件のリストを返すことができます。v2 の代替エンドポイントでは、1 リクエストあたり最大 100 件のリストを返すことができます。デフォルトでは 100 件のリストオブジェクトが返されます。結果数を変更するには、/1.1/lists/members と同様に、クエリパラメーター max_results= と pagination_token を使用してください。 レスポンスデータの形式 標準 v1.1 と X API v2 のエンドポイントバージョンの最大の違いの 1 つは、ペイロードにどのフィールドを含めるかの選択方法です。 標準エンドポイントでは、多くのレスポンスフィールドがデフォルトで返され、さらにどの追加フィールドやフィールドセットをペイロードに含めるかをパラメーターで指定できます。 X API v2 バージョンの /users/:id/list_memberships では、デフォルトでリストの id と name フィールドが返されます。追加のフィールドやオブジェクトをリクエストするには、fields および expansions パラメーターを使用する必要があります。このエンドポイントからリクエストしたリストのフィールドは、プライマリのリストオブジェクト内に返されます。展開されたオブジェクトとフィールドは、レスポンス内の includes オブジェクト内に返されます。その後、プライマリオブジェクトと展開されたオブジェクトの両方に含まれる ID を照合することで、展開されたオブジェクトをプライマリのリストオブジェクトに対応付けることができます。  以下は、取得可能なリストのフィールドと expansions の例です:
  • created_at
  • follower_count
  • member_count
  • owner_id
  • description
  • private
EndpointExpansion
/2/lists/:id/memberspinned_tweet_id
/2/users/:id/list_membershipsowner_id
これらの新しいパラメーターについては、それぞれのガイド、または fields と expansions の使用方法 に関するガイドを参照して、詳しく確認することをおすすめします。  標準 v1.1 のフィールドを新しい v2 のフィールドにマッピングするのに役立つ データ形式移行ガイド も用意しています。このガイドでは、特定のフィールドを返すために v2 リクエストと併せて指定する必要がある、具体的な expansion および field パラメータについても説明しています。  特定のフィールドのリクエスト方法の変更に加えて、X API v2 では、Post オブジェクトや user オブジェクトを含む、API が返すオブジェクトに対して新しい JSON 設計も導入しています。
  • JSON のルートレベルでは、標準 v1.1 のエンドポイントは Post オブジェクトを statuses 配列で返しますが、X API v2 では data 配列で返します。 
  • Retweeted および Quoted の「statuses」を参照する代わりに、X API v2 の JSON では Retweeted および Quoted Tweets を参照します。contributors や user.translator_type など、多くのレガシーおよび非推奨フィールドは削除されます。 
  • Post オブジェクトでの favorites と user オブジェクトでの favourites の両方を使用する代わりに、X API v2 では like という用語を使用します。 
  • X では、値を持たない JSON 値 (たとえば null) はペイロードに書き込まないという規約を採用しています。Post および user の属性は、非 null の値を持つ場合にのみ含まれます。
リクエストパラメータ 次の Standard v1.1 のリクエストパラメータには、X API v2 での対応があります。 List メンバー取得
Standard v1.1X API v2
list_idid
slug対応なし
owner_screen_name対応なし
owner_id対応なし
countmax_results
cursorpagination_token
include_entities対応なし
skip_status対応なし
List メンバーシップ取得
Standard v1.1X API v2
user_idid
screen_name対応なし
countmax_results
cursorpagination_token