程序来自于生活，web应用中的B端和S端的交互与人的交互是一模一样的。
只是，比生活中的稍微多了一丢丢（因为，计算机没有眼睛，没法看到。所以，把人能够看到的东西也得说清楚）。
B-----》S： 发送请求时，B端需要给S端说清楚我发的是什么，我用什么发的，发的方式是什么，你给我响应时，需要响应啥类型等等（这就是我下一个主题要说的请求报文）。
S-----》B：响应时，S端也要告诉B端 我给你发的是什么，发的什么类型，什么时间，服务器用的什么软件，响应的状态码，协议的版本等等（这就是我下一个主题要说的响应报文）。
请求报文和响应报文
报文是什么？
好吓人呢。此报文不是彼豹纹
报文一词来自于，以前电报中的用语
可以理解为，报告的文档、文字；上报的文档、文字。即：信息交换两方的信息内容。相当于两个人说话的内容。比如：你给你女朋友打电话说"我想你了”。你给你女朋友传递的信息就是“我想你了”，也就是你发给你女朋友的报文。然后，你女朋友给你说 “其实，我也想你了，就等你的电话呢……”，这是你女朋友发给你（响应给你的）的报文。
web开发中，B端发给S端的报文叫作请求报文，S端发给B端的报文叫作响应报文。
请求报文：
请求报文的内容包括三部分，分别是： 请求行，请求头，请求体。这三部分放的都是信息。
1、请求行
请求行包括：前端请求时的请求方法（method），请求路径（URL）, 请求时所使用的的http协议的版本
2、请求头
有若干键值对，一般属于附属信息（什么是附属信息？哈哈，很吓人，其实就是汉语中的修饰相关的词语（如：定语，状语，补语））
常见的默认会有哪些？
Accept：告诉S端，我B端可以接受的（响应）内容类型，如： text/plain ，表示我只能接受文本，你发图片我不认识。Accept是可以接受多个类型，如：text/html; image/webp
Accept-Language：告诉S端，我B端可以接受（认识）的语言，如： zh-CN，表示中文
Accept-Encoding : 告诉S端，我B端可以接受的编码类型 ，如： gzip
Cache-Control : 缓存控制，如： no-cache；表示客户端不缓存此次响应的内容。
Cookie: 请求时携带的cookie。这里面除了本地cookie保存的数据外，一般还会有sessionId。
Referer： 表示这个请求是从哪个URL过来的 。
content-type: B端发给S端的数据类型描述，如：application/json
………………………………
也可以自定义键值对。
如，用axios发送请求时，B端要给S端传递token；就可以在请求拦截器中这样写：
// 请求拦截器
axios.interceptors.request.use(config=>{
// 请求前可以做的事情(这一般都是通用的信息)
// 如： 身份验证信息的携带（如：token）
let token = localStorage.getItem(“token”);
if(token){
config.headers.authorization=token;
}
return config;
});
以上代码中：config.headers.authorization=token;
headers，就表示把数据放在请求头里。
authorization：是自定义的键
token：就是传给后端的值
3、请求体
请求体里是前端给后端发送的数据，一般特指，用post方式（非get方式）发送的数据。
是键值对连接起来的字符串： username=张三疯&pass=123
另：关于前端发送给后端的数据，get方式是在url进行携带；post方式是在请求体里携带。
另：用汉语的语法解释请求头，请求体的关系。
请求体是主体，是请求时传给后端的主体信息。请求头是附属信息。
对比汉语。请求体就是宾语。请求头是修饰词（如：定语，状语，补语）。
举个栗子：
“我今天去火车站接女朋友”，这句话核心表达的意思（经过缩句）：我接女朋友。
请求体：女朋友
请求头有：时间：今天；地点：火车站；
响应报文：
响应报文的内容也包括三部分，分别是： 响应 行， 响应 头， 响应 体。这三部分放的都是信息。是S端发给B端的信息，道理是一样的。
1、响应行
响应行包括：HTTP协议的版本，响应的状态码和描述。
如： HTTP/1.1 200 OK 表示响应时使用的是http协议的1.1版本；响应的状态码是200；描述是OK。
响应状态码
和请求报文相比，响应报文多了一个“响应状态码”，它以“清晰明确”的语言告诉客户端本次请求的处理结果。
HTTP的响应状态码包括：
1xx 消息，一般是告诉客户端，请求已经收到了，正在处理，别急…
2xx 处理成功，一般表示：请求收悉、我明白你要的、请求已受理、已经处理完成等信息.
3xx 重定向到其它地方。它让客户端再发起一个请求以完成整个处理。
4xx 处理发生错误，责任在客户端，如：客户端的请求一个不存在的资源（地址不对，请求方式不对，Content-type不匹配等等），客户端未被授权，禁止访问等。
5xx 处理发生错误，责任在服务端，如：服务端抛出异常，路由出错，HTTP版本不支持等。
2、响应头
HTTP响应头往往和状态码是结合起来的。
常见的响应头包括：
Content-Length：表示内容长度。
Content- Type：表示后面的文档属于什么MIME类型。如：text/html、application/json;
Date：表示响应内容的时间（GMT格式）。
Expires：告诉浏览器把响应的资源缓存多长时间，-1或0则是不缓存。
Set-Cookie： 设置和页面关联的Cookie，即：服务端设置客户端的Cookie，其原理就是通过这个响应报文头属性实现的
Cache-Control ：缓存控制，如： no-cache；告诉客户端该内容不做缓存。
ETag: 一个代表响应服务端资源（如页面）版本的报文头属性，如果某个服务端资源发生变化了，这个ETag就会相应发生变化。它是Cache-Control的有益补充，可以让客户端“更智能”地处理什么时候要从服务端取资源，什么时候可以直接从缓存中返回响应
3、响应体
这个是服务器响应给客户端的数据，如：
[
{userid: “01001”, username: “马梅玲”},
{userid: “01002”, username: “冯一凡”},
{userid: “01003”, username: “姬佩霞”},
{userid: “01004”, username: “李晨兴”}
]
接口文档的信息，体现在报文里的何处？
用我们常见的接口文档来解释：
一般来说，接口文档里的信息至少包括：请求地址（URL），请求方式（method），请求参数，响应数据。
1.前三个都带着“请求”两个字，是请求时的相关信息，都在请求报文里。
2.最后一个“响应数据”，是在响应报文里。
你是怎么给女朋友送礼物的？
哈哈，一直送礼物，给了就行么。
亲，这样不行，得说点情话。
剖析一下你给女朋是怎么送礼物的？
其实，你给女朋友送礼物包含了很多信息？
比如：什么类型的礼物，礼物用的什么包装盒，礼物有多重，这个礼物是从哪个店里买的，这个礼物是通过什么交通工具（步行，骑自行车，开车还是？），
顺便再暗示一下对方，如果要送给你礼物，最好送什么类型的（哈哈，来而不往非礼也）
生活中的交互（交往，交流）有很多，如：约会，请吃饭了，买衣服，打车，学习，……………… 等等都包含了很多信息，只是我们熟“视”无睹而已。而，现在你 要搞清楚技术，就得细品“生活”