用邓哥的例子来讲给大家：
邓哥家住在吃鸡村，邓嫂家住在农药屯。邓哥到邓嫂家可以有很多种选择，走着去、驾车去、坐火车去等等。邓哥通常选择驾车过去。
这里吃鸡村和农药屯就相当于是互联网中的两台计算机，邓哥和邓嫂相当于是这两台计算机中的两个程序，这两个程序之间想要通信可以有很多种协议，就好比有很多种交通方式可以到达。我们假设驾车这种方式就是网络中的HTTP协议。
邓哥家有两辆车，一辆轿车，一辆箱式货车。
两种车就好比是HTTP协议中的两种方式，我们假设轿车是GET请求方式，箱式货车是POST请求方式。
有一天邓哥想接邓嫂来吃鸡村玩，邓哥准备开箱式货车去接邓嫂。
邓哥要去接邓嫂，就好比程序A要向程序B发出一个请求。从原理上说，无论是轿车还是货车都是车，都能够把人接回来。所以在本质上，GET请求和POST请求都能拉取数据。这时候，邓哥的父亲（也就是隔壁老王）出来了，说道：“你是不是傻，去接人开轿车多好啊，开货车干嘛？费油不说，没准人家那还不让货车停车呢！”
既然GET和POST都可以做到拉取数据，那么为什么我们通常拉取数据使用GET而不使用POST呢？
在故事中，隔壁老王不让邓哥开卡车去接邓嫂，那么在现实中，是不是也有一个“隔壁老王”这样的角色在限制我们呢？
答案是：有的，这个现实中的“隔壁老王”就是ISO国际标准化组织，这个组织也说了一堆类似隔壁老王的话，这堆话被称为RFC规范。
所以说，我们常说的HTTP协议实际上是基于RFC规范的，实际上GET和POST请求的语法是完全相同的，但是在RFC规范中，给GET请求和POST请求规定了语义，规定GET用来获取信息，POST用来发送信息。
当过年的时候，邓哥想要给邓嫂家送一些年货的时候，邓哥按照隔壁老王的嘱咐，开着货车给邓嫂家送年货去了。当然，送过去了一些蔬菜也会稍微拉回来一点水果~
这就是按照RFC的规范来执行的，当邓哥想要送年货的时候，就会开货车过去；在互联网环境中，如果想要发送信息就要使用POST方法。
POST方法虽然是发送消息的，但也是有Response的，在请求返回的时候带回来一点数据也是被允许的。
那么这时候问题又来了，邓哥如果不听老王的怎么办？那这个规范不就没有作用了吗？这个时候老王也是很有办法的，老王就坐在院子门口，如果邓哥想运货出去的时候，开的不是货车就不让出院门~
光有规范没有具体的软件实施也是没有意义的，所以很多的软件遵从了RFC的规范，比如我们熟悉的Chrome浏览器。所以我们想用GET方式发送文件或者图片是不可能的~就像邓哥不可能用轿车去给邓嫂送年货一样。
最后来总结一下：当人们问起GET和POST的区别时，我们要先确定，这里的GET和POST是基于什么前提的？
- 如果什么前提都没有，也就是不用任何规范限制的话，我们只考虑语法来说，这两个方式是没有任何区别的，只有名字不一样。
- 如果是基于RFC规范的，那么问题就又来了。是基于RFC理论的，还是基于具体的实现的。
- 如果是基于RFC理论的，我们称这个为Specification。那么GET和POST是具有相同的语法，但是不具备相同的语义，GET方式用作获取信息（读信息），POST方式用作发送信息（写信息）。
- 如果是基于RFC的具体实现的，我们称之为implementation。其实要区分是具体的哪一种实现。我们通常默认指的是浏览器实现的RFC。当然不止浏览器，我们任何人都可以设计一个HTTP协议的接口，使用RFC规范，当然这些是我们不用考虑的，因为并不通用。
所以我们只需要考虑浏览器实现的RFC，或者说Web环境下的RFC。这个前提下的答案，就是我们最常见的那些。我就简单的列举在下面了。
- GET的数据在 URL 中对所有人都是可见的。POST的数据不会显示在 URL 中。
- GET对数据长度有限制，当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。POST无限制。
- GET可收藏为书签，POST不可收藏为书签。
- GET后退按钮/刷新无影响，POST数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
- GET编码类型application/x-www-form-url，POST编码类型encodedapplication/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
- GET历史参数会保留在浏览器历史中。POST参数不会保存在浏览器历史中。
- GET只允许 ASCII 字符。POST没有限制。也允许二进制数据。
- 与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET 。POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
