接口测试基础【二】（http协议知识，状态码，请求头，响应头，restful接口风格）

文章目录

• 前言
• 一、https加密
• 二、http常见的请求头
• 三、http常见的响应头
• 四、http响应状态码
• 五、http协议和restful风格设计接口
• restful风格的api设计
• 接口测试初步
• 总结

---

前言

记录https概念，请求头，响应头的含义，响应状态码，restful接口风格

---

一、https加密

（一）概念

1、HTTPS=HTTP+加密+认证+完整性保护

2、概念理解：CA(Certificate Authority)证书授权中心

1）CA证书授权中心

2）作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任

3）CA中心会给每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥

4）CA机构的数字签名使得攻击者不能伪造和篡改证书

（二）请求过程

1、【浏览器】向服务器发送https请求

2、【服务器】向CA机构获取证书

3、【服务器】向浏览器发送数字证书(包含public key)

4、【浏览器】用预置的CA列表验证证书，生成随机对称秘钥【key】，并使用公钥加密，如有问题会提示风险

5、【浏览器】加密后的【key】，发送给【服务器】,作为接下来请求的秘钥

6、【服务器】用自己的private key解密得到对称秘钥key

7、【浏览器】使用随机码key进行解密数据

8、【浏览器】【服务器】使用该秘钥进行通信

（三）http和https的区别

1、http明文传输，https密文传输协议

2、默认端口http：80端口，https：443端口

3、https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用

4、http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全

二、http常见的请求头

1、Accept：`*/*`
作用：用来告知（服务器）客户端可以处理的内容类型
服务器可以从诸多备选项中选择一项进行应用，并使用 [`Content-Type`](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Content-Type) 应答头通知客户端它的选择

2、Accept-Encoding：
作用：告知服务端客户端支持的编码格式，通常是某种压缩算法
服务端会选择一个客户端支持的方式，使用并在响应头 [`Content-Encoding`](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Content-Encoding) 中通知客户端该选择

3、Accept-Language：zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
作用：告知服务端，客户端可以理解自然语言，或者方言
服务器可以从中选择一项进行应用， 并使用 [`Content-Language`](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Content-Language) 响应头通知客户端它的选择

4、Access-Control-Request-Headers：content-type,token
作用：告知服务端，真正请求过程中被使用的请求头有哪些

5、Access-Control-Request-Method：Post
作用：告知服务端在真正的请求采用的请求方法
因为预检请求所使用的方法总是 OPTIONS，与实际请求所使用的方法不一样，所以这个请求头是必要的

6、Cache-Control：no-cache
作用：请求头里的Cache-Control是no-cache，是浏览器通知服务器：本地没有缓存数据
响应头中的 Cache-Control:max-age=259200 是通知浏览器：259200 秒之内别来烦我，自己从缓冲区中刷新

7、Connection：keep-alive
作用：决定当前的事务完成后，是否会关闭网络连接
keep-alive，持久连接，不会关闭
close，关闭，表明客户端或服务器想要关闭该网络连接，这是HTTP/1.0请求的默认值

8、Host：openapiv5.ketangpai.com
作用：指明了请求将要发送到的服务器主机名和端口号
如果没有包含端口号，会自动使用被请求服务的默认端口（比如HTTPS URL使用443端口，HTTP URL使用80端口）

9、Origin：https://www.ketangpai.com
指示了请求来自于哪个站点。该字段仅指示服务器名称，并不包含任何路径信息

10、Pragma：no-cache
作用：HTTP/1.1(Cache-Control 是否有缓存)，兼容HTTP/1.0（Pragma）的字段
是一个在 HTTP/1.0 中规定的通用首部，它用来向后兼容只支持 HTTP/1.0 协议的缓存服务器，那时候 HTTP/1.1 协议中的 Cache-Control 还没有出来

11、Referer：https://www.ketangpai.com/
作用：告诉服务端当前请求页面的来源页面的地址，表示当前页面是通过此来源页面里的链接进入的
服务端一般使用 `Referer` 请求头识别访问来源，可能会以此进行统计分析、日志记录以及缓存优化等

