点赞查询

点赞查询：标准 v1.1 与 X API v2 的比较

如果你一直在使用标准 v1.1 的 GET favorites/list 端点，本指南旨在帮助你了解标准 v1.1 与 X API v2 点赞查询端点之间的相同点与差异。

在 v2 中，我们还引入了一个新的“已点赞用户”端点，可用于获取某条 Post 的点赞用户信息。

• 相似点
  • 身份验证
  • 速率限制
• 差异
  • 端点 URL
  • 请求限制
  • 应用和项目要求
  • 请求参数
  • 新的 JSON 格式

相似之处

认证

标准 v1.1 和 X API v2 的点赞查询端点都使用 OAuth 1.0a 用户上下文 或 OAuth 2.0 Bearer Token。因此，如果你之前使用的是标准 v1.1 的 GET favorites/list 端点，在迁移到 X API v2 时，如有需要可以继续使用相同的认证方式。 

视你选择的认证库/包而定，Bearer Token 认证通常是最容易上手的方式，并且可以通过一个简单的请求头设置。要了解如何生成 Bearer Token，请参阅这篇 OAuth 2.0 Bearer Token 指南。   

速率限制

标准 v1.1 的 GET favorites/list 端点对每个用户的速率限制为每 15 分钟 75 次请求。v2 中相应的已点赞 Post 端点也有相同的速率限制。不过，该 v2 端点还另外对每个应用设置了每 15 分钟 75 次请求的速率限制。

差异

端点 URL

• 标准 v1.1 端点：
  • GET https://api.x.com/1.1/favorites/list.json （指定用户发布的 Post 列表）
  • v1.1 中没有与 v2 “liking users” 端点等效的端点
• X API v2 端点：
  • GET https://api.x.com/2/users/:id/liked_tweets （指定用户 ID 点赞过的 Post 列表）
  • GET https://api.x.com/2/tweets/:id/liking_users （点赞了指定 Post ID 的用户列表）

请求限制

v2 的“已点赞 Post”端点允许你每次请求 5 到 100 条 Post，但可以使用分页令牌获取某条 Post 的全部点赞。v1.1 的 GET favorites/list 端点同样允许获取 Post 的全部点赞，但每次请求可拉取 20 到 200 条 Post。

对于 v2 的“liking users”端点，每条 Post 最多返回 100 位点赞用户。  

应用和项目要求

在对 X API v2 端点进行身份验证时，你必须使用与某个项目关联的开发者应用的凭证。所有 X API v1.1 端点可使用独立版应用，或与项目关联的应用的凭证。

请求参数

以下标准 v1.1 端点接受两个查询参数（user_id 或 screen_name）。X API v2 仅接受数值型用户 ID，且必须作为端点路径的一部分传递。

标准 v1.1 与 X API v2 端点版本之间的主要差异之一，是你如何选择在载荷中返回的字段。标准端点提供多个参数来指定返回哪些字段或字段集合，而 X API v2 将这些参数简化为fields和expansions。  

新的 JSON 格式

X API v2 为 API 返回的对象引入了新的 JSON 设计，包括 Post 和 user 对象。

• 在 JSON 根级别，标准端点在 statuses 数组中返回用户对象，而 X API v2 返回 data 数组。
• X API v2 的 JSON 不再引用转发与引用的“statuses”，而是引用 Retweeted 和 Quoted Tweets。许多遗留和已弃用字段（例如 contributors 和 user.translator_type）将被移除。
• X API v2 不再在 Post 对象中使用 favorites、在 user 对象中使用 favourites，而是统一使用术语 like。
• X 采用这样的约定：没有值的 JSON 字段（例如 null）不会写入载荷。仅当 Post 和 user 属性具有非空值时才会包含。  

除了新的 JSON 格式外，我们还为 Post 对象引入了一组新字段，包括：

• conversation_id
• 两个新的 Post annotations 字段：context 和 entities
• 多个新的metrics 字段