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

@lesismal #90 我说的云厂商的 API 就是指 Open API ，包括对象存储的 PUT Object

要说防火墙不一样，云厂商自己不也有防火墙吗？要说软件不是 Nginx ，大多厂商 CDN 和 WAF 用的就是 Nginx 。怎么我们用 Nginx + PUT 就安全，你们用 Nginx + PUT 就不安全了？这只能说明你们运维菜，不足以说明 PUT 方法不安全

考虑其他老软件所以不支持 PUT ，这又关 PUT 安不安全什么事呢？软件的漏洞怪到 HTTP 方法上面，菜，拿了私钥的防火墙连分流策略都不懂得做，只会按总开关，菜上加菜

我前面的评论是解释那篇文章的错误在哪儿，无意跟你辩 HTTP PUT 会不会导致入侵，在我看来这不是一个值得讨论的问题。不必再给我大段回复，互相省点时间

@eason1874
照你们这些以某些厂的场景和做法就代表全天下场景都应如此的聊法，确实别聊了。建议你们努力合并全天下技术厂、直接一统江湖得了。

@lesismal 你就是一个守旧的老古董罢了, 实际上现在 RestFul 非常流行, 新项目基本都用这种方式, nginx 都是充当一个反向或静态服务器, 根本用不着 webdav, 说使用 nginx 需要禁用 put 完全是无稽之谈, 把 CSDN 随便转来的一遍文章当成真理真是搞笑.

@lesismal 你这话也可以用给你啊。要不你去把 HTTP 标准改了，只留 GET 和 POST 。

改呗,make them happy,恶心自己,成全别人。

一个东西如果要垮部门改动，这个改动得找个有点分量的人来牵头，后续可能出现的问题需要这个有分量人协调。

如果人微言轻，勉强让人改了,下次因为这个改动 甚至新出现的不明原因的 bug ，都可能甩给你。现实世界不是只有 0 和 1 ，不能都围着你转。

也别争论什么技术细节了，就一个历史原因造成的安全问题，一个跨部门（你这是跨公司）协商问题。

@Bromine0x23
我经常送给我自己，你有送给过自己吗？另外，你哪里看到我说要改标准了？可理解了我前面楼层的回复意思？没理解的话麻烦就别随便 at 我了

@cweijan
> 实际上现在 RestFul 非常流行
流行跟主流不是一码事，劣币驱逐良币的时候多着呢，流行也未必就代表好，如果连这个都理解不了，那你喜欢就好

> 你就是一个守旧的老古董罢了
老古董算是半个吧，但至少现在的时代还是老古董为主在占据着多数项目的技术话语权

@lesismal 在你眼里除了 CURD ，别的开发就不会有 PUT DELETE ？那么你说我开发部门要开发一个功能一定要调用这些 API 怎么调用？既然你承认别人的 API 是安全的，却又不让我用，你逻辑自洽吗？

后面再有只考虑自己 curd 这点事的同学想辩论就请不要 at 我了，我不想再回复这种了，先谢谢年轻人能对老古董给予体谅。

能跑就行了

@leeg810312 同样的，如果没理解我前面楼层的意思，就请不要 at 我了。反驳的点都没对到点上，有的还曲解别人的意思。

@lesismal 我们在给世界 500 强公司开发，别人的内部网络安全策略那么严格，需要申请网络策略变更开 IP 开端口，只要走流程能说明清楚，都是可以开，从来不会被各种过时的安全理由而拒绝

@lesismal 我理解，你的意思就是我的地盘我做主，我在管网络就是不让你改。

@lesismal 你知道你是老古董就好, 不要用你的思想加给年轻人, 在技术或是政治等各种领域, 年轻人永远都是最激进的那批, restful 是无法阻挡的浪潮.

看 ls 有的人就奇怪了，现在好多框架都 是 restful 的，比如一直用的 rails 了，get put post delete 四种方法，按 ls 有的人说法，rails 不安全啊，

@leeg810312
请教："能给你开" 和 "本来就可以不用开"，你觉得前者更好吗？

能 curd 的人很多，能上升到工程思考的不多，能上升到工程哲学的更少，共勉吧。

@FightPig
我对号入座一下，至少我没这么说过，不安全也是有场景的。如果擅长断章取义、望文生义，请自便。
如果我对号入座得不对，请无视。

