状态码4.18

状态码Status Code：

200 ：请求成功

201：添加资源成功

204：删除资源成功

301：永久重定向

302：临时重定向

400 ：客户端请求错误

出现400的 一般只会存在2种错误（这个是测试的问题）：

1、请求头不对---在Headers 中找问题

2、请求参数不对---在Body中找问题

401：无权访问该系统

403：有权限但是禁止访问

403和401问题的解决方案：

这个一般是授权问题：

常用的几种认证授权：

1、基本basic

2、常规digest

3、自定义

4、oauth2.0(微信)

操作步骤：

 

 这个授权认证了就会在Headers中出现相对应的数据

 

 

404：请求的资源不存在

这个重点查下链接

405：不被允许的请求方法

1、请求方法错误

2、如果有这个请求方法，则找运维问下是否增加了安全体系，如果增加了，并且这个ip

地址增加到白名单里面

500：服务器内部错误--这个完全可以找程序员

504：网关超时--这个不一定是程序员代码的问题，也可能是第三方的问题。

网关的优点：

1、统一的API访问入口

2、监控API的流量

415：只有请求头不对

 

 这个表示的就是需要认证授权

请求头：

常用的请求头是：

cookie：反爬虫，认证授权

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

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

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

以上4是并且的关系 缺一不可

响应头：

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

数据格式一般有3种

JSON XML HTML 

 

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

HTTP:是一个无状态的协议，所以也就导致cookie技术的发展，通过cookie能够几下用户操作的行为状态，但是cookie它是存储在客户端的，所以就不安全，为了解决安全问题。后

面移动 互联网诞生，就有了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是一个随机的字符串

持久化：把某些特定的信息存储下来（临时/永久）