本文共 3500 字，大约阅读时间需要 11 分钟。

在写springboot加mongo上传下载文件的时候突发奇想,把上传方法写成get,下载方法写成post.

直接说结果,结果用postman测试都成功了,而且时间差不多.此时我就很困惑,因为get方法按照理论来说是获取资源的,post方法是提交资源的,这样有悖于常理.但是事实就是成功了,我搜索了一下资料,网上大多数都是这样的: 这些都是基本常识,但是现在事实是我用get方法上传文件也成功了. 终于在一个英文文档里发现了端倪,

原文:

As we all know, file uploading is most often accomplished using POST method. So, why can’t the GET method be used for file uploads instead? Is there a specific prohibition against HTTP GET uploads? 解决方案 GET requests may contain an entity body RFC 2616 does not prevent an entity body as part of a GET request. This is often misunderstood because PHP muddies the waters with its poorly-named $_GET superglobal. $_GET technically has nothing to do with the HTTP GET request method – it’s nothing more than a key-value list of url-encoded parameters from the request URI query string. You can access the $_GET array even if the request was made via POST/PUT/etc. Weird, right? Not a very good abstraction, is it?

Why a GET entity body is a bad idea

So what does the spec say about the GET method … well:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe.”

So the important thing with GET is to make sure any GET request is safe. Still, the prohibition is only “SHOULD NOT” … technically HTTP still allows a GET requests to result in an action that isn’t strictly based around “retrieval.”

Of course, from a semantic standpoint using a method named GET to perform an action other than “getting” a resource doesn’t make very much sense either.

When a GET entity body is flat-out wrong

Regarding idempotence, the spec says:

Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property.

This means that a GET method must not have differing side-effects for multiple requests for the same resource. So, regardless of the entity body present as part of a GET request, the side-effects must always be the same. In layman’s terms this means that if you send a GET with an entity body 100 times the server cannot create 100 new resources. Whether sent once or 100 times the request must have the same result. This severely limits the usefulness of the GET method for sending entity bodies.

When in doubt, always fall back to the safety/idempotence tests when evaluating the efficacy of a method and its resulting side-effects.

译文:

众所周知，文件上传通常是使用 POST 方法完成的。那么，为什么不能使用 GET 方法来上传文件呢？是否有特定的禁止HTTP GET 上传？

解决方案

GET请求可能包含一个实体主体

RFC 2616不会阻止实体主体作为GET请求的一部分。这经常被误解，因为PHP使用 $ _ GET 超全局模糊水域。技术上与HTTP GET 请求方法无关 - 它只不过是一个键值列表来自请求URI查询字符串的url编码参数。您可以访问 $ _ GET 数组，即使请求是通过POST / PUT / etc进行的。奇怪，对吧？不是一个很好的抽象，是吗？

为什么一个GET实体是一个坏主意

那么规范中提到的GET方法 …那么：

特别是，规定GET和HEAD方法不应该具有除检索以外的其他操作的意义。这些方法应该被认为是"安全的"。

所以GET的重要之处在于确保任何GET请求都是安全的。尽管如此，禁止是

仅仅是"不应该" …从技术上讲，HTTP仍然允许GET请求导致一个不是 严格基于"检索"的动作。 "

当然，从语义的角度来看，使用名为 GET 的方法执行除$ b $以外的操作b"获得"一个资源也没什么意义。

当一个GET实体正在平坦的时候出错

关于幂等性，规范说：

方法也可以具有"幂等性"的性质（除了错误或过期问题）

N> 0个相同请求的副作用与单个请求相同。 GET， HEAD，PUT和DELETE共享这个属性。

这意味着一个GET方法必须而不是对

相同资源的多个请求具有不同的副作用。所以，不管实体是否作为GET请求的一部分，副作用 必须始终是相同的。通俗地说，这意味着如果发送一个带有实体主体 的GET 100次的服务器不能创建100个新的资源。无论是发送一次还是发送100次请求， 都有相同的结果。这严重限制了GET方法发送实体的有用性。

如果有疑问，在评估效能时总是回到安全性/幂等性测试中

一种方法及其产生的副作用。

幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

总结一下:我理解的意思就是,get请求也可以包含一个请求实体,虽然可以,但是不推荐使用,因为get方法要保证幂等性,这可能就是约定大于配置吧

转载地址：http://dkowi.baihongyu.com/