从设计初衷考虑get是为了查询服务器资源（不改变服务器数据及状态，因此说它是安全和幂等的，但get请求参数一般是直接在url后面，浏览器地址栏中会被看到能保存书签及历史记录，这点讲可能不安全），post是向服务器提交资源（会改变服务器资源和状态，但向服务器提交的数据一般是放在请求体request body中不会直接在地址栏中看到这点说它相对安全——实际上抓包是能看到数据的）。
2、数据长度限制：
（1）URL长度限制
在Http1.1协议中并没有提出针对URL的长度进行限制，RFC协议里面是这样描述的，HTTP协议并不对URI的长度做任何的限制，服务器端必须能够处理任何它们所提供服务多能接受的URI，并且能够处理无限长度的URI,如果服务器不能处理过长的URI,那么应该返回414状态码。
虽然Http协议规定了，但是Web服务器和浏览器对URI都有自己的长度限制。
服务器的限制:接触的最多的服务器类型就是Nginx和Tomcat,对于url的长度限制，它们都是通过控制http请求头的长度来进行限制的，nginx的配置参数为large_client_header_buffers，tomcat的请求配置参数为maxHttpHeaderSize,都是可以自己去进行设置。
浏览器的限制:每种浏览器也会对url的长度有所限制
（2）请求数据限制
对于get请求，在url的长度限制范围之内，请求的参数个数没有限制。Post数据的长度限制与url长度限制类似，也是在Http协议中没有规定长度限制,长度限制可以在服务器端配置最大http请求头长度的方式来实现。
URL 长了，对服务器处理也是一种负担。原本一个会话就没有多少数据，现在如果有人恶意地构造几个几 M 大小的 URL，并不停地访问你的服务器。服务器的最大并发数显然会下降。另一种攻击方式是，把告诉服务器 Content-Length 是一个很大的数，然后只给服务器发一点儿数据，嘿嘿，服务器你就傻等着去吧。哪怕你有超时设置，这种故意的次次访问超时也能让服务器吃不了兜着走。有鉴于此，多数服务器出于安全啦、稳定啦方面的考虑，会给 URL 长度加限制。
理论上讲，POST 是没有大小限制的，HTTP 协议规范也没有进行大小限制，说 "POST数据量存在80K/100K 的大小限制" 是不准确的，POST 数据是没有限制的，起限制作用的是服务器的处理程序的处理能力。