GET请求和POST请求的区别

GET请求和POST请求的区别

经常遇到「既然GET请求可以做POST请求的事情,为什么还要区分GET和POST而不只使用一个请求?」的问题。作为在实际中被使用最广的两个请求方法,这个问题其实挺难回答的,但万物总有其根由,今天就追根究底。

查看RFC规范再加上之前查过的一些二手文章,整理了如下的观点:

  1. GET 被强制服务器支持

  2. 浏览器对URL的长度有限制,所以GET请求不能代替POST请求发送大量数据

  3. GET请求发送数据更小

  4. GET请求是安全的

  5. GET请求是幂等的

  6. POST请求不能被缓存

  7. POST请求相对GET请求是「安全」的

GET被强制服务器支持

All general-purpose servers MUST support the methods GET and HEAD. All other methods are OPTIONAL.

GET 通常用于请求服务器发送某个资源。在HTTP/1.1中,要求服务器实现此方法;POST请求方法起初是用来向服务器输入数据的。在HTTP/1.1中,POST方法是可选被实现的,没有明确规定要求服务器实现。

浏览器对URL的长度有限制,所以GET请求不能代替POST请求发送大量数据

RFC 2616 (Hypertext Transfer Protocol — HTTP/1.1) states in section 3.2.1 that there is no limit to the length of an URI (URI is the official term for what most people call a URL)

RFC 2616 中明确对 uri 的长度并没有限制。不过虽然在RFC中并没有对uri的长度进行限制,但是各大浏览器厂家在实现的时候限制了URL的长度,可查到的是IE对长度限制为2083;而chrome遇到长度很长的URL时,会直接崩溃

所以这条结论算是正确的。

GET请求发送数据更小

只能通过写代码验证了:下面第一个文件是服务器代码,作用是在客户端发送GET和POST请求的时候返回200状态码。第二个文件是客户端HTML文件,点击两个button,分别发送GET请求和POST请求。

import koa from 'koa'
import fs from 'mz/fs'


const app = koa()

app.use(function* (next) {
  if(this.path == '/test')
    return this.status = 200

  yield next
})

app.use(function* (next) {
  this.type = 'html'
  this.body = yield fs.readFile('./index.html')
  yield next
})

app.listen(8080)
console.log('koa server port: 8080')
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Title</title>
</head>
<body>
<button id="get">GET</button>
<button id="post">POST</button>
</body>
<script>
  function http(type) {
    return function (url) {
      var req = new XMLHttpRequest()
      req.open(type, url)

      req.send()
    }
  }

  var getDom = document.getElementById('get')
    , postDom = document.getElementById('post')
    , get = http('GET')
    , post = http('POST')


  getDom.addEventListener('click', function () {
    get('/test')
  })

  postDom.addEventListener('click', function () {
    post('/test')
  })


</script>
</html>

get-headers
post-headers

从上两张图可以看到POST请求的headers要比GET请求多了两个属性。所以这条结论其实也算是对的,不过从请求发送时间来看的话,其实两者并没有差别。

get-send-time.png
post-send-time

GET请求是安全的

Of the request methods defined by this specification, the GET, HEAD,OPTIONS, and TRACE methods are defined to be safe.

这里的安全指的是在规范的定义下,Get操作不会修改服务器的数据

GET请求是幂等的

A request method is considered "idempotent" if the intended effect on
the server of multiple identical requests with that method is the
same as the effect for a single such request. Of the request methods
defined by this specification, PUT, DELETE, and safe request methods
are idempotent.

从上面可以看到GET请求是安全的,在幂等性中说PUT和DELETE以及安全method都是幂等的,所以GET自然也被包括了。

POST请求不能被缓存

我们在实际使用过程中对HTTP请求的优化大多数都放在GET请求上,比如对没有数据变化的请求(网站中常用的静态文件)做缓存,在潜意识中认为只有GET请求才可以被缓存,所以从来也不会考虑POST请求的缓存优化,然而在RFC中提到GET和POST以及HEAD都是可以被缓存的。不过不要惊讶,之前不知道POST可以被缓存是因为标准也很无奈,浏览器的实现总是比标准厉害。

In general, safe methods thatdo not depend on a current or authoritative response are defined as cacheable; this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD.

POST请求相对GET请求是「安全」的

这一点很多人都会质疑,被抓包之后的POST请求和GET请求是一样裸露的,所以更安全的说法是不对的。我这里所有的「安全」是相对的,因为GET请求有时候会直接反应在浏览器的地址栏,而现在的浏览器大多会记住曾经输入过的URL。试想如果你曾经在别人电脑上填过一个很私密的表单,那么你的这份记录很可能被连没什么电脑常识的人都一览无遗。

阅读 24.2k

推荐阅读
网道
用户专栏

写技术文章就要脸皮够厚;1.不管别人写没写过,比不比自己写得好,2. 不在乎别人会不会打自己脸或者自己...

813 人关注
34 篇文章
专栏主页