ユーザーのブロックおよびブロック解除エンドポイントは、Enterprise プランでのみ利用可能です。Enterprise の関心表明フォームはこちらからご記入いただけます。
Blocks lookup: Standard v1.1 と X API v2 の比較
これまで standard v1.1 の GET blocks/ids および GET blocks/list エンドポイントを利用してきた方向けに、standard v1.1 と X API v2 の blocks lookup エンドポイントの類似点と相違点を理解するのに役立つことを目的としたガイドです。- 類似点
- 認証
- 相違点
- エンドポイント URL
- リクエストあたりのユーザー数上限
- App と Project の要件
- レスポンスデータ形式
- リクエストパラメータ
類似点
認証 standard v1.1 と X API v2 の blocks lookup エンドポイントはいずれも OAuth 1.0a User Context を使用します。したがって、以前 standard v1.1 の blocks lookup エンドポイントのいずれかを利用していた場合、X API v2 版へ移行しても同じ認証方式を継続して利用できます。相違点
エンドポイント URL- Standard v1.1 エンドポイント:
- GET https://api.x.com/1.1/blocks/ids.json (指定したユーザーがブロックしている user ID のリスト)
- GET https://api.x.com/1.1/blocks/lists.json (指定したユーザーがブロックしているユーザーのリスト)
- X API v2 エンドポイント:
- GET https://api.x.com/2/users/:id/blocking (指定した user ID がブロックしているユーザーのリスト)
- JSON のルートレベルでは、standard エンドポイントは 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 とユーザーの属性は、非 null の値を持つ場合のみ含まれます。
- conversation_id フィールド
- context と entities を含む 2 つの新しい annotations フィールド
- いくつかの新しいメトリクスフィールド
- 特定の Post に誰が返信できるかを示す、新しい reply_setting フィールド
コード例
ブロック中のユーザーを取得 (v2)
cURL
ユーザーをブロック (v2) — Enterprise のみ
cURL