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

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

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

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

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

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

@rj15295774336
socket.io 用的人太少了，而且 websocket 足够用了

@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: 是我觉得比较能不互相刺激的表情，但是发不出来，各位脑补好了

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@cxe2v
是啊，解释这么多，真心累，好多写 curd 的人舒适区里呆久了，就不乐意把自己提到高一点的层面看问题，但凡高看一点，就不至于停留在 "程序员 /码农" 的水准，至少能搞个 "架构师级程序员 /码农" 的水平。
太多从业者都只考虑眼前这点，真的是不配叫工程师了。

@leeg810312
你如果有兴趣辩，可以把我回复的多楼层都看一下，先明确下 带上传 /删除文件的服务和 api 的区别、通用场景包括比如安全部门的需要与你说的云厂 api 的区别，你的云厂 api 自己处理好了那是你云厂自己的事情，所以云厂 api 就代表通用全场景了吗（比如这个帖子说的安全部门的需求）？

其他的，工程逻辑、多工种与部门协作，如果你只站在 curd 这种层次考虑问题，我前面楼层已经包含了的一些基本点你们都不看，那烦请不要跟我继续辩了

@lance6716 go-mysql 这个库我自己项目也有用到过一些，我主要精力不是数据库方向，暂时不知道我能对这个做些啥。
看了下 issue 列表，如果是 mysql 功能性的，这感觉有点需要补课