Skip to main content

​
like 查询：Standard v1.1 与 X API v2 的比较

如果你一直在使用 Standard v1.1 的 GET favorites/list endpoint，本指南旨在帮助你理解 Standard v1.1 与 X API v2 的 like 查询 endpoints 之间的相似点与差异。 在 v2 中，我们还引入了一个新的 liked users endpoint，可用于获取对某个 Post 点过 like 的用户信息。
  • 相似点
    • 身份验证
    • 请求速率限制
  • 差异
    • endpoint URL
    • 请求限制
    • App 和 Project 要求
    • 请求参数
    • 全新的 JSON 格式

​
相似之处

身份验证 Standard v1.1 和 X API v2 的 like 查询 endpoint 均支持使用 OAuth 1.0a 用户上下文 或 OAuth 2.0 Bearer Token。因此，如果你之前使用的是 Standard v1.1 的 GET favorites/list endpoint，在迁移到 X API v2 时，如有需要可以继续沿用相同的身份验证方式。 根据你所选用的身份验证库/包，Bearer Token 身份验证通常是最易上手的方式，并且只需设置一个简单的请求头即可。要了解如何生成 Bearer Token，请参阅 本 OAuth 2.0 Bearer Token 指南。 请求速率限制 Standard v1.1 的 GET favorites/list endpoint 对每位用户的请求速率限制为每 15 分钟 75 次。v2 中相应的 liked Posts endpoint 也有相同的请求速率限制。但该 v2 endpoint 还另外对每个 App 设有每 15 分钟 75 次的请求速率限制。

​
差异

Endpoint URL 请求限制 v2 liked Posts endpoint 允许每次请求 5 到 100 条 Post，但可通过分页令牌获取某条 Post 的所有 like。v1.1 的 GET favorites/list endpoint 也允许获取 Post 的所有 like，但每次请求可获取 20 到 200 条 Post。 对于 v2 liking users endpoint，每条 Post 最多返回 100 个点赞用户。    App 和 Project 要求 在对请求进行身份验证时，X API v2 endpoints 要求你使用与一个 开发者 App 关联并隶属于某个 Project 的凭证。所有 X API v1.1 endpoints 则可以使用独立 App，或与 Project 关联的 App 的凭证。 请求参数 以下 Standard v1.1 接口接受两个查询参数（user_id 或 screen_name）。X API v2 仅接受数值型用户 ID，且必须作为 endpoint 路径的一部分传入。 Standard v1.1 与 X API v2 的一大差异在于如何选择响应负载中返回的字段。Standard 端点提供多个参数用于指定返回哪些字段或字段集，而 X API v2 将这些参数简化为 fields 和 expansions。    新的 JSON 格式 X API v2 为 API 返回的对象引入了新的 JSON 设计，包括 Post 和 user 对象。
  • 在 JSON 根级，Standard 端点在 statuses 数组中返回用户对象，而 X API v2 在 data 数组中返回。 
  • X API v2 的 JSON 不再引用被转发和被引用的“statuses”，而是引用被转发和被引用的 Tweets。许多遗留与已弃用字段（例如 contributors 和 user.translator_type）将被移除。 
  • 相较于同时使用 favorites（Post 对象中）和 favourites（user 对象中），X API v2 统一使用术语 like。 
  • X 采用约定：对于无值的 JSON 字段（例如 null），不写入负载。仅当 Post 和 user 属性为非空时才会包含。  
除上述新的 JSON 格式变更外，我们还在 Post 对象中引入了一组新字段，包括：
⌘I