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

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

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

@skinny @hack

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

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

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

@TossPig

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

"Method + 路由 + 参数"

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

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

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

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

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

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

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

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

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

——————————————————————————————————————

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

@buffzty 汇编多平台也是耗神，而且不是做外挂、安全之类的没什么必要再搞了，绝大多数服务也不需要汇编级的优化，偶尔需要也是看看汇编代码琢磨下高级语言本身的优化写法，所以也是不打算了，linux net 本来也算熟。我列的两个项目一个是能支持更全面业务场景的 rpc 框架，不像其他 rpc 框架那样只能局限于 rpc ，还可以做推送、IM 、游戏之类的；另一个项目是个异步网络库，相比于其他的 golang 异步网络库，性能不低于任一，并且支持 tls/http1.x/ws ，其他异步网络库除了 gev 支持简单的 ws ，都不支持这些。这两个项目都算是 golang 领域里别人没有做好的。代理爬虫 web 框架也都是遍地，我的异步网络库 nbio 还基本兼容了标准库，所以比如 gin/echo 之类的这些都能够使用 nbio 作为网络层，然后能够节省大量协程数量和内存开销并支持单机 1000k 这种、不会像基于标准库那样协程数量爆炸、内存爆炸、调度和 gc 成本高、STW 。
这两个库目前也算版本相对稳定了，所以想找点其他好玩的又不至于消耗太大精力的，实在无聊的时候就读读其他好项目的源码了

> 找你这么说，用 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
我对号入座一下，至少我没这么说过，不安全也是有场景的。如果擅长断章取义、望文生义，请自便。
如果我对号入座得不对，请无视。