API（应用程序接口）

REST 的约束与现实

Roy Fielding 在 2000 年博士论文中提出 REST（表述性状态转移），定义了六个约束（无状态、统一接口、可缓存等）。REST API 以 HTTP 方法（GET/POST/PUT/DELETE）操作资源（URL 表示），返回 JSON 或 XML。真正符合 REST 所有约束（包括 HATEOAS 超媒体链接）的 API 极少，大多数所谓「RESTful API」只满足基本的资源-HTTP 方法约定。

REST 的主要缺点在于过度取数（Over-fetching，返回一堆不需要的字段）和多次往返（获取一篇文章的作者信息还需要再发一个请求）。Facebook 2015 年提出的 GraphQL 让客户端精确声明所需字段，一次查询可嵌套获取多层关联数据，在复杂前端场景下特别受欢迎。[1]

gRPC 与 API 设计的工程考量

gRPC（Google，2015）使用 Protocol Buffers 序列化和 HTTP/2 传输，比 JSON over HTTP 快 5-10 倍，天然支持双向流式调用。它是微服务内部通信的热门选择（Kubernetes 内部组件大量使用），但浏览器直接调用有限制（需要 gRPC-Web 代理）。

API 设计的最佳实践：版本化（/v1/users 避免破坏性变更影响现有用户）、幂等性（相同请求多次调用结果相同，POST 创建要特别设计）、限流（Stripe 对免费账户限制 100 req/s）、清晰的错误码（不要把所有错误都返回 500）。