@cweijan
好的，小伙子加油，我看好你们！
而且，论坛嘛，哪来的强加的说法，都是讨论交流，我只是自己管的项目一刀切而已，没项目交集的各位自己喜欢就好。

祖宗之法不可变[doge]

先找几个大公司，提供接口例子证明 put 和 delete 是经得起考验的。
再和甲方说他们的安全设施陈旧，漏洞太多
再提一个适配老旧甲方设施的一揽子方案，（就是替换 put ，delete ），报价高一点，因为乙方还会继续为甲方“贴心的”评估安全性。

https + post + json
走天下

@lesismal PUT DELETE 就一个 HTTP 方式，居然还上升到工程架构这么高的级别了，明显就是说服力不够，非把一个实际上不存在的小问题渲染得及其严重。前面说了，现在很多 API 就是有 PUT DELETE ，所以必须开放，没有能不能可以不可以的所谓选择，也从没听说现在的这些软件和服务哪个是因为 PUT DELETE 产生的安全问题，让人黑了。大概只有你这种抱残守缺的才会找莫须有的安全问题作为借口，我做 500 强的几个项目都没有遇到这种莫名其妙的安全策略，看来 500 强的安全部门都没有你厉害。和你共勉就免了，有的是与时俱进的大牛让我向他们学习。

这种简单认为 put 方法就不安全的垃圾防火墙买来干啥，讲讲是哪个厂家的产品。。
印象中在哪里看到过等保只能过 POST 和 GET ，这都安全行业定制的吗？

@leeg810312
所以我 #111 楼里说你都没理解我前面楼说的内容，你可能都没怎么仔细看吧
#116 你也不回答一下：再请教一次："能给你开" 和 "本来就可以不用开"，你觉得前者更好吗？
#90 楼也可以看下

你要辩的内容，我在前面好几个楼里都已经提过了，我不想再重复了，如果看不懂或者根本没看，就麻烦你不要再 at 我了。几位提到某些云厂的接口，我也有回复过，场景不一样，你但凡没兴趣看或者在这只说别人家有这么用而不是讨论用和不用到底哪个好就别辩了。
不提论据只说别人怎么搞或者你给别人怎么搞所以就是好的，这种辩论法，跟泼妇撕逼骂街没什么本质区别。事情和事情不一样，别断章取义、望文生义

另外，给 500 强做的项目有那么值得自豪吗你张口闭口的，感觉其他几位提到云厂也没像你这么自豪啊，某 500 强我十几年前呆过，有很多牛逼的地方，不完善的地方更多，有一些老同事还在里，说现在不像以前那么盲目 996 不盲目拉横幅搞敏捷了，而是更注重科学管理、效能提升以及员工身心健康各种了，所以现在应该是更好了。但是任何一家公司都不是十全十美的，每个公司也都有初级中级水平的人员，如果你还年轻，等你冷静的时候可以考虑下跳出多数人只顾眼下 curd 逻辑程序员的思维，让你自己站在更高的层面看待整个项目的技术与管理与跨部门协作各方面问题。甚至等你年纪再大点、处理过的大项目大业务再多些再回头来挖这个帖子的坟来 at 我都可以，但是这次，我建议你还是冷静冷静吧，回复的内容为喷而喷没什么论据，我认输

笑了, 单纯 WebDAV 的黑历史歪楼歪到 RESTful 的优劣也是没想到.

更搞笑的是 RESTful 话题里的人几乎都没表现出对 REST 的了解. 不理解 RESTful 执着于 URI +动词的目的, 只是跟风套了一些惯例就觉得自己站在时代大道上的, 估计是没法把所谓 RESTful API 写得比 GET+POST 的 JSON API 更好用的.

我不是安全领域专业户，但是各位可以搜下 "HTTP PUT 攻击 渗透" 或者 "HTTP PUT ATTACK" 之类的，老外的、国内的都有很多相关的帖子或者演示

一些漏洞扫描软件自带功能也包括对 web 服务的 PUT 方法进行扫描

#116 楼的问题我也想统一再问一次那些说安全的各位：
"能给你开" 和 "本来就可以不用开"，前者更好吗？

类似 "这只能说明你们运维菜，不足以说明 PUT 方法不安全" 这种观点，同样的问题：
"运维能搞" 和 "本来运维可以不用额外搞这个"，前者更好吗？

