API 经济：为什么越来越多产品先做接口，再做界面
「API 优先」听起来是技术偏好，实际是商业判断：界面只能覆盖一种使用方式，接口能被别人组合出很多种。
一、为什么接口先做
1. 分发不靠自己
做一个网站，只能等用户来。开放接口，别人可以在自己的产品里用你的能力——这是把你的分发交给合作方，成本比自己买量低得多。
2. 多端复用
同一套能力要供给网页、小程序、App、企业内部系统。接口化之后，每多一个端只是多一个客户端，不再是重写一遍。
3. 内部解耦
接口定清楚，前后端可以并行，第三方接入也不用改核心代码。这是工程上的收益，和商业无关但同样重要。
二、接口设计里最贵的三个决定
| 决定 | 选错的代价 |
|---|---|
| 鉴权方式 | 改一次要所有接入方一起改，几乎做不到 |
| 分页与限流 | 后期加限制会被骂「先放开再收紧」 |
| 错误码与幂等 | 接入方无法判断「失败要不要重试」，会产生重复数据 |
这三项一旦对外发布就很难改，比选技术栈重要得多。
三、鉴权：三种常见形态
- API Key：简单，适合服务端对接，但泄露风险高，必须有轮换机制；
- OAuth：适合「用户授权第三方访问自己数据」的场景，链路长但边界清楚；
- 签名（HMAC）：适合高安全要求，能防重放，实现成本也最高。
选型的判断点：这次调用代表「应用」还是「用户」。代表应用用 Key，代表用户用 OAuth。站内有一篇讲公众号网页授权流程的，可以对照看链路的复杂度。
四、限流要提前设计
不限流的接口，上线第一天就可能被打满。三种常见策略：
- 固定窗口：每分鐘 N 次，实现最简单，边界会有突发；
- 滑动窗口：更平滑，实现稍复杂；
- 令牌桶：允许短时突发，适合有波峰的业务。
对外接口建议「默认宽松 + 明确写在文档里」，并保留随时调整的余地，同时给出超限时的标准返回（状态码 + 重试建议）。
五、文档就是产品
接口类产品的转化率，八成取决于文档：
- 能不能在五分钟内跑通第一个请求（curl 示例、可复制的 token）；
- 错误码是否分类清楚（客户端错误 / 服务端错误 / 配额问题）；
- 有没有「常见坑」章节（时区、编码、幂等、重试）；
- 变更日志是否公开（接入方最怕悄悄改行为）。
六、不适合开放接口的场景
如果你的能力本身依赖「人来看」，或者数据敏感度极高，开放接口的收益很低、风险很高。判断标准：接口的价值 = 被组合的可能性 × 组合方的付费意愿，两者有一个接近零就别做。
多端分发时怎么选入口，见 小程序、App、Web 的成本账；开放接口后的商业化，见 开源项目的商业化路径。
相关阅读
版权声明：如无特殊标注，文章均为本站原创，转载时请以链接形式注明文章出处。
评论