文章目录

• 1）REST（Representational State Transfer）
• • 1、表现层（Representation）
  • • 资源（Resources）
  • 2、状态转化（State Transfer）
• 2）RESTful API 设计
• • *为什么需要API架构？
  • 2.1 URL设计
  • • 1、数据的安全保障（协议）：
    • 2、接口特征表现（域名）：
    • 3、多数据版本共存（版本）：
    • 4、数据即是资源（路径）：
    • 5、资源操作由请求方式决定（HTTP动词）：
    • • 常用的HTTP动词有下面五个（括号里是对应的SQL命令）：
    • 5、过滤信息
  • 2.2 响应状态码
  • • 正常响应（响应状态码2xx）：
    • 重定向响应（响应状态码3xx）：
    • 客户端异常（响应状态码4xx）：
    • 服务器异常（响应状态码5xx）：
  • 2.3 响应结果

---

接口测试的流程主要为：

• 第一步： 分析出测试需求，并拿到开发提供的接口说明文档。
• 第二步： 从接口说明文档中整理出接口测试案例，里面要包括详细的入参和出参数据以及明确的格式和检查点。
• 第三步： 和开发一起对接口测试案例进行评审。
• 第四步： 结合开发库，准备接口测试案例中的入参和出参数据，并整理成csv格式的文件。
• 第五步： 结合接口测试案例文档和csv格式的数据文档，做接口测试案例的自动化案例开发。

RESTful作为目前最流行的API设计规范，测试人员需要对其有一定了解。

1）REST（Representational State Transfer）

互联网软件采用客户端/服务器模式，建立在分布式体系上，通过互联网通信，具有高延时（high latency）、高并发等特点。

• 网站开发，完全可以采用软件开发的模式。但是传统上，软件和网络是两个不同的领域，很少有交集。
• 软件开发主要针对单机环境，网络则主要研究系统之间的通信。
  
  

互联网的兴起，使得这两个领域开始融合，现在我们必须考虑，如何开发在互联网环境中使用的软件。

2000年Roy Fielding博士在其博士论文中提出REST(Representational State Transfer)风格的软件架构模式后，REST就基本上迅速取代了复杂而笨重的SOAP，成为Web API的标准了。

REST即Representational State Transfer，可翻译成"表现层状态转化"，指的是一组架构约束条件和原则。

• 如果一个架构符合REST原则，就称它为RESTful架构。

• RESTful架构是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。

1、表现层（Representation）

把"资源"具体呈现出来的形式，就是它的"表现层"（Representation）。

• 比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式。
• 图片可以用JPG格式表现，也可以用PNG格式表现。

• 资源（Resources）

  所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。
  • 可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。
  • 所谓"上网"，就是与互联网上一系列的"资源"互动，调用它的URI。

2、状态转化（State Transfer）

访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。

• 由于互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。

客户端用到的手段，只能是HTTP协议：

• 具体来说，就是HTTP协议里面四个表示操作方式的动词：GET、POST、PUT、DELETE。
• 它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

---

2）RESTful API 设计

RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。

*为什么需要API架构？

网络应用程序，分为前端和后端两个部分。当前的发展趋势，就是前端设备层出不穷（手机、平板、桌面电脑、其他专用设备…）。因此，必须有一种统一的机制，方便不同的前端设备与后端进行通信。这导致API构架的流行，甚至出现"API First"的设计思想。

2.1 URL设计

1、数据的安全保障（协议）：

• API与用户的通信协议，总是使用HTTPs协议。
• 采用https协议，可以提高数据交互过程中的安全性。

2、接口特征表现（域名）：

• 用api关键字标识接口url，看到api字眼就代表该请求url链接是完成前后台数据交互的。
  • 应该尽量将API部署在专用域名之下：https://api.example.com
  • 如果确定API很简单，不会有进一步扩展，可以考虑放在主域名下：https://example.org/api/

3、多数据版本共存（版本）：

• 在url链接中标识数据版本：
  • https://api.xxxx.com/v1
  • https://api.xxxx.com/v2
  • url链接中的v1、v2就是不用数据版本的体现(只有在一种数据资源有多版本情况下)。

