GET和POST的区别
这就引出了一个经典的面试题
谈谈GET和POST的区别。
首先，GET和POST没有本质的区别。因为在我们HTTP方法的使用是一种混乱的状态，HTTP中有那么多方法，但大家写代码基本上就是一股脑GET/POST方法，大家没太按照规则来写。
同理，GET能干的事情、其实POST方法也能干。但是GET和POST，站在细节上是存在区别的。
区别一：
GET 的 body 一般为空, 需要传递的数据通过 query string 传递, POST 的 query string 一般为空, 需要传递的数据通过 body 传递
区别二：
语义不同: GET 一般用于获取数据, POST 一般用于提交数据
（但现在这个区别已经不明显了，GET也可以用于提交数据，POST也可以用于获取数据。）
区别三：
GET请求一般是幂等的，POST请求一般不是幂等的。
幂等：每次我们输入相同的数据，得到的输出结果是确定的（种瓜得瓜，种豆得豆）。
不幂等：每次我们输入相同的数据，得到的输入结果是不确定的——（可能种瓜得瓜、也可能种瓜得豆）
在实际开发中，我们习惯将GET设置为幂等，将POST设置为不幂等。
区别四：
GET可以被缓存、POST不可以被缓存。
缓存：就是提前把结果给记住。
如果是幂等，记住结果是很有用的，节省了下次访问的开销。
如果是不幂等的，就不应该去提前记，因为结果是不确定的，下一次访问的开销还是存在的。
注意！能不能缓存 和 幂不幂等，是有关联的。
如果你在设计 GET 的时候，没有把它设计成幂等，那么GET，也是不能缓存的。POST 也是同理。
一些补充：
关于幂等性: 标准建议 GET 实现为幂等的. 实际开发中 GET 也不必完全遵守这个规则(主流网站都有 "猜你喜欢" 功能, 会根据用户的历史行为实时更新现有的结果.
关于安全性: 有些资料上说 "POST 比 GET 请安全". 这样的说法是不科学的. 是否安全取决于前端在传输密码等敏感信息时是否进行加密, 和 GET POST 无关.
关于传输数据量: 有的资料上说 "GET 传输的数据量小, POST 传输数据量大". 这个也是不科学的, 标准没有规定 GET 的 URL 的长度, 也没有规定 POST 的 body 的长度. 传输数据量多少，完全取决于不同浏览器和不同服务器之间的实现区别.
关于传输数据类型: 有的资料上说 "GET 只能传输文本数据, POST 可以传输二进制数据". 这个也是不科学的. GET 的 query string 虽然无法直接传输二进制数据, 但是可以针对二进制数据进行 urlencode
请求报头（header）
HOST
表示服务器主机的地址和端口
Content-Length && ContentType
Content-Length:表示body中的数据长度
Content-Type:表示请求中的body中的数据格式
User-Agent(UA)
UA：用户代理，表示的是，当前用户是在拿一个什么什么样的工具在上网
虽然User-Agent 这一个键值对，我们并不能全部看懂。
但是不妨碍我们得出结论：
我们可以发现：User-Agent，总的来说，分为2部分信息：操作系统 + 浏览器 信息。
为什么要有这样一个信息呢？
其实理由也很简单：
在上古时期，就是在互联网刚开始发展的时候。
那个时候，浏览器处在一个飞速进步的状态。
最开始的浏览器，只能显示文本，【HTML】
再后来，能够显示图片了。【HTML】
再后来，能够显示各种复杂的样式了。【CSS】
再后来，能够加载 js 实现交互了。【JS】
再后来，能够支持各种多媒体了（播放视频什么的…）。
那么，问题就来了：
由于那个时期的浏览器发展很快，所以就导致市场被割裂了。
一部分用户，用的是比较老的浏览器。（只能显示文本）
一部分用户，用的是比较新的浏览器。（能够支持 js）
因此，也就给我们网站开发人员带来了很大的挑战。
在设计一个网页的时候，到底要不要给这个网页加上 JS ，或者CSS。
加了吧，有一些用户的浏览器不支持。
不加吧，有一些用户的体验不好。
【用户表示：我能用，你凭什么不给我用？】
【程序员：我开发的浏览器不支持 JS，岂不是说明我很菜？】
当时，为了解决这个问题，聪明的程序员就想到了一个办法。
让浏览器发送的请求中，包含一个数据：“自爆家门”。
就是你浏览器请求过来了，你先告诉我，你的浏览器大概能支持哪些功能。
或者说，告诉我，你的浏览器处于一个什么版本，是旧的，还是新的。
此时，服务器就可以根据浏览器中这个 “自爆家门” 的信息，就可以做出区分了。
根据你的浏览器版本，或者说根据你的浏览器所支持的功能，来返回一个你的浏览器能够支持的网页数据。
这样做，就可以满足每个用户的不同需求。
这里 User-Agent 键值对，就是在做着这样的一个“自爆家门”的工作。
浏览器发展至今，主流浏览器的功能已经差别很小了。
十年前，浏览器兼容性，还是前端开发要考虑的大问题。
兼容性：如何去兼容老的浏览器
十年后的现在，今天基本上是不用考虑了。
因为大部分用户使用的浏览器，都是比较现代的浏览器。
该有的功能，它都有。
与最新的浏览器，没有太大的区别。
也就需要关注那么问题了。
故：放到现在，UA 这个字段起到的作用就已经不那么大了。
其实，我们不告诉服务器，用的是什么浏览器。
服务器也大概知道，在这个年代，不会存在太老旧的浏览器。
所以，直接把页面发给你，你的浏览器肯定是能处理的。
但是！随着当下移动互联网的到来，UA 现在又有了新的使命。
用来区分是 PC端，还是 手机端。
当前 PC端 和 手机端，最大的区别就是 屏幕尺寸和比例。
手机端的屏幕尺寸，是远远小于 PC端的。
一般手机端的网页，就得把按钮之类的，设计的大点。
要不然，你手指点不到按钮。
屏幕比例 PC都是宽屏，手机都是窄屏，比例的不同就导致页面布局就得不同。
因此，我们的服务器就可以根据 UA 来区分 当前是 手机，还是PC。
如果是手机，就返回一个手机版的网页；如果是PC，就返回一个PC版的网页。
这两个版本的网页，它们的尺寸和布局有着很大的不同。
这样做，不管用户使用何种设备，打开一个网页，都会用的很舒服。
这就是当下 UA 的主要功能。
另外，响应式布局也能做到根据设备窗口的大小，来修改页面的样式。
响应式布局，大概就是根据当前浏览器窗口宽度自动修改样式。
这个操作，更加考验前端工程师的功底。
写一个页面，适用于两种不同的平台，确实可以做到，但是代码就会更加的复杂。
代码一复杂，写代码就容易出错。
可能更多的是，写两个页面，分别对应着 手机 和 PC 端。
User-Agent 之所以是这个样子是因为历史遗留问题. 可以参考
User-Agent 的故事: http://www.nowamagic.net/librarys/veda/detail/2576
————————————————
Referer
表示当前这个页面是从哪个页面跳转过来的
cookie
明确一点：浏览器，为了安全，默认情况下是不能让页面的 js 访问到 用户电脑上的文件系统的。
假设某个网页上，包含恶意代码。
然后，我们不小心点到的，就可能触发这个恶意代码，可能就把你电脑上的资料 全给删除了。
显然这是一件非常难受的事情！
所以浏览器为了保护 用户电脑上的 资料，就会禁止页面的 js 访问到文件系统。
就是说，页面的 js 是获取不到：当前用户电脑上的文件有哪些 ，就别提进行删除操作了。
这是浏览器为了安全而引入的机制。
但是！这样的安全限制，也带来了一些麻烦。
因为有时候，我们确实需要让页面这里持久化存储一些数据，方便后续访问网站。
举个例子：
其中，最典型的，就是序要存储 用户当前的身份信息。
总结：
Cookie 是浏览器提供的一个持久化存储数据的机制，
Cookie 的最重要的应用场景，就是存储会话ID，进一步的让访问服务器的后续页面的时候，能够带上这个 id 从而让服务器能够知道当前的用户信息。
另外，服务器上保存用户信息这样的机制，就被称为 Session（会话）、
那么，Cookie能不能用存别的信息？？
当然也是阔以的！！完全取决你怎么去设计。
大家一定要重点理解 cookie 和 session 的 工作机制。
这件事对于我们后面去实现一些，类似于登录页面，这样的功能，是非常有必要的！
那么，当然了，在讲到后面具体代码的时候，还会通过写代码的形式，让大家进一步的了解cookie 和 session 的工作过程。
当下，咱们就只需要“简单” 的，从理论的角度来认识它的一个工作过程就行了
————————————————
四、HTTP响应详解
常见的响应码
200 请求成功
302 表示请求重新定向
404 表示请求服务器已经收到，但是你要的数据不存在（请求地址错误）
500 表示服务器已经收到请求，但是服务器内部错误（代码发生错误）
五、HTTP请求响应过程中的Content-type
请求 和 响应中的 Content-Type ，是不一样的。
请求的Content-Type常见取值
application/x-www-from-urlencoded
以键值对的数据格式提交
响应中的 Content-Type 常见取值有以下几种:
text/html : body 数据格式是 HTML
text/css : body 数据格式是 CSS
application/javascript : body 数据格式是 JavaScript
application/json : body 数据格式是 JSON
————————————————
