这是我参与「第四届青训营 」笔记创作活动的第4天
01.初始HTTP
- Hyper Text Transfer Protocol
- 应用层协议，基于TCP协议
- 请求 响应
- 简单可扩展
- 无状态
02.协议分析
2.1 发展
2.2 报文
2.2.1Method：
| 方法 | 说明 |
|---|---|
| GET | 请求一个指定资源的表示形式.使用GET的请求应该只被用于获取数据. |
| POST | 用于将实体提交到指定的资源,通常导致在服务器上的状态变化或副作用 |
| PUT | 用请求有效载荷替换目标资源的所有当前表示 |
| DELETE | 删除指定的资源 |
| HEAD | 请求一个与GET请求的响应相同的响应,但没有响应体 |
| CONNECT | 建立一个到由目标资源标识的服务器的隧道。 |
| OPTIONS | 用于描述目标资源的通信选项。 |
| TRACE | 沿着到目标资源的路径执行一个消息环回测试。 |
| PATCH | 用于对资源应用部分修改。 |
safe(安全的)： 不会修改服务器数据的方法（GET HEAD OPTIONS）
Idempotent(幂等)：同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的所有safe的方法都是ldempotent的(GET HEAD OPTIONS PUT DELETE)
2.2.2状态码：
graph LR
1xx --> 提示信息表示请求已接收继续处理
graph LR
2XX --> 成功表示请求已被成功接受理解接受
graph LR
3XX --> 重定向要完成请求必须进行更进一步的操作
graph LR
4XX --> 客户端错误请求有语法错误或请求无法实现
graph LR
5XX --> 服务端错误服务器未能实现合法的请求
200 OK ----- 客户端请求成功
301 ----- 资源网页等被永久转移到其他URL
302 ------临时跳转
401 Unauthorized-----请求未经授权
404-----请求。资源不存在可能输入了错误的URL
500-----服务器内部发生了不可预期的错误
504 Gateway timeout-----网关或者代理的服务器无法在规定的时间内获得想要的响应
RESTful API:
RESTful API:一种API设计风格﹔REST - Representational State Transfer
(1)每一个URI代表—种资源;
(2）客户端和服务器之间,传递这种资源的某种表现层;
(3）客户端通过HTTP method，对服务器端资源进行操作，实现"表现层状态转化"。
常用的请求头：
| Accept | 接收类型，表示浏览器支持的MIME类型(对标服务端返回的Content-Type). |
| Content-Type | 客户端发送出去实体内容的类型 |
| Cache-Control | 指定请求和响应遵循的缓存机制，如no-cache |
| if-Modified-Since | 对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内 |
| Expires | 缓存控制,在这个时间内不会请求，直接使用缓存,服务端时间 |
| Max-age | 代表资源在本地缓存多少秒,有效时间内不会请求,而是使用缓存 |
| if-None-Match | 对应服务端的ETag，用来匹配文件内容是否改变（非常精确)。 |
| Cookie | 有cookie并且同域访问时会自动带上。 |
| Referer | 该页面的来源URL(适用于所有类型的请求，会精确到详细页面地址, csrf拦截常用到这个字段)。 |
| Oridin | 最初的请求是从哪里发起的(只会精确到端口) ,Origin比Referer更尊重隐私 |
| User-Agent | 用户客户端的一些必要信息，如UA头部等。 |
常用的响应头：