12、User-Agent：Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:87.0) Gecko/20100101 Firefox/87.0
作用：让服务端来识别发起请求的用户代理软件的应用类型、操作系统、软件开发商以及版本号

三、http常见的响应头

（一）Access-Control-Allow-Credentials：True
作用：表示是否可以将对请求的响应暴露给页面。返回true则可以，其他值均不可以

（二）Access-Control-Allow-Headers：
作用：服务端允许在正式请求的Request-Headers 请求头字段名称
Origin,token,Authorization,X-Requested-With,Content-Type,Accept,OPTIONS,POST,GET,PUT,DELETE

（三）Access-Control-Allow-Origin
作用：指定了该响应的资源允许被哪些服务访问
Access-Control-Allow-Origin：* ，如需允许所有资源都可以访问你的资源

（四）Access-Control-Allow-Origin: https://developer.mozilla.org
作用：允许该org共享资源

（五）Cache-Control：no-cache表示客户端不缓存

1、作用：指定请求和响应遵循的缓存机制

2、no-cache：指示请求或响应消息不能缓存，实际上是可以存储在本地缓存区中的，只是在与原始服务器进行新鲜度验证之前，缓存不能将其提供给客户端使用

3、no-store：缓存应该尽快从存储器中删除文档的所有痕迹，因为其中可能会包含敏感信息

4、max-age：缓存无法返回缓存时间长于max-age规定秒的文档，若不超规定秒浏览器将不会发送对应的请求到服务器，数据由缓存直接返回；超过这一时间段才进一步由服务器决定是返回新数据还是仍由缓存提供。若同时还发送了max-stale指令，则使用期可能会超过其过期时间

5、min-fresh：至少在未来规定秒内文档要保持新鲜，接受其新鲜生命期大于其当前 Age 跟 min-fresh 值之和的缓存对象

6、max-stale：指示客户端可以接收过期响应消息，如果指定max-stale消息的值，那么客户端可以接收过期但在指定值之内的响应消息

7、only-if-cached：只有当缓存中有副本存在时，客户端才会获得一份副本

8、Public：指示响应可被任何缓存区缓存，可以用缓存内容回应任何用户

9、Private：指示对于单个用户的整个或部分响应消息，不能被共享缓存处理，只能用缓存内容回应先前请求该内容的那个用户

（六）Connection：keep-alive

作用：告诉客户端当前的事务完成后，是否会关闭网络连接
keep-alive，持久连接，不会关闭
close，关闭，表明客户端或服务器想要关闭该网络连接，这是HTTP/1.0请求的默认值

（七）Content-Encoding：gzip
作用：表示响应的消息主体进行了何种方式的内容编码转换
告知客户端需要通过对应方式的解码才能获取响应主体内容

（八）Content-Type：text/html; charset=UTF-8
作用：告诉客户端实际返回的内容的内容类型

（九）Date：Fri, 16 Apr 2021 11:53:53 GMT
作用：报文创建的日期和时间

（十）Expires：
作用：返回响应到期时间

（十一）Pragma：
作用：与Cache-Control作用相同

（十二）Server：nginx
服务器所用到的软件相关信息

（十三）Set-Cookie：
作用：告诉浏览器设置当前cookie，浏览器就会自动在请求当前面所在域名设置cookie字符串，
当再次发送请求时，浏览器默认会自动将cookie中的字符串放在请求头的Cookie字段中发送给web服务器，
注意是web服务器，常用的web服务器nginx。

