RESTful API

RESTful API（Representational State Transfer）是由 Roy Fielding 于 2000 年在博士论文中提出的一种接口设计风格，如今已成为 Web 服务的主流范式。它的出发点很简单：把业务能力看作可寻址的"资源"，再借助 HTTP 自身的语义去操作这些资源，完成常见的增删改查。

RESTful API 的设计要点

• 无状态：每个请求自带完整信息（如凭证），服务器无需保存会话状态。
• 前后端分离：客户端只管展示与交互，服务端负责数据与业务。
• 统一接口：以 HTTP 动词（GET、POST、PUT、DELETE 等）表达动作，规范一致。
• 支持缓存：响应可标注为可缓存，降低延迟与服务器压力。
• 分层架构：可由网关、负载均衡等中间层扩展系统能力。

HTTP 动词的含义

• GET：查询资源，不改变服务端状态。
• POST：新建资源或提交处理请求。
• PUT：整体更新资源，用提交内容替换原资源。
• DELETE：移除指定的资源。
• PATCH：只更新资源的局部字段。

URL 设计建议

在 REST 风格中，URI 只用来表示资源本身，动词交给 HTTP 方法，名词用复数、层级表达从属关系。一个典型的图书接口可以这样设计：

• GET /books：获取全部图书。
• GET /books/{id}：按 ID 查询单本图书。
• POST /books：新增一本图书。
• PUT /books/{id}：整体更新指定图书。
• DELETE /books/{id}：删除指定图书。

响应状态码

调用方依据 HTTP 状态码即可判断请求结果：

• 200 OK：处理成功并返回数据。
• 201 Created：资源创建成功。
• 204 No Content：成功但无返回体。
• 400 Bad Request：请求参数有误。
• 401 Unauthorized：未认证或认证失败。
• 404 Not Found：资源不存在。
• 500 Internal Server Error：服务端发生异常。

小结

RESTful API 之所以流行，在于它依赖 HTTP 的既有语义，学习成本低、可扩展性好，几乎天然适配各类规模的 Web 应用，从简单的单体服务到庞大的分布式系统都能受益。