REST API 含义

REST不是rest这个单词，而 REpresentation State Transfer的缩写，直接翻译：表现层状态转移。
字面意思理解起来比较困难，网上流传的比较通俗的说法是：URL定位资源，用HTTP动词（GET，POST，DELETE，PUSH等）描述操作。
REST 实际上只是一种设计风格，它并不是标准.
使用方法，客户端只要依次“遍历”超链接，就可以完成对应的合法业务逻辑。当资源的转换规则发送变化时（如某一页由于历史文章被删除了而没有下一页，又或者某篇文章转储在了其他网站上），客户端不需要作额外的更新升级，只需要升级服务端返回的超链接即可。

Restful可以通过一套统一的接口为PC、微信(H5)、IOS和Android提供服务，这样的接口不需要前端样式，只提供数据。

  1. Resource资源，首先是弄清楚资源的概念。资源就是网络上的一个实体、一段文本、一张图片或者一首歌曲。资源总是要通过一种载体来反应它的内容。文本可以用TXT，也可以用HTML或者XML、图片可以用JPG格式或者PNG格式，JSON是现在最常用的资源表现形式。
  2. 统一接口。Restful风格的数据元操作CRUD(create,read,update,delete)分别对应HTTP方法：GET用来获取资源，POST用来新建资源(也可以用于更新资源)，PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口。
  3. HTTP状态码，在REST中都有特定的意义：200，201，202，204，400，401，403，500。比如401表示用户身份认证失败，403表示你验证身份通过了，但这个资源你不能操作。
  4. 无状态。所谓无状态即所有的资源都可以URI定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而变化。

Restful 是典型的基于HTTP的协议，HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。前面一次请求与后面一次请求没有必然的联系，所以是无状态的。

REST API版本控制

  1. 使用URI是最直接的方法，尽管它违背了URI应该引用唯一资源的原则。当版本更新时，还可以保障客户端不会受到影响，如：

     http://******.test.com/v1
 http://******v1.test.com

  2. 使用自定义请求头进行版本控制。
    自定义头(例如，Accept-version)允许您在版本之间保留uri，尽管它实际上是现有的Accept头实现的内容协商行为的副本，如:

     $.ajax({
     headers: {
     Accept-version:v1
     },
     type: "get",
     success: function (data) {
     }
 });

  3. 版本使用Accept标头
    内容协商可以让您保留一组干净的url，但是您仍然需要处理在某些地方服务不同版本内容的复杂性。这个负担通常会向上转移到您的API接口上，API接口负责确定要发送哪个版本的资源。最终结果往往是一个更复杂的API，因为客户端在请求资源之前必须知道要指定哪个头，如:

     Accept:application/ com.test.v1 + json
 Accept:application
 / json com.test + = 1.0版本

在实际开发中，API永远不会是完全稳定的。因此，如何管理这种变化很重要。

REST API方法

  1. REST 是面向资源的
    资源是通过 URI 进行暴露。URI 的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关，操作是通过 HTTP动词来体现，所以REST 通过 URI 暴露资源时，会强调不要在 URI 中出现动词。比如：左边是错误的设计，而右边是正确的。

     GET /rest/api/getDogs --> GET /rest/api/dogs 获取所有小狗狗 
 GET /rest/api/addDogs --> POST /rest/api/dogs 添加一个小狗狗 
 GET /rest/api/editDogs/:dog_id --> PUT /rest/api/dogs/:dog_id 修改一个小狗狗 
 GET /rest/api/deleteDogs/:dog_id --> DELETE /rest/api/dogs/:dog_id 删除一个小狗狗

  2. REST API 7种方法

     GET（READ）：从服务器取出资源（一项或多项）。
 POST（CREATE）：在服务器新建一个资源。
 PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
 PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
 DELETE（DELETE）：从服务器删除资源。
 HEAD：获取资源的元数据。
 OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。

  3. 常见参数

     ?limit=10：指定返回记录的数量
 ?offset=10：指定返回记录的开始位置。
 ?page=2&per_page=100：指定第几页，以及每页的记录数。
 ?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。
 ?animal_type_id=1：指定筛选条件

REST 系统的特征

  1. 客户-服务器（Client-Server），提供服务的服务器和使用服务的客户需要被隔离对待。
  2. 无状态（Stateless），来自客户的每一个请求必须包含服务器处理该请求所需的所有信息。换句话说，服务器端不能存储来自某个客户的某个请求中的信息，并在该客户的其他请求中使用。
  3. 可缓存（Cachable），服务器必须让客户知道请求是否可以被缓存。
  4. 分层系统（Layered System），服务器和客户之间的通信必须被这样标准化：允许服务器和客户之间的中间层（Ross：代理，网关等）可以代替服务器对客户的请求进行回应，而且这些对客户来说不需要特别支持。
  5. 统一接口（Uniform Interface），客户和服务器之间通信的方法必须是统一化的。（Ross：GET,POST,PUT.DELETE, etc）
  6. 支持按需代码（Code-On-Demand，可选），服务器可以提供一些代码或者脚本（Ross：Javascrpt，flash，etc）并在客户的运行环境中执行。这条准则是这些准则中唯一不必必须满足的一条。（Ross：比如客户可以在客户端下载脚本生成密码访问服务器。）

HTTP 状态码

REST的另一重要部分就是为既定好请求的类型来响应正确的状态码。如果你对HTTP状态码陌生，以下是一个简易总结。当你请求HTTP时，服务器会响应一个状态码来判断你的请求是否成功，然后客户端应如何继续。以下是四种不同层次的状态码：

2xx = Success（成功）

3xx = Redirect（重定向）

4xx = User error（客户端错误）

5xx = Server error（服务器端错误）

REST API优缺点

优点：

  1. 适合开放性高的API。这几年的由于移动互联网流行使得前端设备多样化，业界急需一种统一的机制来规范API设计，使得API适用于各种各样的前端设备，REST符合这种需求。
  2. 行为和资源分离，更容易理解。
  3. 提出使用版本号（例如v1、v2），更加规范。

 

缺点：

  1. 对后端开发人员要求高，业务逻辑有时难以被抽象为资源的增删改查。
  2. 对前端开发人员不友好，API粒度较粗，难以查询符合特殊要求的数据，同样的业务要比普通的API需要更多次HTTP请求。
最后修改：2019 年 11 月 15 日
© 允许规范转载
如果觉得我的文章对你有用，请随意赞赏