参考我前面几楼说过的工程逻辑、跨工种跨部门甚至跨公司的观点

现在的年轻人都这么喜欢无论据方式的阴阳怪气吗？

很看好你们最新鲜的一代，但也经常感到失望。希望你们 30 、40 岁的时候不会继续这个样子吧。

@lesismal 我做 10 几年开发，现在做架构设计也做开发方面的工作，当前客户基本都是 500 强，不以当前的工作举例还能怎么举例？和我以前的工作接触到的客户比，当然是他们的安全政策最繁复安全管理最严格，你看到几个很菜的能说明什么问题？

我在客户内网工作必须使用客户的电脑，操作服务器必须用跳板机，所有开 IP 和端口白名单必须申请并说明理由，除了 web 和邮件等少量服务器其他服务器不能有外网连接，代码发布前做安全检查，服务器定期安全扫描等等，按你说的这样的安全是不是够工程思维了，但检查到需要整改的安全问题从来没有与 HTTP 方式有关，客户网络安全环境可是跑着跨地区几百上千个大大小小系统的网络。

现在的软件和服务生态已经包含了那么多 API 使用 PUT DELETE ，网络环境复杂，但你反正永远强辩别人做得安全就是场景不同，我也看不出你说的所谓场景有什么特殊的地方。再次强调 HTTP 不是只有 CURD 才用，所以很羡慕你能在你的公司有权无理由拒绝需要调用 PUT DELETE 的一切应用。不过现在生态变了是趋势，建议您还是要跟上时代呢

我去，，，下班回来直接麻了，这破事儿居然吵热了

给各位汇报一下这个事儿的进展
最后的方案，是甲方也不想再花钱，我们写一个承诺书，我写了一句话，其他甩给商务去扩展了
------------------------------------
因为我司产品遵循 restful 设计原则导致的网络安全问题，由我方承担全部相关责任
------------------------------------
下午还有个小故事

最开始电话和网络中心主任沟通的，表示我们能说明是安全的就行，问题不大，
十分钟后又打电话来，说他问了他们专门管安全的专员，说这个就是风险！！！最后怎么变成修承诺说的就不知道商务怎么周旋的了


我前面已经说过了，这事儿其实也不是个什么事儿，

但是，我明明没有错，为什么要为别人的无知买单？要去“委曲求全”的“绕过”？

加钱

@lesismal 我把你所有回答都看了，GET 就不能改 /删东西了？啥玩意儿，看到底你就是个外行，还喜欢扮 “高层面”。找你这么说，用 POST 替代 PUT ，然后一个傻帽把数据库全清空了，然后你又说 POST 不安全？

@leeg810312
我好像没说过强制你们也别用吧？我各个楼是在对比 PUT/DELETE 相对于不用它俩的优劣以及不用它俩的成本，关联到工程、协作等相关的层面，都是在讨论更好的方式。而你们的点就是你们再用并且能用，但是这种方案就是最正确的最好的吗？
自己项目正在用和能用，跟对比其他方式是否存在缺点孰优孰劣，是两码事
流行不代表就是主流，即使主流也不等价于最优
这些我前面楼都有讲过，你们跟我辩来辩去有人认真看我说的点了吗？:joy:

所以这些楼层下来，相当于我在说 A 不如 B ，并且我解释为什么 A 不如 B ；然后你们就说你们在用 A ，你们给大厂的方案也是在用 A ，云厂也在用 A ，驴唇不对马嘴地怼我呢，多数都没怼到我聊的点上，也不提一些论据，比如说为什么 A 就是比 B 好并且好在哪些地方，或者说 A 相对于 B 没有带来更多缺点或者额外的成本（比如安全策略的设置、更新、维护，比如楼主 @TossPig 刚才回复的需要走流程写保证书，本来如果你们不用 PUT/DELETE ，就不需要这些额外的成本，当然，楼主项目历史积累的方案、不改我也理解、支持，只是如果有新项目的时候，建议改成不依赖 PUT/DELETE 的，只是建议，各位自己决定就好）

