被客户告知 HTTP 的 PUT 请求不安全，甩锅给我们要求整改

[TossPig]

真的是要吐，这段时间好几个客户单位反馈业务系统无法使用，一直报错

上去一看，PUT 请求全部被拦截，也不知道家防火墙商干的好事，默认把 PUT 请求全部给禁了，还给客户培训说 PUT 请求就是不安全

给客户解释了半天，根本不听，就说防火墙这样设置肯定有他的道理，说是我们使用了不安全的请求方法，要我们负责安全整改

全站遵循 RESTful 设计的呀~简直要疯了~也不知道哪个 wbd 做的默认规则

[wqtacc]

遇到这种不讲道理的，写啥承诺，中间件加一个"X-Http-Method-Override",改成 POST

[fuxkcsdn]

就一个 method 名看把你们矫情的
看来是没经过甲方爸爸的揉虐

[binux]

@lesismal Java 没问题，Nginx 有问题，而 Nginx 是那个文章作者负责的，所以是文章作者自己的问题。

[twl007]

@lesismal 感觉你可以去跟 Box API 的团队讨论下 API 设计 人家 get put post 语义明确 用起来一点毛病没有 不知道 Box 算不算特定领域亦或是人家对安全要求低 反正没见人家有这个问题

https://developer.box.com/reference/

Google Cloud 的 API 设计指南中也给出了不同方法的明确语义并且 GCP 的 API 设计也遵循指南

https://cloud.google.com/apis/design

This chapter defines the concept of standard methods, which are List, Get, Create, Update, and Delete. Standard methods reduce complexity and increase consistency. Over 70% of API methods in the Google APIs repository are standard methods, which makes them much easier to learn and use.

[Valid]

回到一个问题，RESTful 真的有必要吗

[skinny]

@kaneg 国内厂商做安全最喜欢的就是掩耳盗铃，特别是跟国字头有关的，演习期间更是掩耳盗铃到你无语……现在执行和法规也是解决提出问题的人……我都搞不懂国家大方向明明是想真的提高网络安全信息安全，可很多措施和执行却反其道而行，也许实在太多人人不是一条心，又有太多顽固半吊子把控……

[learningman]

@knives #30 总感觉这个是个可以注入的点。。

[learningman]

@cweijan #114 restful 哪激进了，激进的都 graphql 了（

[FakNoCNName]

大家都在凭自己经验和知识相互讨论，我个人比较喜欢使用新鲜的东西，所以知道 restfull 出来不久就开始接触、使用，这些年用下来也还不错。

当然我也遇到几个项目就是用老技术（不代表过时），从框架到各种小算法都改下来很麻烦，所以继续使用，而开新项目的时候呢，直接拿老框架复制粘贴。算是历史原因了吧，毕竟全改下来从工程上几乎是推翻重来了，成本太高。

不过个人还是喜欢追新技术，从技术发展就能看出来新技术代表一种理念，虽然不一定能成为标准，但肯定有收获，反而始终用着开始的东西，后面不改也不尝试新技术，会随着中间错过的东西越来越多被淘汰。

旧的不一定过时，但总有一天会过时，新的不一定成为标准，但成为新标准的肯定是新技术。

（技术方面聊到这里其实已经没多少可以争论的了，大家都说清了主张和原因，很多东西都是有历史原因的，也需要考虑成本，最后总有一方需要改变。）

以上的内容出圈了，看了这么多回答有点个人感受。

@lesismal

[zhangchongjie]

restful 接口 2000 年就出来了,到现在还能叫新东西?web 规范现在有几个不是?post,put 也就是个请求方式,你非用 post 也没人管你不是? 这两个都是规范而已,不像遵循可以走自己的方式,系统统一就醒了.回到原题,如果真觉得不安全应该采用 https 而不是争这些,http 决定了你不管用那个请求都有风险,楼上争什么呢没看懂,还能扯到新人老人,2B 吗

[0o0o0o0]

@TossPig 想问一下你们用 nginx 只是为了反向代理吗，如果是的话，那么完全不需要编译 dva 。

[TossPig]

@0o0o0o0 我们的整个部署环境就没有 dva 这个东西

@lesismal 我们后端就是 go ，echo+gorm,后端迭代特别顺滑，现在有点趋势上的包袱反而在前端，当年历史原因这套系统选择了 angular 作为底层框架，进新人特别慢，上手 angular 确实需要两周的时间，现在国内几乎是 vue 的天下

@wqtacc 那承诺就是个笑话，在告诉懂的人，这甲方在质疑 restful 的安全性 ？？？

@iseki Websocket 这东西，一直没怎么用起来，看过有有人用 Websocket 写的 bbs 项目，各种原因也没推广开，没测过，但是有状态协议，对服务器的压力还是比无状态大的，说白了，普通的 web 应用的需求都是无状态的，任何绕开的方式，都是在对 http 造轮子

@fuxkcsdn 不觉得这是矫情，现场不就是不停的和甲方+友商小伙伴扯皮吗？都不加钱的甲方爸爸，只能算孙子~

