Skip to main content

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

如果你一直在使用 Standard v1.1 的 GET blocks/ids 和 GET blocks/list endpoint，本指南旨在帮助你了解 Standard v1.1 与 X API v2 封锁查询 endpoint 之间的相同点与差异。
  • 相同点
    • 认证
  • 差异
    • Endpoint URL
    • 每次请求的用户数量限制
    • 对 App 和 Project 的要求
    • 响应 data 格式
    • 请求参数

​
相似之处

身份验证 Standard v1.1 和 X API v2 的封禁查询 endpoint 都使用 OAuth 1.0a 用户上下文。因此，如果你此前使用过 Standard v1.1 的某个封禁查询 endpoint，在迁移到 X API v2 版本后，仍可继续使用相同的身份验证方法。 

​
差异

Endpoint URL 每次请求的用户数量限制 Standard v1.1 endpoint 允许每次请求返回最多 5000 名用户。新的 v2 endpoint 允许每次请求返回最多 1000 名用户。要返回完整的 1000 名用户，你需要将 max_results=1000 作为 query 参数传入；随后可以将响应负载中返回的 next_token 作为下一次请求中的 pagination_token query 参数传入。   App 和 Project 要求 X API v2 endpoint 要求在对请求进行身份验证时，使用与 Project 关联的开发者 App的凭证。所有 X API v1.1 endpoint 都可以使用独立 App 或与 Project 关联的 App 的凭证。 响应数据格式 Standard v1.1 与 X API v2 版本的 endpoint 之间最大的差异之一在于如何选择在负载中返回哪些 fields。 对于 standard endpoint，你默认会接收许多响应字段，然后可以选择使用参数来指定应在负载中返回哪些字段或字段集合。 X API v2 版本默认仅返回用户 id、name 和 username 字段。要请求任何其他字段或对象，你需要使用 fields 和 expansions 参数。你从此 endpoint 请求的任何用户字段都会返回在主 用户对象 中。任何展开的 Post 对象及其字段都会返回在响应中的 includes 对象内。随后，你可以通过匹配用户对象与展开的 Post 对象中存在的 ID，将任意展开对象与用户对象对应起来。  我们建议你在各自的指南中进一步了解这些新参数，或阅读我们的如何使用 fields 和 expansions指南。  我们还整理了一份数据格式迁移指南，帮助你将 standard v1.1 字段映射到较新的 v2 字段。本指南还将提供你在 v2 请求中为返回特定字段需要传入的具体 expansion 和 field 参数。    除请求某些字段的方式发生变化外，X API v2 还为 API 返回的对象引入了新的 JSON 设计，包括 Post 和 user 对象。
  • 在 JSON 根级别，standard endpoint 在 statuses 数组中返回 Post 对象，而 X API v2 返回 data 数组。 
  • X API v2 的 JSON 不再引用被转发和被引用的“statuses”，而是引用被转发和被引用的 Tweets。许多旧版和已弃用字段（例如 contributors 和 user.translator_type）正在被移除。 
  • X API v2 不再同时使用 favorites（在 Post 对象中）和 favourites（在 user 对象中），而是采用术语 like。 
  • X 采用的约定是：没有值的 JSON 值（例如 null）不会写入负载。仅当 Post 和 user 属性具有非 null 值时才会被包含。   
我们还在 Post 对象中引入了一组新字段，包括：
  • 一个 conversation_id 字段
  • 两个新的 annotations 字段，包括 context 和 entities
  • 若干新的 metrics 字段 
  • 一个新的 reply_setting 字段，用于显示谁可以回复某条 Post
请求参数 以下 Standard v1.1 请求接受两个 query（查询）参数（user_id 或 screen_name）。X API v2 只接受数值型用户id，且必须作为 endpoint 路径的一部分传递。
⌘I