然后，既然兄弟你都也十多年经验了，跟我杠的时候就不能认真看看我在说什么吗。。。非要像个 95 后一样盲怼我，你们各位怼我的大侠扪心自问一下这样够讲武德吗 :joy:
别说什么我跟上时代潮流，除了你们的团队，还有很多团队都在用 GET/POST + 结构化 body ，甚至像我一样连 GET 都不用的，不要以为自己的圈子就是最大的最流行的圈子就是最潮流的，我上面和其他楼都说过了，流行和主流和最优都不是等价的，否则就不会有革新了。
另外，牛逼的人把复杂的事情简单化，一般的人把简单的问题复杂化，less is more ，上点年纪的多做过一些各种项目的应该要懂的。

PS: 很多交流如果允许带上图，气氛可以不那么激烈，真希望 v 站能畅快的发点 emoj ，:joy: 是我觉得比较能不互相刺激的表情，但是发不出来，各位脑补好了

@xfriday
> 我把你所有回答都看了，GET 就不能改 /删东西了

我什么时候说过这话了？我说 PUT 能删文件 == 我说 GET 不能删文件？你逻辑及格了吗小兄弟？

另外，GET 能删跟 PUT 的删法一样吗？你每层楼都看了没看懂我说 PUT 文件服务跟 api 的区别？自己不会搜一下？哪里来这么多自信上来就喷，真看了吗？真看懂了吗？

好多断章取义，望文生义上来就怼的，服了你们了

> 找你这么说，用 POST 替代 PUT ，然后一个傻帽把数据库全清空了，然后你又说 POST 不安全
文件服务的 PUT ，跟你的 api POST 接口相比，参数校验方式一样吗？ webshell 那些，黑客漏洞扫描工具那些，了解吗？

> 看到底你就是个外行，还喜欢扮 “高层面”。
我扮没扮高层面我自己清楚，但咱俩谁外行你未必清楚

@lesismal 额，，，不会的，新项目我依然会坚持做这样的设计

考虑的点是基于这样几个考虑

1. 产品设计应该尽量统一，采用流行的模式，方便交付，以及和其他厂商同行对接，流行的规范，大多数人更容易接受，读到你是 delete 请求，自然知道这里是要删除一个什么东西，读到 post 的时候，知道这里是新增了一个什么东西，不是 and,create,built 一堆动词的滥用

2. 哪怕我改成全 POST 封装，实际还是会在 POST 的不管是 body 或者 url 中描述这个操作是 query ，还是 edit 或者 delete ，和写 header 里面的 method 头没区别，只是小聪明的重复造轮子了

3.不是每个客户都这么恼火，也有甲方，默认给关了，但是你提出需求，就直接放行了，不是每个客户都这么固执

4.这次坚持了，下一次同一个甲方再遇到这个问题，哪怕是其他同行就不存在沟通成本了

嗯，暂时想到这么多，突然想起两句话，其他地方不一定对，在这里我觉得可以参考“用户是需要被教育的”，“用户不会提前告知你什么是更好的”

@TossPig
> 流行的规范，大多数人更容易接受，读到你是 delete 请求，自然知道这里是要删除一个什么东西，读到 post 的时候，知道这里是新增了一个什么东西，不是 and,create,built 一堆动词的滥用

抛开 RESTFul 不谈，我前面提到的三元 /三个维度的问题，其实 post delete 的方法在路由上就搞定了比如 /aaa/bbb/delete ，但是路由上做可以省去 Method 的不统一和比如这次聊到的 PUT 的问题

> “用户是需要被教育的”

这个不太同一，如果我们做得更简约，比如 POST 替代 PUT ，则连教育用户都可以省掉了



但公司产品统一，这个没毛病，适合你们自己当前实际情况的就是好的。good luck~ :smile:

@lesismal
> 文件服务的 PUT ，跟你的 api POST 接口相比，参数校验方式一样吗？ webshell 那些，黑客漏洞扫描工具那些，了解吗？
文件服务难道不是读取请求，执行操作？和 api 有区别吗？难道不是人写的？难道你手里有 bug 文件服务才叫文件服务，别人写的没问题的文件服务就成 api 了？

@xfriday 兄弟，出门左转百度，右转谷歌，请自己查一下，我就喜欢你们年轻人这种活泼劲儿 :joy:

@lesismal 自己阴阳怪气还装老

楼主好惨，遇到这种奇葩的半吊子安全专员……帖子里也一堆这种专员……

一句安全压天下，谁人不识安全厂商大忽悠

全给 tama 改成 GET 啊

post 把

甲方脑残，不过为了赚钱倒也可以迂回下，搞个 http over http 就好了。还可以宣传一波自带混淆，顺便多要点

