接口测试3

常用状态码

当客户端向服务端发送?个请求后，服务端响应回复返回给客户端，在返回的信息中会包含?个HTTP请求头的状 态码信息?以响应客户端的请求。在?站https://http.cat中可以看?各个不同表情的状态码的显示，如调?https:/ /http.cat/504就会显示如下对应的信息。常?的状态码具体为：

• 200 请求成功

• 201 created :添加资源成功

• 204 No Content ：删除资源成功

• 301 永久重定向 （请求A的时候，会自动跳转到B）

• 302 临时重定项 （请求A的时候，会自动跳转到B临时）

所有的400，都是客户端的问题

• 400 Bad Request 客户端请求错误

  1、请求头不对 2、请求参数不对

• 401 Unauthorized ?权限访问该系统

  认证（授权）：

• 1、基本 basic

• 2、常规 digest

• 3、自定义

• 4、oauth2.0 (微信)

• 403 Forbidden 有权限但是禁?访问

• 404 请求的资源不存在

• 405 不被允许的请求?法

另一种情况：IP地址引入了安全体系加入了白名单。

• 415:只有请求头不对

• 500 服务器内部错误

• 504 GateWay Timeout 网关超时

  不一定是程序员代码的问题，也可能是第三方的问题

  API gateway（网关）

  1.统一API访问入口

  2.监控API流量

请求头

• cookie: 反爬虫 ,认证授权

• referer：请求目标地址是从哪里来的

• content-type:代表的是什么样的数据格式

• user-agent：代表的是访问目标服务器，是通过什么来访问

实际操作步骤：

打开拉勾网搜寻职位，点击下一页找到positionAjax.json

 在Postman请求头中输入相应的cookie、referer、type、user-agent

在数据参数（body）中输入相应值

响应头

content-type:返回的响应数据是什么样的数据格式

Set-cookie:服务端把生成的认证凭证信息返回给客户端

HTTP是一个无状态的协议，所以导致了COOKIE技术的发展，通过COOKIE能够记下用户操作的行为状态，但是COOKIE它是存储在客户端的，所以不安全，为了解决安全问题，SESSION诞生，SESSION它是存储在服务端，相对来说比较安全。后面移动互联网诞生，就有了TOKEN，TOKEN，本质上是SESSION原理来实现的，它成为一个令牌。TOKEN的实现技术是JWT的技术。

COOKIE请求：

特点：

1. 存储在客户端

2. 不安全

以登录为案例说明COOKIE的流程：

1. 客户端输入账户密码登陆成功

2. 在服务端生成COOKIE的信息，通过响应头中的SET-COOKIE把生成的COOKIE返回给客户端

3. 客户端在下次请求的时候，通过请求头中的cookie把返回的cookie带上发送给服务端，服务端内部进行验证

SESSION流程

1. 客户端输入账户密码登录成功

2. 在服务端会生成SESSIONID，同时存储在服务端本地，把通过响应头中的Set-cookie把生成的SESSIONID返回给客户端

3. 客户端收到SESSIONID后

4. 客户端再次请求服务端（比如访问个人主页），会在请求头的cookie中带上SESSIONID发送给服务端

5. 服务端接收到客户端发送过来的SESSIONID，与存储在服务端本地的SESSIONID之间会进行比较，如果一致，允许访问个人主页，如果不一致，就会重定向到登录页面

实际操作步骤：

打开拉勾网登录页面，登录账号获得以下数据

 进行进入“个人中心”操作，找到以下数据

TOKEN流程

1. 每次登陆成功后，生成的TOKEN都是不一样的

2. 返回的token是一个随机的字符串

持久化

把某些特定的信息存储下来(临时/永久)

实际操作步骤：

登录BOSS直聘，点击Application，在cookies菜单中，右键clear清除，跳转到登录界面。