初看到这篇文章的时候，觉得标题又是一个噱头。因为技术圈很多时候也有点像娱乐圈，很多人都只是为了搏眼球。但是闲来无聊就看了一下。看了一点就觉得被打脸了。原文作者文章写的确实很不错。故此在这儿转发，以表敬意。
如果有人问你，GET 和 POST，有什么区别？你会如何回答？
我的回答
前几天有人问我这个问题。我说 GET 是用于获取数据的，POST，一般用于将数据发给服务器之用。
这个答案好像并不是他想要的。于是他继续追问有没有别的区别？我说这就是个名字而已，如果服务器支持，他完全可以把 GET 改个名字叫 GET2。他反问道，那就是单纯的名字上的区别喽？我想了想，我觉得如果说再具体的区别，只能去看 RFC 文档了，还要取决于服务器（指 Apache，IIS）的具体实现。但我不得不承认，我的确没有仔细看过 HTTP 的 RFC 文档。于是我说，我对 HTTP 协议不太熟悉。这个问题也就结束了。
最普遍的答案
回来之后寻思了很久，他到底是想问我什么？我一直就觉得 GET 和 POST 没有什么除了语义之外的区别，自打我开始学习 Web 编程开始就是这么理解的。
可能很多人都已经猜到了，他要的答案是：
GET使用 URL 或 Cookie 传参。而 POST 将数据放在 BODY 中。
GET 的 URL 会有长度上的限制，则 POST 的数据则可以非常大。
POST 比 GET 安全，因为数据在地址栏上不可见。
但是很不幸，这些区别全是错误的，更不幸的是，这个答案还是 Google搜索的头版头条，然而我根本没想着这些是答案，因为在我看来他们都是错的。我来一一解释一下。
GET 和 POST 与数据如何传递没有关系
GET 和 POST 是由HTTP协议定义的。在 HTTP 协议中，Method 和 Data（URL， Body， Header）是正交的两个概念，也就是说，使用哪个 Method 与应用层的数据如何传输是没有相互关系的。
这个如果你自己有过实际的尝试，就会完全同意原作者的。 博主在开发中就深有体会，我们没有用一些 ajax 的库，而是自己基于 fetch api 和 Promise 封装了自己的一个名为 WebAPIUtils 的网络请求库，其中默认根据参数 body 是否为空对象，来确定 GET 或者是 POST 请求，当然你也可以指定 Method。发现原来 GET 或者是 POST 和 body 是没有关系的。只是我们一般都是这么理解的，一直是很模凌两可。(好，我们继续原作者的文章)
HTTP 没有要求，如果 Method 是 POST 数据就要放在 BODY 中。也没有要求，如果Method 是 GET，数据（参数）就一定要放在 URL 中而不能放在 BODY 中。
那么，网上流传甚广的这个说法是从何而来的呢？我在 HTML标准中，找到了相似的描述。这和网上流传的说法一致。但是这只是 HTML 标准对 HTTP 协议的用法的约定。怎么能当成 GET 和 POST 的区别呢？
而且，现代的 Web Server 都是支持 GET 中包含 BODY 这样的请求。虽然这种请求不可能从浏览器发出，但是现在的 Web Server 又不是只给浏览器用，已经完全地超出了 HTML 服务器的范畴了。
知道这个有什么用？我不想解释了，有时候就得自己痛一次才记得住。
HTTP 协议对 GET 和 POST 都没有对长度的限制
HTTP 协议明确地指出了，HTTP 头和 Body 都没有长度的要求。而对于 URL 长度上的限制，有两方面的原因造成：
浏览器。据说早期的浏览器会对 URL 长度做限制。据说 IE 对 URL 长度会限制在 2048 个字符内（流传很广，而且无数同事都表示认同）。但我自己试了一下，我构造了 90K 的 URL 通过 IE9 访问 live.com，是正常的。网上的东西，哪怕是 Wikipedia 上的，也不能信。
服务器。URL 长了，对服务器处理也是一种负担。原本一个会话就没有多少数据，现在如果有人恶意地构造几个几 M 大小的 URL，并不停地访问你的服务器。服务器的最大并发数显然会下降。另一种攻击方式是，把告诉服务器 Content-Length 是一个很大的数，然后只给服务器发一点儿数据，嘿嘿，服务器你就傻等着去吧。哪怕你有超时设置，这种故意的次次访问超时也能让服务器吃不了兜着走。有鉴于此，多数服务器出于安全啦、稳定啦方面的考虑，会给 URL 长度加限制。但是这个限制是针对所有 HTTP 请求的，与 GET、POST 没有关系。
安全不安全和 GET、POST 没有关系
我觉得这真是中国特色。我讲个小段子，大家应该可以体会出这个说法多么的可笑。
觉得 POST 数据比 GET 数据安全的人会说
“防君子不防小人；中国小白多，能防小白用户就行了。”
“哼，”我不以为然，“那你怎么不说，URL 参数都 Encode 过了，或是 Base64 一下，小白也看不懂啊。”
那人反驳道，“Encode 太简单了，聪明点儿的小白很容易就可以 Decode 并修改掉。”
我笑道，“五十步笑百步耳，再聪明点儿的小白还会截包并重发呢，Opera 就有这功能。”
那人阴险地祭出神器——最终解释权，说，“这个不算小白。”
我日啊。
网络安全其实就是这样的，不过你用 GET 和 POST 都是然并卵。调试工具一打开，你往那个地址发送了什么东西全都可以看的见。如果在被截包，简直就是没有穿衣服啊。
最后一点儿感想
我之前一直做 Windows 桌面应用，对 Web 开发无甚了解，直到一年多前转做服务器端开发，才开始接触到 HTTP。（注意，我说的是 HTTP，不是 HTML 。服务器开放接口是基于 REST 理念设计的，使用的协议是H TTP，但是传输的内容不是 HTML。这不是 Web Server，而是一个 Web Service）
所以我对于 GET 和 POST 的理解，是纯粹地来源于 HTTP 协议。他们只有一点根本区别，简单点儿说，一个用于获取数据，一个用于修改数据。具体的请参考 RFC 文档。
如果一个人一开始就做 Web 开发，很可能把 HTML 对 HTTP 协议的使用方式，当成 HTTP 协议的唯一的合理使用方式。从而犯了以偏概全的错误。
可能有人会觉得我钻牛角尖。我只是不喜欢模棱两可，不喜欢边界不清、概念不明，不喜欢“拿来主义”，也不喜欢被其它喜欢钻牛角尖的人奚落得无地自容。
“知之为知之，不知为不知，是知也。”
感想
首先，感谢原作者分享这篇博文。其次，很敬佩原作者这种精神。
安全问题
web 应用的安全问题不能靠 GET 和 POST 简单地解决的。后续文章会讲讲 web 应用的安全问题，敬请期待。