@
SimonOne 随便就搜到个：
blog.csdn.net/CHEndorid/article/details/111277629而且和楼主公司的情况挺像的，不会就是同一个公司吧？
直接贴过来：
```text
一、背景
最近研发让我开一下服务器的 put 、delete 方法，被我以不安全的 http 方法给拒绝了。
研发表示我很无理，put 怎么就是不安全的了，在他看来，put 和 post 只是语义上的不同。如果 put 是不安全的方法，那么 post 也是不安全的方法了。
网上的说法也是分为两派，一派说这些都是不安全的方法，要关掉；另一派说它们只是语义上的区别，不存在安不安全。
二、一探究竟
经过我和研发各自编写测试用例来论证后，我明白了为什么会有这样的分歧：我是从 nginx 作为 web 服务器的角度来看问题的，研发是从 java 代码上来看问题的。
1 、为什么说 POST 和 PUT 只是语义上的区别？
在研发的代码里，终端（浏览器或客户端）过来的流量，最终通过 java 的注解，携带参数进入到了研发写了一个方法里来了。比如研发对某个自定义方法使用 PUT 的注解，那么终端通过 PUT 方法传递的参数就会进入到这个自定义方法中。有点编程经验的话，就会知道，到了你写的方法里，这些参数就随便你玩了。
对于 PUT 、POST ，研发都可以通过添加不同注解的方式，得到传递的参数，然后进行操作。所以研发会认为他们只是语义上的区别。
2 、为什么说 PUT 、DELETE 是不安全的方法？
对于 nginx ，可以使用 HttpDavModule 编译 nginx （./configure --with-http_dav_module ），开启 PUT 、DELETE 等方法。开启后，恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上，所以 PUT 等方法对 nginx 来说是不安全的。
3 、上面两个问题是否矛盾？
并不矛盾。
假如研发人员打包一个 jar 包，这时客户端直接访问这个 jar 包起的服务，那么 put 传递过来的所有参数，是可以由研发人员编写的代码控制的。只要控制得没有猫病，那么就是安全的。假如开发的是一个 tomcat 容器部署的工程，参数也是一样可以由研发的代码控制的。
同时，用 nginx 也可以反向代理 put 方法（不用 HttpDavModule ），所以只要后端服务对 put 服务做好控制，nginx 不需要做任何更改，也就实现了对 put 方法的支持。
但 nginx 不能单独开启 put 等，因为研发的代码不能对 nginx 做控制。
三、结论
后端服务可开启 put 方法，只需要后端服务对 put 传递的参数做好控制，并实现 put 方法即可。
nginx 不可开启 put 方法，这是一种危险的方法。
```
另外：竟然真的有人认为 REST 挺好，是有多傻。