4、数据即是资源（路径）：

• 接口一般都是完成前后台数据的交互，交互的数据我们称之为资源。
  • 一般来说，数据库中的表都是同种记录的"集合"（collection），所以API中的名词也应该使用复数。
    • https://api.xxxx.com/users
    • https://api.xxxx.com/books
  • 在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。
  • 特殊的接口可以出现动词，因为这些接口一般没有一个明确的资源，或动词就是接口的核心内容：
    • https://api.xxxx.com/login
    • https://api.xxxx.com/resgister

5、资源操作由请求方式决定（HTTP动词）：

• 操作资源一般都会涉及到增删改查，对于资源的具体操作类型，由HTTP动词表示。

常用的HTTP动词有下面五个（括号里是对应的SQL命令）：

• GET（SELECT）：从服务器取出资源（一项或多项）。
  • https://api.xxxx.com/books - get请求：获取所有书
  • https://api.xxxx.com/books/1 - get请求：获取主键为1的书
• POST（CREATE）：在服务器新建一个资源。
  • https://api.xxxx.com/books - post请求：新增一本书
• PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
  • https://api.xxxx.com/books/1 - put请求：整体修改主键为1的书
• PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
  • https://api.xxxx.com/books/1 - pathc请求：局部修改主键为1的书
• DELETE（DELETE）：从服务器删除资源。
  - https://api.xxxx.com/books/1 - delete请求：删除主键为1的书
  
  

还有两个不常用的HTTP动词：

• HEAD：获取资源的元数据。
• OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。

5、过滤信息

• 如果记录数量很多，服务器不可能都将它们返回给用户。API应该提供参数，过滤返回结果。常见的参数：
  • ?limit=10：指定返回记录的数量
  • ?offset=10：指定返回记录的开始位置。
  • ?page=2&per_page=100：指定第几页，以及每页的记录数。
  • ?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。
  • ?animal_type_id=1：指定筛选条件。
• 参数的设计允许存在冗余，即允许API路径和URL参数偶尔有重复。比如，GET /zoo/ID/animals 与 GET /animals?zoo_id=ID 的含义是相同的。

2.2 响应状态码

• 正常响应（响应状态码2xx）：

  • 200：常规请求
  • 201：创建成功
    
    

• 重定向响应（响应状态码3xx）：

  • 301：永久重定向
  • 302：临时重定向
    
    

• 客户端异常（响应状态码4xx）：

  • 403：请求无权限
  • 404：请求路径不存在
  • 405：请求方法不存在
    
    

• 服务器异常（响应状态码5xx）：

  • 500：服务器异常

详细可见：https://www.ruanyifeng.com/blog/2014/05/restful_api.html

2.3 响应结果

• 响应数据要有状态码、状态信息以及数据本身。

  {
      "status": 0,
      "msg": "ok",
      "results": [
          {
              "name": "百年孤独",
              "price": 33.60,
          },
          ...
      ]
  }
  

• 需要url请求的资源。

  {
      "status": 0,
      "msg": "ok",
      "results": [
          {
              "name": "百年孤独",
              "price": 33.60,
              "img": "https://image.xxxx.com/bngd.png"
          },
          ...
      ]
  }
  

• 针对不同操作，服务器向用户返回的结果应该符合以下规范：

  • GET /collection：返回资源对象的列表（数组）
  • GET /collection/resource：返回单个资源对象
  • POST /collection：返回新生成的资源对象
  • PUT /collection/resource：返回完整的资源对象
  • PATCH /collection/resource：返回完整的资源对象
  • DELETE /collection/resource：返回一个空文档

---

【部分内容参考自】

• 什么是接口测试？为什么要做接口测试？：https://www.cnblogs.com/zoraliu66/p/6743126.html
• 理解RESTful架构：http://www.ruanyifeng.com/blog/2011/09/restful.html
• RESTful API 设计指南：https://www.ruanyifeng.com/blog/2014/05/restful_api.html
• Restful 接口规范：https://www.cnblogs.com/17vv/p/11890532.html