@lesismal

> 抛开 RESTFul 不谈，我前面提到的三元 /三个维度的问题，其实 post delete 的方法在路由上就搞定了比如 /aaa/bbb/delete ，但是路由上做可以省去 Method 的不统一和比如这次聊到的 PUT 的问题

我们的理解可能不太相同

为什么要抛开 restful?至少我还没找到一种在 web api 设计中更优的最佳实践

你看了半天，也没找到你前面提的三元问题

至于说“省去 Method 的不统一”,其实你自己的举例中也在路由中，补入了一个 delete
难道我的
/user?ids=aaa,bbb
method delete
就没统一描述 /user 这个资源？

我在脑子里做了，想象中你的方案的落地，没找到比 restful 的优点

反而感觉像放弃了，http 协议做为应用层协议的优势，感觉上你在把 http 当 tcp 来玩

@lesismal
把动词放到路由上基本都会遇到名词和动词混淆的问题，这个很恶心；
符合 RESTful 的设计更加便于理解，虽然私有 API 可以依靠完善的文档来弥补；
至于你说 POST200 更省资源这就有点扯了，都 application/json 你跟我说省资源？？？

@iseki
> 至于你说 POST200 更省资源这就有点扯了，都 application/json 你跟我说省资源？？？

我没太懂，"我说省资源"，是指我在哪一楼的来着，我全页面搜了下这个帖子里只搜到你这一楼“省资源”这几个字了

@TossPig

> 看了半天，也没找到你前面提的三元问题

"Method + 路由 + 参数"

#86 #88 网页回复，没编辑那么细致，之前没叫三元

另外，我自己项目和熟悉的朋友的项目里，oost + struct body 挺多的，restful 的反倒没怎么见到

不知道为啥吵吵。。 其实就一个点，内网机器，看和甲方沟通场景，面向公网的，没得说，只能 get post ，鬼知道客户会用啥子防火墙。这个就和 User-Agen 一样了，有历史背景。

@skinny @hack

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

前面回复的太多了，这会也快睡觉的时间了，就不挨个楼去整理了

我前面还说过好些人断章取义，望文生义、无论据式口嗨、看都没看懂上来就怼，你们对待技术真是够随便的，我得庆幸还有很多不随便的人。

@lesismal 抱歉，这个是我看串了，你没说这个省资源，你说这个省心智负担。
我倒是觉得复杂度是不会降低的，只是在不同的形式间转换，现在流行的 RESTful 风格借助 HTTP 动词表达的语义，你用 RPC 风格一样要 CreateXxx UpdateXxx 。只是前者和 HTTP 结合的更好，也更容易被生态接受罢了。
权衡利弊，现阶段 PUT 都会出问题的系统基本上很少见了，个人认为大多数情况下拆掉这些过时的规则没什么问题。

@xfriday 是的呀，怎么了，我也是被你们各位上来就口嗨给逼的呀，只能这种戏谑点方式和心态防止自己被气坏啊，所以请多理解，而且对认真聊技术的人我可是没这样说话的呀。。

@iseki 嗯嗯，能保系统是第一位的，其他的慢慢演进吧，每个团队每个人都有自己的设计审美，而且是否流行与是否主流与是否优雅也通常不是绝对正相关的，大家能赚钱、能有朝一日全民不卷就好。

辛苦攒的 v 币，今天消耗了太多，怀疑一些层主上来就口嗨是过来骗我 v 币的，真是坏得很呢。
这个帖子不想再扯了，睡觉了，晚安各位。

@lesismal

认真看了#88 突然有种恍然大悟的感觉

web 其实提供了这么一套方案，叫 websocket 。只有一个方法 get ，初始化 token 通过 header 传输
然后，，，嗯，，，，[狂笑]
对比 http 那 9 种方法有诸多优势，及时性，有状态，可以发送 binaryType

@TossPig HaHa ，其实我一直想尝试下 JSONRPC over Websocket 的，但迫于这东西不管是穿 CDN 还是生态和缓存都有缺点

能用 POST 不让用 PUT 就是掩耳盗铃

甲方就是这样的了，客户还说 80 端口不安全，要用 443 端口，只懂关心端口号，不关心走的是什么协议 [doge]

@TossPig @iseki
刚洗完澡头发还没干，所以又来补一波。。。