[avv]

@Ib3b 一把刀，有人认为他是杀人凶器，有人认为他是一把菜刀；怪刀吗？

[egfegdfr]

说 RESTful 没必要的，就和我刚出来告诉我 一行代码只能写 80 个字符，Lombok 不安全,引入 mybatis-plus ，和 pagehelper 没啥用一样
拥抱变化~~~

[mytsing520]

技术态的不讨论，上面讲了很多。

只讲一句，不要和甲方争论技术，不要改动甲方已有的场景、习惯和规则。

[leeg810312]

@lesismal 原来是 go 吹，go 用了什么都要成主流是吧？流行的开源项目好多都有 rest API ，除了前面举例的，还有 devops CI CD 整个生态的大量软件都提供 rest API ，不仅 put delete ，甚至还有 patch ，云计算平台也是目前趋势吧，也是大量 rest API 。你的回答是不是趋势不一定对，主流不一定好？看来你是权威，只有你才能决定什么是对，什么是好

[mytsing520]

#175
准确来说，是“不要和甲方争论技术，不要改动或试图改动甲方已有的场景、习惯和规则。”

[lesismal]

@twl007
> 感觉你可以去跟 Box API 的团队讨论下 API 设计 人家 get put post 语义明确 用起来一点毛病没有
> 不知道 Box 算不算特定领域亦或是人家对安全要求低 反正没见人家有这个问题

我好像没说过所有 PUT/DELETE 不安全吧，包括转的帖，也是说特定场景下的不安全比如文件服务相关的，而比如前面其他人提到的云厂 API PUT ，以及你提到的 box google ，API 接口控制好，我也没说有安全问题，但这些都是控制好的前提下，我们不能指望所有团队都按照你提到的厂的规范，尤其这世上还存在很多健在的 php asp jsp 项目。

我之前有说，在这个帖子里关于 PUT 的观点包括几个方面：
1. 安全规避以及替代成本不高
2. 与其他方案对比的优劣
3. 工程、跨工种 /部门 /公司协作

我并没有说 REST 就一定不安全、不能用。但是 PUT 在现实场景里，就是有的人会面临 1 和 3 的额外的麻烦比如楼主的项目，而如果不用 PUT ，则可以免掉这个麻烦，而且抛开项目历史包袱，POST 替代 PUT 成本也可以忽略

REST 的各种 Method ，一是基于 HTTP 协议本身，二是基于社区发展实践和历史，按照工程实践形成的规范继续实践下去也 OK ，但是我说的是与其他方案对比的优劣，如我 #88 中说过的，各位没有考虑参照物对比、只是说 REST 可以用，各位跟我聊的甚至不是一个事情

#88 我已经解释了一些，各位有没有想一下，如果早期 HTTP 就没 Method ，大家还必须依赖 Method 吗？只用路由能搞定吗？ RPC 的 'Method' 其实是相当于 HTTP 的路由，RPC 其实没有 HTTP 这种在路由之外额外再套上的 Method 区分，即使 GCP 文档里的 PB RPC Service 定义部分，也是直接把 HTTP Method 映射到 RPC Method 上（就是方法 /函数名），相当于我 #88 说的 路由+参数 两个维度，并不需要三个维度。其他的很多自定义二进制协议场景也是类似，路由 /方法名 /命令号 + 参数 这两个点就足够了，也是并不需要非得搞成三个维度

我真正想聊的，是自底向上从不同的设计方案来对比 A 和 B 两种方案或者设计 /使用方式，哪种更简化、更省更好，而不是各位这种多是自顶向下从如何使用 A 或者在 A 的历史实践中形成的经验如何好用。

所以跟 box 聊设计或者跟 google 文档对比，跟我说的这些都没什么关系，希望有人能 get 到我说的点，而不是继续跟我聊 A 方案为什么好用。

[lesismal]

@FakNoCNName 我真正在辩论的点可能大家好些人都没理解到，请参考我 #178 的回复。

> 旧的不一定过时，但总有一天会过时，新的不一定成为标准，但成为新标准的肯定是新技术。

>（技术方面聊到这里其实已经没多少可以争论的了，大家都说清了主张和原因，很多东西都是有历史原因的，也需要考虑成本，最后总有一方需要改变。）

这些我也是都认同的，前面几楼也解释了一些。因为好些位看到个关键字就断章取义了，把我意思都给曲解了 :joy:

[lesismal]

@leeg810312
我希望聊技术的人能带上点脑子，就比如 go 吹，go 吹就不能聊这些设计了吗？前面楼问过其他人，现在也问你一句：你逻辑及格了吗?

#132 回复你的你能看懂吗？
#178 的回复你也可以看一看

说自己十几年经验，一直在这断章取义、望文生义、无论据式无脑口嗨，十几年就这？十几年一直写 CURD 了是吧？只会为杠而杠是吧？

能看懂我回复再来 at 我行不？