@smilenceX 他是说旱厕和现代下水系统的区别。
看你能不能接受夏天味道特别冲并且低头看到的是一片白茫茫蠕动的蛆，
冬天则是地面上尿水溜冰+是真·屎山，坑旁边是垒的砖头，这样才能你踩着砖拉不沾到屁股上。

当然也有可能是安全问题

有些旱厕直接就是一个大坑上搭个木板，站上去心惊胆颤，还有些真的旱厕连着猪圈，你对着坑下面那个长着大口活物非常害怕生怕它顶你一下。

我可以决定的项目里我会禁止引用 hutool 或者只引入核心，因为 uuid 和雪花 id 确实省得自己写了。

不想引入的原因很简单，同样一个 StringUtil ，存在以下选项的时候 spring,commons-lang3, guava ，commons-lang ，hutool 的时候我选择大厂背书或者社区核心维护的库优先于 小众群体维护的库不是很容易理解吗。

写代码连尽量不堆屎山的追求都没有，心态就是混口饭吃，那你不论干哪行都是咸鱼，当然了，当一天和尚撞一天钟的人也许才是大多数。

至于公司项目，不归我做主，我也没必要非当事逼逼着同事改代码，那爱咋样咋样，领导有追求我跟着干，大家都无所谓我也不逆势而为。
所以公司项目引入乱七八糟，上面那几个同功能的库都有，有的甚至会由于依赖导致重复引入了同一个库的不同版本，那就引呗，再加上有些同事自己攒了多年自己写的工具类，以及接入某写 SDK ，人家示例代码里的 util ，五彩缤纷。

40%、50%的失业率，各位可真牛逼说这话的时候都没过过脑子，老美大萧条时候都没这么高，到这数了还没有遍地造反那只有两种可能：
1 、剩下 50%的就业人口全部都是秘密警察，时刻监控这些失业的。
2 、智械时代来到，人类靠剥削机械产出已经可以完全脱离任何工作，还在参与工作研究的都是自己兴趣爱好。

后面有哥们解读说人家原文指的是初入职场的新人的就/失业率，那还有可能，因为现实环境确实很恶劣，但即便 16 年不恶劣的时候有一说一这个青年失业率估计也不低，
我同学朋友里头学文的、学机械、学化工的都大部分找不到满意的工作，最后一大半都转行了，学的和干的完全无关系，而且有时候还会多次转行跳槽，我感觉好像这个才是常态，只有 it 、金融、警察军队等少数几个专业毕业后找专业对口工作的人多一些。

@baiyi 你不回最好，减少了这个世界上的无用信息和戾气。

要不是后面另一个哥们指出了我的错误，我缓和了一下心情给他先点了个赞，我也不可能维持一个好心情给你也施舍一个赞。

@Mac0ne
你提到的几个方法里，OPTIONS HEAD 这些几乎标准后端默认都支持，但你说可以用来 DDOS ，那 GET 不也一样可以，而且效果还更好。

PUT 、DELETE 、TRACE 又都不是标准 http 服务会默认提供标准行为模式的方法，甚至老实说 TRACE 我都实际当中没用过，许多 http 软件都完全不支持这玩意。

不要觉得全世界所有人用这几个方法都是去搞 WebDAV 服务了，觉得这几个会影响安全，那只能说你们运维是真的水。



我们项目有以下几个接口，麻烦你分析一下哪个会产生篡改数据的风险，哪个会产生数据删除的风险，哪个会影响服务器上的磁盘文件：

DELETE /api/users/{id}
PATCH /api/system/info
PUT /api/stations

如果这几个接口有风险， 那请问，以下接口为什么在你的认知里就是安全的，当然如果你认为以下接口也不安全，那麻烦给出整改意见：

POST /api/delUser?id={}
POST /api/system/updateInfo {a:1,b:2}
POST /api/station/addStation {name:'xx',desc:'abc'}

非要保证递增，那就只能使用锁或者单独的 id 生成服务，以并发的代价来保证 id 生成同一时间唯一。

@baiyi 你说的对，还是你理解深入，给你点赞

@baiyi 这东西不是百度谷歌随便一搜就找得到么

https://www.ruanyifeng.com/blog/2011/09/restful.html

https://datatracker.ietf.org/doc/html/rfc4918


restful 作者只是提了一个想法，但没有形成什么明确的规则协议，所以关于 restful 的细节大家各有各的理解，因为最初的作者就是论文里笼统一说，不像 graohQL 。

