GET请求 | POST请求 |
---|---|
幂等,不会产生副作用(在浏览器刷新/回退时是无害的)。在HTTP的定义中,GET被称为安全方法。 | 非幂等,重复请求可能会带来意想不到的效果。 在HTTP的定义中,POST不是安全的方法。 |
GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。 | POST放在Request body中。 |
GET请求参数会被完整保留在浏览器历史记录和服务器上日志记录里 | POST参数都在body里面,服务器日志记录不到,浏览器历史也记录不到。 |
GET请求由于浏览器地址栏的限制,对传送的参数是有长度限制的 | POST没有。 |
GET产生的URL地址可以被Bookmark。 | POST不可以。 |
GET请求会被浏览器主动cache | POST不会,除非手动设置。 |
GET请求只能进行url编码 | POST支持多种编码方式。 |
对参数的数据类型,GET只接受ASCII字符 | POST没有限制。 |
GET产生一个TCP数据包 | POST产生两个TCP数据包。 |
* 1. 幂等的意思是,同一个请求重复发送返回同样的结果。
* 2. 如果不使用HTTPS传输,GET和POST都是不安全的。
Safe
- 安全这里的「安全」和通常理解的「安全」意义不同,如果一个方法的语义在本质上是「只读」的,那么这个方法就是安全的。客户端向服务端的资源发起的请求如果使用了是安全的方法,就不应该引起服务端任何的状态变化,因此也是无害的。 此RFC定义,GET, HEAD, OPTIONS 和 TRACE 这几个方法是安全的。但是这个定义只是规范,并不能保证方法的实现也是安全的,服务端的实现可能会不符合方法语义,正如上文说过的使用GET修改用户信息的情况。引入安全这个概念的目的是为了方便网络爬虫和缓存,以免调用或者缓存某些不安全方法时引起某些意外的后果。User Agent(浏览器)应该在执行安全和不安全方法时做出区分对待,并给用户以提示。
Idempotent
- 幂等幂等的概念是指同一个请求方法执行多次和仅执行一次的效果完全相同。按照RFC规范,PUT,DELETE和安全方法都是幂等的。同样,这也仅仅是规范,服务端实现是否幂等是无法确保的。引入幂等主要是为了处理同一个请求重复发送的情况,比如在请求响应前失去连接,如果方法是幂等的,就可以放心地重发一次请求。这也是浏览器在后退/刷新时遇到POST会给用户提示的原因:POST语义不是幂等的,重复请求可能会带来意想不到的后果。
Cacheable
- 可缓存性 顾名思义就是一个方法是否可以被缓存,此RFC里GET,HEAD和某些情况下的POST都是可缓存的,但是绝大多数的浏览器的实现里仅仅支持GET和HEAD。关于缓存的更多内容可以去看RFC7234。
另,参考:https://www.cnblogs.com/nankezhishi/archive/2012/06/09/getandpost.html