RESTFul APIrepresentation state transfer Application Program

representation state transfer Application Program Interface 表示性状态转移接口

API 设计规范

1、将一切数据视作资源

2、利用 HTTP 请求方式，描述对资源的操作（增/删/改/查）

3、通过 HTTP 响应状态码，描述对资源的操作结果（如： 200/5xx）

1、看 URL 知道是什么资源（接口语义化）

2、看 Method 知道要对资源进行什么操作

3、看 Response Code 知道操作是否成功

1、GET 用于读取资源

2、POST 用于创建资源

3、PUT 用于更新资源（客户端提供更新后的完整资源）

4、Patch 用于局部更新（客户端提供资源局部变量）

5、DELETE 用于删除资源

URL 规范：只使用名词，不能有动词

{
  code: //描述状态
  data: // 返回数据
  message: //状态描述
}

对所有接口的返回结构保持统一

1、有效降低沟通成本

2、前后端解耦更彻底

3、前端更多业务灵活性

现在已经不是ASP JSP的直出页面的时代，也不是单个服务器只服务于单个前端的时代，一套好的接口规范可以大幅降低前后端的沟通成本，其次后端可以更专注于维护一套通用的接口服务，前端更专注于业务，前后端分离的更加彻底；最后规范约束了接口具备更强的原子性，把更多的业务灵活性交回给前端

思考问题：接口要升级如何处理？

遇到事务性业务逻辑要如何设计？