而 WebDAV ，这玩意出现的不算太晚，但最初人家都是自己客户端和服务通信的，只是基于 http 协议了而已，这样不安客户端的用户也能查看，它和 gRPC 一样，属于特定领域在 http 上实现的私有协议。
WEB 主流世界用不上他们这功能自然支持情况很差，尤其是后端，这是 spring 官方有我提到的那个拦截器的原因，因为在 restful 火起来的同时期的 tomca 7 吧还是 8 都还不支持 PUT 请求。

楼主的问题我们也遇到过，但你们的 QA 估计就只会背八股文，知其然不知其所以然，实际上是 WebDAV(对小白)不安全。
restful 是 作者发现人家 WebDAV 搞的这套 http method 很符合他的想法，所以复用(偷)了他们定义的 http method 而已，仅此而已，实际两者没什么关系。



而安测会将这个提示为风险的实际原因是针对小白的规则拦截导致被 AOE ，根本原因是有些小白用 IIS 或者其他一键脚本开启了 WebDAV 服务但没做鉴权，效果就和允许匿名的 FTP 服务一样，导致文件被脚本小子加密或者删除。


我们是某个合作的甲方人家找的安测出的报告里包含 “中风险漏洞: 使用 PUT ，http method”, 不过人家给的报告还包含里处理建议/参考， “打开服务设置，选择 IIS 服务器，关闭 WebDAV 服务”，所以我们一看就明白了

另外我们的要求只是高危漏洞必须处理，其他的可以商量，所以我们就解释说明了一下就 ok 了，如果你们的安测是甲方
的而且道理说不通，要求必须按规定，按他们原有的测试脚本，那你只能投降了。



-------------------------------

最后如果楼主只能改了，那也不算非常麻烦，spring 有个拦截器可以把 POST( "xxx/api", {"_method":"put"}） 转换识别为 put 请求，这样整体后端代码就不用改了。
前端呢也可以将 http 工具再封装一下， 把其他 method 改成 post + _method 参数的方式。

@vtgoal 主要搞得就是大公司的发行版，同行拿起我的筷子来抢我的饭碗，小公司还有个人你修改优化了一个半个软件，人家地主家大业大还真不一定看的上。

我一直很好奇 楼主提到的 2 ，红帽的限制分发到底是怎么办到的，能直接禁用别人构建还不触犯 GPL 协议。然后翻看了半天大家的讨论还有 外国用户的说法，最终结果确实如楼主所说，但中间原理完全不一致。

由于 GPL 限制， 红帽必须给客户二进制的同时给客户源码， 同时无法限制客户使用源码修改和重新构建，所以实际上客户是可以自行编译构建再分发的，它做不到禁止客户构建。
但是，红帽的销售协议和 GPL 是不冲突的， 它可以规定当你通过源码重新构建并提供给其他用户后，你就违反了红帽的销售协议，你依然拥有当前版本的二进制和源码，但红帽的售后支持(服务)会自动终止，你将无权使用后续更新的软件和源码。

也就是说如果 rocky 购买了 RHEL 9.0.17 版本的授权， 然后通过源代码构建后， 这是意味着当前销售合同中止作废，rocky 再登录 redhat 官网只能下载，9.0.17 版本， 如果下载 9.1.45 这类版本的二进制和源码则属于盗版行为，redhat 就可以起诉你。
所以要么你从你购买的哪个版本的源码开始继续自行维护更新兼容，要么每次升级你都来买一份再分发给别人。

有一说一操作挺骚，但确实好像和 GPL 不冲突...

讲道理的基础是你讲的东西是对的，并且你有能力转换成孩子能听懂的例子。

所以讲道理最好还是能简单进行换位思考的，比如：
“假如明天哥哥来咱们家作客的时候也像你一样抱着人家的玩具要带走，你说爸爸妈妈该送给你的哥哥吗？”
而不是，
“假如这 100 块零花钱是给你哥哥的，他就会拿去买美术书学画画，而你只会买玩具车，学学你哥哥，认真学习才是孩子真正该干的正事”

并且你自己也需要是个言行一致的人， 你开车的时候说“假如我是路上这个人，我一定不像他这么瞎，不懂得躲车”，然后你走在路上则变成了，“这些傻逼司机连礼让行人都不懂，真尼玛没素质”。


最后，还有不少人说的 “讲道理” 是和 “父母独断转型不考虑孩子感受意见” 对应的。
对于这种事，也是需要分事情以及考虑表达方法的，
错误的表达：
“xx ，爸爸妈妈想给你添个弟弟妹妹好不好啊”
“xx ，我们家是买 suv 好还是 mpv 啊”

正确的表达：
“xx ，你觉得爸爸这样做 xx 对不对”