（十四）Transfer-Encoding：chunked
作用：数据安全传递给用户所采用的编码形式
identity：用于指代自身（例如：未经过压缩和修改）
gzip：表示采用 [Lempel-Ziv coding](http://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) (LZ77) 压缩算法
chunked：数据以一系列分块的形式进行发送
deflate：采用 [zlib](http://en.wikipedia.org/wiki/Zlib) 结构 (在 [RFC 1950](http://tools.ietf.org/html/rfc1950) 中规定)，和 [*deflate*](http://en.wikipedia.org/wiki/DEFLATE) 压缩算法(在 [RFC 1951](http://tools.ietf.org/html/rfc1952) 中规定)
- compress：（专利问题已经被弃用）采用 [Lempel-Ziv-Welch](http://en.wikipedia.org/wiki/LZW) (LZW) 压缩算法，来源于UNIX系统的 *compress* 程序

（十五）Vary：Accept-Encoding
1、博客：https://blog.csdn.net/qq_29405933/article/details/84315254
2、作用：Vary字段是由服务器端添加，添加到响应头部。大部分情况下是用在客户端缓存机制或者是缓存服务器在做缓存操作的时候，会使用到Vary头，会读取响应头中的Vary的内容，进行一些缓存的判断
3、Vary来源：Vary存在于响应头中，它的内容来自于请求头中相关字段，Vary头的内容如果是多条则用“,”分割
4、Vary解决什么问题
   4.1、对于服务端提供的某个接口，因请求的客户端不同，客户端能解析的数据编码格式和内容都不一样，这就需要服务器端做不同的数据返回
   4.2、所以服务端在需要知道不同客户端需要返回的编码格式和数据内容，因此解决方案就出来，用Accept-Encoding、User-Agent等头部
   4.3、Accept-Encoding表示客户端支持的编码格式，所以服务端就能正确返回对应编码格式的数据
   4.4、User-Agent表示客户端代理，使得服务器能够识别客户使用的操作系统及版本，所以服务端就能正确返回对应编码格式的数据
   4.5、看似问题解决了，但是我们都知道服务器要想快速响应，最快的方式就是使用缓存数据，因此当使用缓存的时候就会出问题，因为服务端并不知道什么时候更新缓存，所以Vary就应运而生了

5、Vary缓存判断过程
   5.1、某个接口首次请求时，缓存服务器会将某接口的首次请求结果缓存下来（包括响应头中的Vary）
   5.2、后面在发生相同请求的时候缓存服务器会拿着缓存的Vary来进行判断，比如Vary: Accept-Encoding,User-Agent，那么Accept-Encoding与User-Agent两个请求头的内容，就会作为判断是否返回缓存数据的依据
   5.3、当缓存服务器中相同请求的缓存数据的编码格式、代理服务与当前请求的编码格式、代理服务一致，那就返回缓存数据，否则就会从服务器重新获取新的数据
   5.4、当缓存服务器中已经缓存了该条请求，那么某次服务器端的响应头中如果Vary的值改变，则Vary会更新到该请求的缓存中去，下次请求会对比新的Vary内容

6、总结
   6.1、Vary是作为响应头由服务器端返回数据时添加的头部信息
   6.2、Vary头的内容来自于当前请求的Request头部Key，比如Accept-Encoding、User-Agent等
   6.3、缓存服务器进行某接口的网络请求结果数据缓存时，会将Vary一起缓存
   6.4、HTTP请求，缓存中Vary的内容会作为当前缓存数据是否可以作为请求结果返回给客户端的判断依据
   6.5、HTTP请求，响应数据中的Vary用来判断当前缓存中同请求的数据的Vary是否失效，如果缓存中的Vary与服务器刚拿到的Vary不一致，则可以进行更新
   6.6、当Vary的值为“\*”，意味着请求头中的所有信息都不可作为是否从缓存服务器拿数据的判断依据

（十六）X-Powered-By: PHP/7.0.33
服务端PHP版本

四、http响应状态码

（一）1xxx：服务器已收到请求，需要客户端继续操作
1、100：【Continue】继续。客户端应继续其请求
2、101：【Switching Protocols】切换协议，服务端根据客户端请求切换到更高级的协议

（二）2xxx：HTTP成功状态码
1、200：【ok】请求已成功，一般用于POST，GET请求
2、201：【Created】已创建。成功请求并创建了新的资源
3、202：【Accepted】已接受。已经接受请求，但未处理完成
4、204：【No Content】无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
5、206：【Partial Content】部分内容。服务器成功处理了部分GET请求，下载资源

（三）3xxx：重定向
1、301：【Moved Permanently】请求的资源已被永久的移动到新URI，返回替代该资源的新的URI，浏览器会自动定向到新URI。  后续对该资源的请求都应使用新的URI代替
2、302：【Found】临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
3、303：【See Other】查看其它地址。与301类似。使用GET和POST请求查看
4、304：【Not Modified】未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
5、305：【Use Proxy】使用代理。所请求的资源必须通过代理访问
6、307：【Temporary Redirect】临时重定向。与302类似。使用GET请求重定向

（四）4xxx：客户端错误
1、401：【Unauthorized】，请求要求用户的身份认证
2、402：【Payment Required】，保留，将来使用
3、403：【Forbidden】服务器理解请求客户端的请求，但是拒绝执行此请求
4、404：【Not Found】服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"页面
5、407：【Proxy Authentication Required】请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
6、408：【Request Time-out】服务器等待客户端发送的请求时间过长，超时

（五）5xxx：服务端错误
1、500：【Internal Server Error】服务器内部错误，无法完成请求
2、501：【Not Implemented】服务器不支持请求的功能，无法完成请求
3、502：【Bad Gateway】作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
4、503：【Service Unavailable】由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
5、504：【Gateway Time-out】充当网关或代理的服务器，未及时从远端服务器获取请求
6、505：【HTTP Version not supported】服务器不支持请求的HTTP协议的版本，无法完成处理

五、http协议和restful风格设计接口

（一）定义
1、HTTP协议(超文本传输协议HyperText Transfer Protocol)
2、用于从万维网服务器传输超文本到本地浏览器的传送协议
3、它是基于TCP协议的应用层传输协议，简单来说就是客户端和服务端进行数据传输的一种规则
4、HTTP协议是基于TCP的应用层协议，它不关心数据传输的细节，主要是用来规定客户端和服务端的数据传输格式，最初是用来向客户端传输HTML页面的内容。默认端口是80
5、http是基于请求与响应模式的、无状态的、应用层的协议
6、理解：TCP好比高速公路，HTTP协议就是高速公路上跑的货车，HTTP（货车）它并不在乎这些货具体是哪个用户的，它只关心这些货物的打包方式，是否按照约定的方式进行打包运输的

（二）常见请求类型【完成】
1、get 查看资源
2、post 增加资源
3、put 修改资源，需要提交全部字段，未提交的字段会被删除
4、patch 修改资源,局部更新
   {'name':'jack','age':'20','sex':'man'},只更新某一个字段使用
5、delete 删除资源
6、head 查看响应头
7、options 查看可用请求方法
8、trace：返回服务器收到的请求，用于查看请求数据，主要用于测试或诊断
9、connect：HTTP/1.1协议中预留方法，这个方法的作用就是把服务器作为跳板，让服务器代替用户去访问其它网页，之后把数据原原本本的返回给用户

restful风格的api设计

1、如果接触过 http 协议，那么肯定听过一个名词“RESTFul ”。RESTFul 是目前最流行的 API 架构风格，用于 Web 数据接口的设计

一、什么是 RESTFul 

2.1、RESTFul 的核心思想： 请求方式 + URL 的方式对资源发起命令

2.2、采用这种约定之后，每个动作对应不同的请求方式，但是 URL 不会发生变化。对于接口的维护和测试都是非常方便的
比如：GET /user 这个命令中，GET 查询动作，user  是被查询的对象
比如：POST /user 这个命令中，POST 新增动作，user  是被新增的对象

二、RESTFul 和其他接口设计的区别

1、传统接口设计方式
    GET/POST /getAllUsers               查询所有的用户
    GET/POST /getUserById?id=1       查询id=1用户
    POST      /createUser             创建用户
    GET/POST /deleteByUserId?id=1    删除id=1用户

2、RESTFul
    GET    /user        查询所有的用户
    GET    /user/1        查询id=1用户
    GET    /user?id=1     查询id=1用户
    POST   /user          创建用户
    DELETE /user/1      删除id=1用户
    DELETE /user?id=1   删除id=1用户

3、结论通过上面对比你会发现，RESTFul 类型的接口更加简单轻量，需要记忆的东西也变少了，这就是 RESTFul 魅力所在

4、状态码

4.1、http 状态码是一个三位数，范围 100-599，以第一位数分类
4.2、在 RESTFul 接口设计中 1XX 和 3XX 基本用不到，4XX 和 5XX 还是和普通接口一样，出现了什么错误做出对应提示即可。
       只有 2XX 会有一些改变，传统接口成功之后我们都会统一返回 200 不做区分，而 RESTFul 对于不同的请求方式会返回不同的状态码

5、响应报文类型
   RESTFul 接口返回的响应报文一般是 JSON 或者 XML，由 `Content-Type` 这个实体头字段指定，不应该返回纯文本。JSON 也是目前最常用的一种传输格式

接口测试初步

接口测试-功能测试：

1、接口文档(缺少、不全面、不维护) -- swagger
2、抓包工具 - F12, fiddler/charles/wireshark/burpsuite
3、设计接口测试用例
   接口测试工具/平台 - jmeter、postman、rf、postwoman、fastapi、apipost、yapi、metersphere
4、数据库操作 - 校验数据
5、项目架构 - 技术、微服务、数据库

客户端                 服务端
发请求者               接收请求并响应
pc浏览器               https://www.ketangpai.com/
app小程序/应用          项目测试环境地址
postman 

网络传输： 请求数据     响应数据
服务端提供的服务：考勤、考勤数据查询、学员展示、作业发布、作业提交、作业批阅、文件上传.....

前后端分离： 前端页面(用户交互UI - 前端开发-页面样式/后端交互/表单数据校验)、后端逻辑实现(业务逻辑+数据库交互)
           数据传递 === 接口实现(后端定义)
           每一个接口 - 功能、接口地址

接口：
    1、开发实现的 - 设计一个功能有多少个接口、每个接口的功能是什么(地址/发哪些数据)、对数据库中的表有什么影响、
    2、接口 == 传递数据的通道。
    3、接口类型：系统内部接口(前端后端交互)、外部接口(系统与其它系统的交互接口 - 微服务/第三方支付接口/上下游系统)
    4、接口通信协议：http/https(接口设计风格restful)、webservice、dubbo
    5、接口数据格式：json格式、xml格式、text

接口测试：
    测试接口传递的数据 -- 正常场景、异常场景。
UI界面点点点： UI点点点操作，调用多个接口去进行数据传递和处理，比UI底层

自动化测试：优先接口自动化测试

http/https: 
    通信过程：
    1、建立连接 - 客户端与服务端建立连接(拨号并确保对方能接通)
    2、发送请求数据(你说话)-请求数据包
    3、服务端接收请求数据，并响应数据。(听到之后再回复你)-响应数据包
    4、关闭连接。(挂电话)
    
    数据包：请求数据包、响应数据包
    请求数据包：请求行、请求头(header)、请求体(body)
    请求行：请求目标地址(接口地址)、请求方法(get\post)
    请求头：content-type(除get以外的请求方法都需要关注)、Content-Length、user-agent
    请求体：get请求是没有的。post/put/delete..
    get请求：请求参数是拼接在接口url的后面： 接口地址?key=value&key=value
    post请求：请求体的。
         
    响应数据包：响应行、响应头、响应体
    响应行：响应状态码?有哪些状态码
    响应头
    响应体
    
    经典面试题：get和post的区别

cookie鉴权、token鉴权、加密鉴权

cookies: 登陆接口的响应头里面，set-cookies

面试题：token,session,cookies的区别？？

https的加密过程 - 非对称加密和对称加密的应用

tcp通信 - 三次握手，四次挥次

tcp/udp - 可靠的
https://www.cnblogs.com/fundebug/p/differences-of-tcp-and-udp.html

---

总结

暂无