其实相比于 RESTFull ，post+struct body 方式的路由也好、参数也好（甚至路由也放到 body struct 字段里，但是比如 nginx 日志之类的不友好、需要插件解码再日志才行），更统一，比如参数，不需要再去 header 的 kv 、form 或者 body 各种地方取，而且写法上，以 go 语言为例，一个 ctx.Bind(&args)，后续的参数就都可以是结构体字段，干净得很。有的人喜欢省事用 map 类型，然后取到 interface{}再解析，这种不推荐，理由跟强弱类型语言做工程的优劣类似，而且项目足够规范，就应该协议制定阶段定好类型，然后就都很规范干净。当然，不同语言，强类型、弱类型、还有 java 这种带注解的，对于这种方式参数使用的便利未必一样。但至少在 go 和其他一些语言领域，或者从设计、获取参数来源上，确实是简便了一些的。而且 RESTFull 多种方法相关的，我前面说路由命名一样能解决，RPC 也一样的道理，如果命名解决不了，那 RESTFul 也未必能解决的了、只是增加一个维度的复杂度而已。

一些传统业务，社区已经既有很多成熟的解决方案，比如企业级、电商、管理后台系列、金融相关的很多，还有一些语言优势领域比如 PHP ROR 各种擅长的中小项目领域，这些成型的成熟方案改造使用 post+struct body 没什么必要，或者像楼主这种，公司已经形成了比较统一的项目规范，改个另类出来反倒增加团队负担，也没必要。
但是近年的一些新项目，尤其 go 语言这种，因为没有历史包袱，主流的框架以及相对中等以上水平的团队，很多都会选择 post+struct body 的方式。所以之前其他楼一些同学说我应该跟上时代，我都觉得他们有点说反了，可能他们才是没跟上时代吧 :joy:

另外关于 websocket ，我这有个 go 的 rpc 框架，支持 websocket 作为 transport 层，而且不只是 rpc ，可以服务端主动发消息给客户端，可以避免线头阻塞，可以乱序响应，而且能够支持更多业务场景比如推送、IM 、游戏等等：
github.com/lesismal/arpc

go 的 rpc 框架里，性能我不敢吹第一，但哪个框架说它第一的话我也不服。。。这有一份相对客观公正的 go rpc benchmark：
github.com/micro-svc/go-rpc-framework-benchmark

这里有个 websocket 聊天的简单例子：
github.com/lesismal/arpc/tree/master/examples/webchat

如果各位有兴趣玩 go ，欢迎多多交流

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

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

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

@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.

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

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

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

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

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

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

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

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

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

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

@lesismal

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

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

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

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

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

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

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

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

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

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

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

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

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

@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 方案为什么好用。

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

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

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

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

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

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

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

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

@lesismal 所以，现在说的这些问题还普遍存在么？如果不存在了，PUT 是不是就能用了呢

@leeg810312
#88 #178
这些，你能看懂吗？知道我在说啥吗？能读懂我的观点、论据、对比说明吗？知道你自己在曲解、驴唇不对马嘴无论据口嗨吗？

> 你的回答是不是趋势不一定对，主流不一定好？看来你是权威，只有你才能决定什么是对，什么是好

#132 里我回复过你 “流行不代表就是主流，即使主流也不等价于最优”
看准了，“”主流也不等价于最优“，这句话你就推断出 “主流不一定好”，“好”跟“最优”是一码事吗？你了解除了 HTTP 之外的各种协议吗？知道其他各种领域各种场景各种协议为啥不直接用 HTTP 吗？知道 HTTP 这么 “牛逼” 为啥大家还要搞 RPC 还要搞 Websocket ，为啥其他不受浏览器限制的还要直接 tcp 自定义协议，还有很多为啥要 UDP ?
知道 HTTP 1.1 主要解决了啥吗？知道为啥还要继续搞 HTTP 2.0 、2.0 解决了啥吗？知道为啥 HTTP 2.0 还没普及就 HTTP 3.0 标准都基本达成一致了吗？知道 HTTP 3.0 为啥用 谷歌 QUIC 知道为啥要基于 UDP 吗？

你眼里的好，是因为你接触到的技术范围就局限在你熟悉的 HTTP 周边小范围内，并且你只是使用者，自己没做过这些基础设施没思考过当下所用之物有哪些缺点、不足、不能满足哪些需要、可以做哪些改进优化，所以你都不看我在对比什么。别跟个井底之蛙似的

