关于HTTP 请求方式: GET和POST的比较的本质
转自：https://www.cnblogs.com/doubleqsweet/p/7201099.html
什么是HTTP?
超文本传输协议(HyperText Transfer Protocol -- HTTP)是一个设计来使客户端和服务器顺利进行通讯的协议。
HTTP在客户端和服务器之间以request-responseprotocol（请求-回复协议）工作。
GET方法：
使用GET方法时，查询字符串（键值对）被附加在URL地址后面一起发送到服务器：
/test/demo_form.jsp?name1=value1&name2=value2
特点：
· GET请求能够被缓存
· GET请求会保存在浏览器的浏览记录中
· 以GET请求的URL能够保存为浏览器书签
· GET请求有长度限制
· GET请求主要用以获取数据
POST方法：
使用POST方法时，查询字符串在POST信息中单独存在，和HTTP请求一起发送到服务器：
POST/test/demo_form.jsp HTTP/1.1
Host:w3schools.com
name1=value1&name2=value2
特点：
· POST请求不能被缓存下来
· POST请求不会保存在浏览器浏览记录中
· 以POST请求的URL无法保存为浏览器书签
· POST请求没有长度限制
GET和POST的区别：
|
|
GET |
POST |
|
点击返回/刷新按钮 |
没有影响 |
数据会重新发送（浏览器将会提示用户“数据被从新提交”） |
|
添加书签 |
可以 |
不可以 |
|
缓存 |
可以 |
不可以 |
|
编码类型(Encoding type) |
application/x-www-form-urlencoded |
application/x-www-form-urlencoded or multipart/form-data. 请为二进制数据使用multipart编码 |
|
历史记录 |
有 |
没有 |
|
长度限制 |
有 |
没有 |
|
数据类型限制 |
只允许ASCII字符类型 |
没有限制。允许二进制数据 |
|
安全性 |
查询字符串会显示在地址栏的URL中，不安全，请不要使用GET请求提交敏感数据 |
因为数据不会显示在地址栏中，也不会缓存下来或保存在浏览记录中，所以看POST求情比GET请求安全，但也不是最安全的方式。如需要传送敏感数据，请使用加密方式传输 |
|
可见性 |
查询字符串显示在地址栏的URL中，可见 |
查询字符串不会显示在地址栏中，不可见 |
其他HTTP请求方式
|
方式 |
描述 |
|
HEAD |
与GET请求类似，不同在与服务器只返回HTTP头部信息，没有页面内容 |
|
PUT |
上传指定URL的描述 |
|
DELETE |
删除指定资源 |
|
OPTIONS |
返回服务器支持的HTTP方法 |
|
CONNECT |
转换为透明TCP/IP隧道的连接请求 |
本质上，这些并不是HTTP的GET和POST两者请求的区别，这些区别是建立在HTML标准对于HTTP协议的用法的约定之上的。
1. GET和POST与数据如何传递没有关系
GET和POST是由HTTP协议定义的。在HTTP协议中，Method和Data（URL， Body， Header）是正交的两个概念，也就是说，使用哪个Method与应用层的数据如何传输是没有相互关系的。
HTTP没有要求，如果Method是POST数据就要放在BODY中。也没有要求，如果Method是GET，数据（参数）就一定要放在URL中而不能放在BODY中。
那么，网上流传甚广的这个说法是从何而来的呢？我在HTML标准中，找到了相似的描述。这和网上流传的说法一致。但是这只是HTML标准对HTTP协议的用法的约定。怎么能当成GET和POST的区别呢？
而且，现代的Web Server都是支持GET中包含BODY这样的请求。虽然这种请求不可能从浏览器发出，但是现在的Web Server又不是只给浏览器用，已经完全地超出了HTML服务器的范畴了。
2. HTTP协议对GET和POST都没有对长度的限制
HTTP协议明确地指出了，HTTP头和Body都没有长度的要求。而对于URL长度上的限制，有两方面的原因造成：
1. 浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内（流传很广，而且无数同事都表示认同）。但我自己试了一下，我构造了90K的URL通过IE9访问live.com，是正常的。网上的东西，哪怕是Wikipedia上的，也不能信。
2. 服务器。URL长了，对服务器处理也是一种负担。原本一个会话就没有多少数据，现在如果有人恶意地构造几个几M大小的URL，并不停地访问你的服务器。服务器的最大并发数显然会下降。另一种攻击方式是，把告诉服务器Content-Length是一个很大的数，然后只给服务器发一点儿数据，嘿嘿，服务器你就傻等着去吧。哪怕你有超时设置，这种故意的次次访问超时也能让服务器吃不了兜着走。有鉴于此，多数服务器出于安全啦、稳定啦方面的考虑，会给URL长度加限制。但是这个限制是针对所有HTTP请求的，与GET、POST没有关系。
安全不安全和GET、POST没有关系
转自：知乎
因为它们表达的语义不一样，这决定了主干网络可以对其做不同的处理。
get表达的是一种幂等的，只读的，纯粹的操作，即它除了返回结果不应该会产生其它副作用（如写数据库），因此绝大部分get请求（通常超过90%）都直接被CDN缓存了，这能大大减少web服务器的负担。
而post所表达的语义是非幂等的，有副作用的操作，所以必须交由web服务器处理。
把所有get请求换成post，意味着主干网络上的所有CDN都废掉了，web服务器要处理的请求数量将成百上千倍地增加，显然这不是一个聪明的做法！
-------------------------绕圈子的分割线-----------------------
我觉得对于一个真诚地讨论问题的人来说，以上解释就足够了，然而有些人非要把圈子绕大，那我就陪你们把圈子绕完咯
“get和post就是那几个字母的区别”
开发过web服务器的同学都知道，只要请求打到了服务器上，那么要怎么解释这个请求的内容就完全是服务器自己的事情了，只是web服务器开发框架通常会自动帮你做一些解析http请求的事情而已。
所以如果说客户端和服务端都是自己写，那当然很随意，想怎么玩就怎么玩好了，事实上在没有RESTful建议的时候，大家也的确玩得很随意。
然而说出“就是几个字母的区别”这种话仅仅是表达了“我搞过服务端开发”这层意思而已。
实际上问题真正困难的地方在于，网络上每天产生的请求数目庞大，并且其中绝大部分请求均为只读请求，如果所有这些请求都要交由web服务器直接处理，这无疑是巨大的资源浪费。所以大家自然能想到，假如我们能在请求到达web服务器之前，就对请求作一个初步的解析，得知请求的大致意图，对于不同意图的请求以不同方式满足（比如请求经过nginx的时候nginx就会解析请求头信息，然后根据这些信息把请求分配给合适的角色去进一步处理），那么事情就合理多了。
于是RESTful的建议就在这个时候应运而生了，它的出现正是为了解决http基础设施未能得到充分合理利用的问题。
所以我们开发一个服务的时候，选择http协议（而不是直接用tcp），最根本的原因是，我们希望它可以直接和浏览器打交道，可以借用现有的http基础设施，它的行为能被除自己的客户端以外的，网络中的其它角色所理解。 （而不是仅仅靠http解决文本编码问题
这才是我们之所以强调get和post区别，强调“语义”的真正原因。
