Skip to main content

​
Standard v1.1 と X API v2 の比較

Standard v1.1 の GET statuses/show や GET statuses/lookup を利用している場合、このガイドは、Standard v1.1 と X API v2 の投稿ルックアップ用エンドポイントの共通点と相違点を理解するうえで役立ちます。 X API v1.1 のデータ形式 と X API v2 の形式 の違いをすばやく確認するには、ビジュアルデータ形式移行ツール もあわせてご覧ください。
  • 共通点
    • OAuth 1.0a ユーザーコンテキスト
    • 1 リクエストあたりの投稿数の上限
    • 投稿の編集履歴とメタデータのサポート
  • 相違点
    • エンドポイント URL
    • App および Project の要件
    • レスポンスのデータ形式
    • リクエストパラメータ

​
共通点

​
OAuth 1.0a ユーザーコンテキスト認証方式

標準エンドポイントは OAuth 1.0a User Context をサポートしており、新しい X API v2 のポストルックアップエンドポイントは、OAuth 1.0a User Context と OAuth 2.0 App-Only の両方をサポートします。したがって、以前にいずれかの標準 v1.1 のポストルックアップエンドポイントを使用していた場合は、X API v2 のバージョンに移行しても同じ認証方式を引き続き使用できます。 App-Only 認証は、使い始めるうえで最も手軽な方法でしょう。App Access Token の生成方法については、この OAuth 2.0 App-only ガイド を参照してください。

​
リクエストごとの投稿数の制限

v1.1 の GET statuses/lookup エンドポイントでは、1 回のリクエストにつき最大 100 件の投稿を指定できます。これは GET /tweets エンドポイントにも同様に適用されます。最大の 100 件を指定するには、クエリパラメータとして ids パラメータを使用し、Post IDs をカンマ区切りのリストとして指定してください。 ポストの編集履歴とメタデータのサポート どちらのバージョンも、編集履歴を示すメタデータを提供します。詳細については、Post lookup APIリファレンスおよび Edit Posts fundamentals page を参照してください。

​
相違点

​
エンドポイント URL

  • Standard v1.1 エンドポイント:
    • https://api.x.com/1.1/statuses/show
    • https://api.x.com/1.1/statuses/lookup
  • X API v2 エンドポイント:
    • https://api.x.com/2/tweets
    • https://api.x.com/2/tweets/:id

​
App と Project の要件

X API v2 エンドポイントでは、認証のために Project に関連付けられた developer App の認証情報が必要です。X API v1.1 エンドポイントでは、Project に関連付けられていない App からの認証情報でも、Project に関連付けられた App からの認証情報でも使用できます。

​
レスポンスデータ形式

standard v1.1 と X API v2 のエンドポイントバージョンの大きな違いの 1 つは、ペイロード内でフィールドがどのように選択されるかです。 standard エンドポイントでは、多くのレスポンスフィールドがデフォルトで含まれており、パラメータを使用して追加のフィールドを指定することができます。 一方、X API v2 では、デフォルトでポストの id と text フィールドのみが返されます。追加のフィールドやオブジェクトを取得するには、fields と expansions パラメータを使用する必要があります。展開されたフィールドはレスポンス内の includes オブジェクトに含まれ、ID を照合することでメインのポストオブジェクトと対応付けることができます。 fields と expansions の使用方法については、fields と expansions の使い方ガイドを参照してください。データ形式の移行ガイドでは、standard v1.1 のフィールドを新しい v2 のフィールドに対応付けています。 さらに、X API v2 では、ポストオブジェクトや user オブジェクトなどに対して新しい JSON 設計が導入されています。
  • standard エンドポイントではポストオブジェクトは statuses 配列で返されますが、X API v2 では data 配列が使用されます。
  • X API v2 では、「statuses」という用語は、リツイートされたツイートおよび引用ツイート (Retweeted / Quoted Tweets) という用語に置き換えられます。
  • like のような新しい用語が、favorites や favourites のような用語を置き換えます。
  • 値を持たない属性 (例: null) は、X API v2 のペイロードには含まれません。
X API v2 のポストオブジェクトには、次のような新しいフィールドが含まれます。
  • conversation_id
  • 2 つの新しい annotations フィールド (context と entities)
  • 新しい metrics フィールド
  • 特定のポストに誰が返信できるかを示す reply_setting フィールド

​
リクエストパラメータ

次の標準 v1.1 リクエストパラメータには、X API v2 で対応するパラメータがあります。
StandardX API v2
idids
一部の標準 v1.1 パラメータは、X API v2 では サポートされていません。
StandardComment
tweet_modeフィールドと expansions の機能に置き換えられました。
trim_userフィールドと expansions に置き換えられました。ユーザーデータには author_id の expansion と user.fields を使用してください。
include_my_retweet認証ユーザーによるリツイートされた投稿について、その元のポストの ID を返します。
include_entitiesペイロード内のエンティティを制御するには、フィールドと expansions を使用してください。
include_ext_alt_text代替テキストが存在する場合、メディアエンティティに ext_alt_text フィールドを追加します。
include_card_uri広告カードが添付されている場合に card_uri を追加します。
mapv1.1 でフィールドが null にされていたのとは異なり、X API v2 では利用できない投稿に対してポストの ID とエラーメッセージを返します。

​
コード例

以下の例では、標準的な v1.1 エンドポイントと、それに対応する v2 エンドポイントを示します。認証情報は実際のトークンに置き換えてください。v2 エンドポイントの場合、トークンは developer App が属する Project のものを使用する必要があります。 v1.1 のレスポンスペイロードは v2 のものとは異なります。v2 では、フィールド と expansions パラメータを使用して、さまざまなフィールドをリクエストできます。 複数ポストのルックアップ: v1.1 GET statuses/lookup → v2 GET /tweets
cURL (v1.1)
curl --request GET \
  --url 'https://api.x.com/1.1/statuses/lookup.json?id=1460323737035677698%2C1460323743339741184' \
  --header 'Authorization: Bearer $ACCESS_TOKEN'
単一ポストのルックアップ: v1.1 GET statuses/show/:id → v2 GET /tweets/:id
cURL (v1.1)
curl --request GET \
  --url 'https://api.x.com/1.1/statuses/show.json?id=1460323737035677698' \
  --header 'Authorization: Bearer $ACCESS_TOKEN'