#132 回复你的我再贴一次：
"所以这些楼层下来，相当于我在说 A 不如 B ，并且我解释为什么 A 不如 B ；然后你们就说你们在用 A ，你们给大厂的方案也是在用 A ，云厂也在用 A ，驴唇不对马嘴地怼我呢，多数都没怼到我聊的点上，也不提一些论据“

@pkoukk
我也没说过不能用啊，说几句不好，大家就都觉得我说不能用了 :joy:

看下 #178 和多几个楼的回复

大道至简，post 能干的事情还搞一堆 PUT/DELETE 干啥呢，是工作不饱和还是闲的蛋疼，你看看淘宝，腾讯等公开接口文档，哪个不是用 get/post 的，有几个做了 RESTful 。

> 现在有点趋势上的包袱反而在前端，当年历史原因这套系统选择了 angular 作为底层框架，进新人特别慢，上手 angular 确实需要两周的时间，现在国内几乎是 vue 的天下

这确实了，前端历史包袱也重

> Websocket 这东西，一直没怎么用起来，看过有有人用 Websocket 写的 bbs 项目，各种原因也没推广开，没测过，但是有状态协议，对服务器的压力还是比无状态大的

有状态的协议，实现复杂度比 CURD 要难得多
性能压力未必更大，因为有的需求，如果用无状态只能轮询，轮询的压力更大，得按实际场景对比
另外就是，复杂些的需求，无状态真的搞不定，所以才会额外要搞 RPC 要搞各种自定义协议，这也是我不喜欢 HTTP 的原因之一

道不同不相为谋，时间会证明一切

换个工作然后就不用管这个整改了，多省事。还有问题访问我的用户名站点吧

我们除了静态资源，其他一律 post ，如此一来，前端后端运维都皆大欢喜，早点下班，岂不美哉。

有些系统内，是只允许 post 和 get 的，这个还是得稍微注意一下

@lesismal 这就是不同的团队自己的选择了，你要把 HTTP 当应用层协议用，那就严格遵守 RESTful ；你要把 HTTP 当应用层协议的承载者用，那就意味着整个生态里，从头到尾所有的问题都需要自己解决。

HTTP Methods 在流量上体现就一个单词的区别，要不要遵守语义是服务器的选择

接受一部分语义，然后说其他语义不安全，很难不笑出声。有这本事应该去把 GCP 、AWS 、Azure 、阿里云、腾讯云、百度云等大厂的 RESTful API 给黑了

客户提出这种问题，我只会解释一遍。如果客户坚持 PUT 就是不安全，我就知道是对牛弹琴，内心吐槽一句傻子，把他列为能用概念忽悠的高溢价非专业客户，二话不说，按要求做兼容，后续需求提高报价

@eason1874 正解

@lesismal 我的项目里也全部都是 post + json 只有 /version /health/live,ready /swagger /metrics 这几个固定的 path 是 get 其余全是 post. 很大的原因是不想前端天天问我为什么接口调不通. 他们一天到晚随机 contentType 和 method 调接口 然后问我接口有问题

远离 restful ，拥抱 RPC 吧，get ，post 一把梭。

@eason1874 优解。另外，接口风格这东西，自己咋方便咋来，团队舒服就行。

> 接受一部分语义，然后说其他语义不安全，很难不笑出声。有这本事应该去把 GCP 、AWS 、Azure 、阿里云、腾讯云、百度云等大厂的 RESTful API 给黑了

我真是佩服你们这些人断章取义、拿出别人观点中的一部分词进行曲解的能力

之前的好几楼我已经都说过了，这时代电子产品多眼睛容易疲劳，视力不好建议多做做眼保健操

@buffzty 所以说，用过的人直呼内行！

就技术而言，他们虾扯蛋。就实际工作而言，看博（撕）弈（逼）结果吧。

可以问一下是哪家防火墙吗，说英文名的最后一两个字母我就知道了。如果是相关的话可以协助反馈处理一下。但是 PUT 这个方法开启没有问题，有问题的是你做没做检测和鉴权，如果做了，你完全可以直接怼回去，脱离业务谈安全就是瞎扯。

一律 post ，如此一，前端後端都皆大喜，早下班，不美哉。