GET 和 POST 是 HTTP 请求的两种基本方法，最直观的区别就是 GET 把参数包含在 URL 中，POST 通过 request body 传递参数。
一些标准的区别：
1. GET 在浏览器回退时是无害的，而POST会再次提交请求。
2. GET 产生的URL地址可以被 bookmark，而POST 不可以。
3. GET 请求会被浏览器主动 cache，而POST不会，除非手动设置。
4. GET 请求只能进行URL编码，而POST支持多种编码方式。
5. GET 请求参数会被完整保留在浏览器历史纪录里，而POST中的参数不会被保留。
6. GET 请求在URL中传送的参数是有长度限制的，而POST 没有。
7. 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
8. GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
9. GET 参数通过URL传递，POST放在 request body中。
GET 和 POST 在本质上的区别：
GET 和 POST 是 HTTP 协议中的两种发送请求的方法。HTTP 是基于TCP/IP的关于数据如何在万维网中如何通信的协议。
HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。
那么，“标准答案”里的那些区别是怎么回事？
在我大万维网世界中，TCP就像汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET, POST, PUT, DELETE等等，HTTP规定，当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里。当然，你也可以在GET的时候往车厢内偷偷藏点货物，但是这是很不光彩；也可以在POST的时候在车顶上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。
但是，我们只看到HTTP对GET和POST参数的传送渠道（url还是requrest body）提出了要求。“标准答案”里关于参数大小的限制又是从哪来的呢？
在我大万维网世界中，还有另一个重要的角色：运输公司。不同的浏览器（发起http请求）和服务器（接受http请求）就是不同的运输公司。 虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到哦。
好了，现在你知道，GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
GET和POST还有一个重大区别，简单的说：
GET产生一个TCP数据包；POST产生两个TCP数据包。
长的说：
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。
因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？
1. GET与POST都有自己的语义，不能随便混用。
2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
因此，HTTP 不管使用什么方法和参数放的位置都没有关系的。下面介绍几种放 HTTP 参数的方式：
1. URL 里放参数
在URL里放参数最简单，就是问号+键值对，它存在于HTTP的Header中第一行
1 POST /psas/bug/image/confirm?param=1¶m2=b HTTP/1.1
包含两个参数
| 参数名 | 参数值 |
| param1 | 1 |
| param2 | b |
2. Body 里放参数
由于URL里放参数是放在HTTP报文头，而往Body里放参数的方式就有很多种了，如果让接收方识别这些放参数的方法，就靠Content-type
| Body参数方式 | Content-type |
| Text | text/plain |
| Form | appllication/x-www-form-urlencoded |
| JSON | application/json |
| File | 不确定 |
| Multipart | multipart/form-data; boundary=X_PAW_BOUNDARY |
根据Content-type不同，服务器去读取HTTP Body中参数的方式也不一样。
3. Body 不同参数方式介绍
1. text/plain 文本传输
HTTP 的报文是纯文本，没有任何格式和修饰，服务端就会拿走文本自己处理。
2. application 参数传输
最常用到的就是 application 格式的 HTTP 报文体，其中还分为 JSON 格式与 Form 表单格式。
3. Form 表单
最常用的传递参数方式，HTML 中都有form标签与其对应，其本身采用 Key-Value 的方式传递参数。其本身就是简单的把URL参数中?后的字符串移到Body里。所以看其Content-type全称 application/x-www-form-urlencoded 后边代表意思是 X-万维网-FORM表单-URL编码方式。
4. JSON Object
与Form表单同属一个 Content-type 分类，JSON 格式的全称是 application/json 与 Form 表单不同是，它的 HTTP 的 Body 是一串符合 JSON 格式的字符串，而不是简单的把 URL 参数移动到 Body 内。所以说 Json 格式比Form 格式更加有效的地方是传送 Object，而不是简单的 Key-Value 对。