一，接口测试
1）接口:
1）数据交互的入口和出口，是一套规范一套标准
2）高效、灵活: U盘
3）架构师设计的 (API文档)
不使用接口的缺点：
1. 研发标准不统一，团队磨合难度高（指的是前后端对同一种变量的不同定名字格式，就很难互相解读）
2. 研发周期长
3. 可扩展性差
使用时的优点：
1. 统一设计标准；
2. 前后端开发相对独立；（不用为什么命名格式问题，一直互相问）
3. 扩展性灵活；
4. 前后端都可以使用自己熟悉的技术；
2）接口测试：
概念：
接口测试就是代替前端或者第三方验证后台响应数据是否正确
接口测试原理：
模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收响应数据后并进行判断的一个过程。
请求：是否正确，默认请求成功是200（GET），如果请求错误也能返回404、500等。
检查：返回数据的正确性与完整性
安全性：接口一般不会暴露在网上任意被调用，需要做一些限制，比如次数限制。
流程：
要素1: 定位服务器资源(通过 URL 实现: http://www.baidu.com | http://127.0.0.1:8000/资源路径)
要素2: 模拟用户提交数据
要素3:查看响应的结果是否符合预期
分类：
类型1:web接口测试 （BS 架构）
| ----- 服务器接口测试:测试自己公司实现的接口
| ----- 第三方接口测试:测试别的公司实现的接口
类型2:模块接口测试 (CS 架构)
二，接口测试：插件
是测试接口的测试工具：
火狐 ------ RESTClient
谷歌 ------ POSTman
Java 实现的测试工具: Jmeter(重点)
三，RESTful 风格(重点)：
一些约定俗成的习惯：
增:
要素1: URL + POST
要素2: 多个数据
方式1: 键=值&键=值
方式2: JSON 格式
要素3: 200 | 201 + 添加的记录
删:
要素1: URL + GET|DELETE
要素2: 方式1: 键=值&键=值
要素3: 200|204 + 无
改:
要素1:URL + POST|PUT(更合适)
要素2:
方式1: 键=值&键=值
方式2: JSON 格式s
要素3:200 | 201 + 修改后那条记录
查:
要素1: URL + GET
要素2:常用方式1 URL?键=值&键=值....
要素3:200 + 一条或多条记录
RESTful风格：
http://服务器地址:端口号/[服务名]/[版本]/资源集合/单个资源
状态码:
201-----新建或修改数据成功
204------删除数据成功
404 ------ 资源路径有误
505 ------ 服务器异常
GET 和 POST 区别 ：
1、POST 安全性高
2、POST 提交的数据量没有大小限制
四，JSON
一种数据载体：
HTML 格式:
<html>
<head>
<title>hello</title>
</head>
<body>
<font color='red'> hello world </font>
</body>
</html>
xml 格式:
<person>
<name>huluwa</name>
<age>8</age>
</person>
缺点:
标签标记语言，有效数据占有率低
A-4、 JSON 优化数据传输
{"title":"hello","font":"hello world"}
{"name":"huluwa","age":"8"}
B、为什么？
JSON 传输数据效率更高，所以部分场景下使用 JSON 替换 html 和 XML_(ajax)
但是 JSON 语法描述性不及 标签语言，所以部分场景还得使用 html 和 xml
如果传递的是少量数据的话，可能使用 JSON
C、怎么用？
语法:
格式1(JSON对象):{"键1":"值1","键2":"值2".....}
格式2(JSON数组):[值1,值2,值3.....]
格式复合: {"name":"huluwa","age":"8","aihao":["救爷爷",“吐火”,"吐水"]}
[{"name":"huluwa","age":"8"},{"name":"aotuman","age":"10"}......]