程序来自于生活，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），请求参数，响应数据。

 

　　前三个都带着“请求”两个字，是请求时的相关信息，都在请求报文里。

 

　　最后一个“响应数据”，是在响应报文里。

 

　　你是怎么给女朋友送礼物的？

 

　　哈哈，一直送礼物，给了就行么。

 

　　亲，这样不行，得说点情话。

 

　　剖析一下你给女朋是怎么送礼物的？

 

　　其实，你给女朋友送礼物包含了很多信息？

 

　　比如：什么类型的礼物，礼物用的什么包装盒，礼物有多重，这个礼物是从哪个店里买的，这个礼物是通过什么交通工具（步行，骑自行车，开车还是？），

 

　　顺便再暗示一下对方，如果要送给你礼物，最好送什么类型的（哈哈，来而不往非礼也）

 

　　生活中的交互（交往，交流）有很多，如：约会，请吃饭了，买衣服，打车，学习，……………… 等等都包含了很多信息，只是我们熟“视”无睹而已。而，现在你 要搞清楚技术，就得细品“生活”