申请推特开发者账号：审批、密钥，以及你到底需不需要它
申请推特开发者账号：审批、密钥，以及你到底需不需要它
在开始申请之前，有一个问题能省下很多时间：你需要的是开发者账号，还是 X 的数据？
★这不是同一件事。★ 开发者账号是 X 的正门 —— 如果你要发帖、回复、或以认证用户身份操作，它是必需的。而如果你只是要读取公开数据，它只是若干条路之一，而且往往不是最快的那条。
这篇讲申请流程、密钥管理、webhook 问题，以及什么情况下整件事可以跳过。
申请流程
在哪申请： X 开发者门户。用普通 X 账号登录，所以你得先有一个 —— 而且需要绑定并验证手机号，这一步经常卡住人。
要填什么： 描述你在做什么、会怎么使用数据。写得朴素一点。 "做一个内部看板监控品牌提及"是比某种含糊而宏大的说法更好的答案。
要等多久： 从立刻通过到好几天不等。没有公布的时限，也没有队列位置可查。 如果你的申请慢，除了等没有别的办法。
★开发者账号本身是免费的。花钱的是它授予的 API 访问★ —— 见各档实际要多少钱，因为杀死大多数项目的是定价，不是审批。
⚠️ 免费档是以写入为主的。 如果你申请时预期能有量地读取推文，先看清档位限制再动手。这是最常见的一个意外。
如果卡点就是等审批、而你只需要读公开数据，有一条不需要申请的路 —— 没有门户，也没有用途审查。
你会拿到什么：各种密钥
通过审批后，你会得到一个项目、项目里的一个 app，以及一组凭据。这些名字很容易混，因为它们来自 API 的不同年代：
| 凭据 | 用来做什么 |
|---|---|
| API Key / API Secret | 标识你的 app。有时叫 consumer key/secret |
| Bearer Token | 仅 app 身份的认证。读取公开数据用它就够 |
| Access Token / Secret | 代表某个用户操作。发帖必需 |
实际的分界： 读公开数据只需要 bearer token。以用户身份操作 —— 发帖、关注、点赞 —— 才需要 access token 对，而那要走 OAuth。
★如果你的应用永远不需要以某个人的身份操作，你就永远不需要用户令牌★ —— 而这意味着小得多的安全面。
怎么管密钥才不会后悔
- 绝不提交进代码库。 用环境变量或密钥管理服务。公开仓库里的密钥会在几分钟内被自动扫描器发现，不是几天。
- 一旦泄露立即轮换。 重新生成是即时且免费的。
- 一个项目一个 app。 共用凭据会让你无法判断是哪个项目在烧配额，也无法在不影响另一个的情况下吊销其中一个。
- 搞清楚爆炸半径。 ⚠️ 泄露一个用户 access token，意味着别人能以你的身份发帖；泄露一个只读密钥，意味着别人能花掉你的配额。★这是两种非常不同的糟糕日子★ —— 这也是"只读还是可写"这个区分值得在意的原因。
关于 webhook
这一点会让人意外，所以直说。
★不存在一个通用的"某账号发帖时通知我"的 webhook。★ X 的 webhook 式推送是为账号活动场景准备的 —— 你自己认证账号上的私信和事件 —— 而且需要另一套审批。它不是一个用来盯别人公开时间线的机制。
那怎么发现新推文？
- 轮询。 反复问、和已见过的做比对。简单、到处可用，而成本完全由你的间隔决定 —— 而那正是决定账单的那个数字。
- 流式连接。 一条持久连接，数据到达即推送。延迟更低，但要维持的活动部件更多。
这两者之间的权衡才是真正的架构决策，而且它和你有没有开发者账号无关。
★我们为什么选流式而不是 webhook★
我们提供 WebSocket 流，并且刻意不提供 webhook。理由如下，因为这个决定会影响你怎么接入：
webhook 把接收方的可用性变成了你的问题。 如果你的端点宕了十分钟，总得有人决定那些事件怎么办 —— 缓冲、丢弃、重试、重试多久。每个 webhook 服务商最后都要建一套重试队列、死信策略和签名机制，而★这里的每一处都是事件会悄悄消失的地方★。
流把它反过来了。 连接握在你手里。你断了，你自己知道断了 —— 你的客户端看到了断开。重连、续传。不存在"投递到底发生过没有"的歧义，因为根本没有投递动作，只有一条你在或不在的连接。(我们的流就是这样做的，正是出于这个理由。)
诚实的权衡： webhook 上手更容易 —— 不需要常驻进程，一个 HTTP 端点就行；流需要一条被监管的连接。⚠️ ★如果你明确就是要 webhook，我们没有，这是一个去看别家的正当理由。★ 我们宁可这么说，也不把轮询包装成 webhook。
什么情况下你不需要开发者账号
你需要它，如果： 你要发帖、回复、点赞、关注，或代表用户操作。没有替代方案 —— 没有任何第三方能替你做写操作，任何声称能做的都想要你的账号凭据。
你可能不需要它，如果： 你只是读公开数据。那就变成了一道比较题 —— 官方 API vs 托管数据接口 vs 自己写爬虫 —— 而决定因素是成本、审批时间，以及 X 一改动谁来维护。完整对比在这里。
★简短版：写入必须用官方 API。读取则是一道选择题。★
大家会问的问题
怎么申请推特开发者账号？ 用一个绑定了手机号的 X 账号在开发者门户申请、描述用途、等待批准。
推特开发者账号免费吗？ 账号免费。 超出免费档的 API 访问按量计费 —— 见当前定价。
开发者审批要多久？ 从立刻到好几天不等。没有公布时限，也没法查进度。
我的开发者申请为什么被拒？ 通常是用途描述太含糊，或者请求的东西和档位对不上。用一段具体的说明重新申请。
推特开发者门户在哪？
developer.x.com。旧的 developer.twitter.com 地址一般会跳转过去。
怎么拿到 X API key？ 通过审批后在门户里建一个项目和一个 app。密钥在 app 的 Keys and Tokens 里。
API key 和 bearer token 有什么区别？ API key 标识你的 app。bearer token 用于仅 app 身份的请求 —— 读公开数据用的就是它。
access token 是干什么的？ 代表某个用户操作。 发帖必需；读公开数据不需要。
怎么重新生成密钥？ 在 app 的 Keys and Tokens 里。重新生成是即时的，并会让旧的立即失效 —— 部署新值期间会有短暂中断。
密钥泄露了会怎样？ 别人能花掉你的配额。泄露用户 access token 更糟 —— 那允许以你的身份发帖。两种情况都要立即轮换。
推特有 webhook 吗？ 没有那种通用的"通知我某账号的动态"的机制。 webhook 式推送只存在于你自己账号的活动场景，而且要单独审批。
怎么在别人发推时收到通知？ 定时轮询，或者维持一条流式连接。两种做法的对比是值得读的那篇。
不申请开发者账号能用 API 吗？ X 自己的不行。第三方数据接口不需要它就能读公开数据，但它们不能写。
读推文需要开发者账号吗？ 用 X 官方 API 需要。就"读取公开数据"这件事本身而言，不需要 —— 还有别的路。
推特的 OAuth 是干什么的？ 让用户授权你的应用代表他操作。只有做写操作时才相关。
能建多少个 app？ 取决于档位。免费档限制在很少的项目和 app 数量。
能几个项目共用密钥吗？ 技术上可以，实际上别这么做。你会失去归因用量的能力，也无法单独吊销其中一个项目。
开发者门户是用来干什么的？ 管理项目和 app、查看用量、重新生成凭据。它是管理后台，不是开发工具。
我的 API key 为什么不管用？ 常见原因：在该用 bearer token 的地方用了 API key、重新生成后新值还没部署、或者调了档位之外的端点。
申请之前能先试用 API 吗？ X 自己的不能。第三方接口通常能立刻发一次调用 —— 这往往是更快弄清"你的想法到底行不行"的办法。
项目和 app 有什么区别？ 项目是与你的访问档位绑定的容器；里面的 app 持有凭据。大多数人各要一个。
有免费的推特 API key 吗？ 免费档存在，而且以写入为主 —— ★它的读取权限少到大多数读取场景都放不进去★。
bearer token 是什么？ 一个作为请求头发送、用于应用级鉴权的凭据。 ★把它当密码对待★ —— 拿到它的人就能花你的配额。
开发者控制台在哪？ 在开发者门户里，项目、app 和密钥都在那里。
官方的开发者工具有哪些？ 门户、文档，以及接口本身。 ★其余全是第三方★ —— 怎么评估第三方。
读取公开数据需要开发者账号吗？ ★不一定。★ 开发者账号是用来使用 X 自己的接口的 —— 通过其它服务商读取公开数据并不需要它。
如果你在做路线选型
两个问题就能定：
你要往 X 写入吗？ 那就需要开发者账号，剩下的都是流程。这里没有任何东西可以替代。
你只读公开数据吗？ 那就比成本、比多久能发出第一次调用、比 X 改动时谁来修。
我们的 API 是只读那条路：在控制台拿一个 key，没有申请、没有用途审查，固定按次价格，没有属于你的限流要管。它在设计上就是只读的 —— ★这也意味着密钥泄露损失的是配额，永远不是你的账号★。
发出前就被我们拒绝的请求，以及我方原因导致的错误，不计费。
延伸阅读：官方 API 要花多少钱 · 轮询 vs 流式 · 正确处理限流 · 获取 X 数据的每一种途径对比。