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

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

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

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

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

@eason1874 未读提醒里没有你的回复，所以才看到

> PUT 方法和 Nginx + PUT 组合在云厂商的服务里多得是，配置类 API 大量使用 PUT ，对象存储上传文件也用 PUT ，CDN 既用 Nginx 也用 PUT 。自认能“快捷简单地入侵”的快去 SRC 提交漏洞，有这本事拿个几万美金奖励轻轻松松

专用场景用来对比安全部门的通用场景合适吗？ PUT/DELETE 跟 POST 存在上传、删除资源的区别，代理也有不同的 api 、文件服务，能都统一处理吗？而且，我之前楼提到过了，就算按路由配置放行策略，开发、运维、安全部门耦合，这样好吗？并且 POST 替代 PUT 成本很高吗

你举例子的，比如特定厂商的特定的服务或者业务，比如上传配置，接口做好了处理，比如对象存储基本是内部服务代码内网调用的不对外开放的所以也不怕，但是跟通用场景两码事，我好几个楼解释了很多，不只是 nginx 是否可配置、怎么配置，不只是接口代码可不可以处理，还有工程、跨工种协作上的，还有 HTTP 协议本身的

如果都考虑自己眼下这点代码逻辑，那倒是万事大吉。

@TossPig
"那 http1.1 设计就太冗余了" ——事实就是这样子的，不只是 http1.1, tcp 、http2.0 都有缺陷，互联网创世年代摸石头过河，都可以理解，但不好或者不够好就是不好或者不够好。

@kksco 这个领域我不熟悉 :joy:

@FakNoCNName
> 这个用法也能用，不过看起来就像说： http 、mqtt 、mysql 、redis 这么多种协议让人头疼，结构复杂、数据容易、还带来了设计的复杂度，我们就全部用的 TCP 流，内部定义一些字段区分不同含义。

层主可以多了解一些类型的项目，这世界上不是只有 http/mqtt 之类的这几种协议，有太多自定义协议了，只是因为自定义协议多是自家项目、不会形成广大社区、行业的这种 RFC 级别的协议规范，mysql/redis 其实就应该归类于非广泛社区的协议，同样地，它俩也不需要 RFC

> 复杂的工具（ RESTRull ）是为了解决复杂问题，一代代人总结整理出来的经验，你不能说自己目前这么干够用就认死了只这么干（ post+body ）。
> 我们就尽量按照 RESTFull 设计接口，用起来没觉得复杂，查接口、查日志也方便，开发功能、定位问题等等分类也比较合理，如果现在让我们全都用 post ，接口多起来以后简直要吐血。
> 如果把 post+body 比作 txt 文档，RESTFull 就跟带标签的 PDF 或者带目录的 word 一样，一两页资料看不出差别，几十上百页呢？

确实需要复杂的基础设施的地方，我也会用，我并不是反对复杂的东西。
我是反对本来可以简单解决的、却把问题搞复杂了。
比如你说的查日志，并非必须 Method 才能搞定，路由分段一样可以解决，比如 /aaa/bbb/...

我上面一楼也有补充的，协议交互主要就两点，而 路由 /命令 这里，我也没限制只能一个层次比如只能 /aaa 不能 /aaa/bbb ，这至少比 HTTP method/路由 /headerbody 各种参数要少了一元设计成本

另外，你的这种观念形成过程可能是反的：是因为从学习到使用都是按社区或者自家项目这样经历下来的，因为用并且用习惯了并且有人说它好、所以自己也觉得它好，可能没有尝试过自己从底向上设计这些基础设施的思考。就像我上一楼补充里说的，别人给你个轮子，能用，就觉得好，所以你对它的好的判断欠缺真正参照物来对比。

可以尝试下了解多一些类型的项目，或者自己自底向上设计基础设施，然后你就会面对这些设计上的关于美的丑的性能优的劣的各种细节考量，然后才能得出更全面的结论。

> 另外说的安全问题，这些早就没了，要说不安全也是使用的人没做好处理，跟什么方法没关系。

这个我前面楼层说过，安全问题不只是代码逻辑，安全还有很多工程逻辑在里面。很多场景都可能因为人没使用好导致安全问题，但是 PUT/DELETE 的问题相对明显，并且这两个方法并非不可替代、禁用它俩用其他简单方案替代成本也不高

@graetdk 没看懂是要搞啥，笔记、点子之类的记录本？还是把你的一些点子开发成产品？

我也攒了不少点子，但都是商业相关的，我更爱技术一点，所以一直懒得动手 :dog:

本来交互协议主要两点：
一是路由，RPC 里叫方法，有的游戏为了节省流量和性能会用数值类型、叫命令号之类的，各个领域自定义协议的项目叫法都类似
二是参数。

之前楼写完上面的落了几句，补充上：
本来简单化一和二就搞定的事情，HTTP 协议非要搞成 Method + 路由 + 参数 三个层次，而且参数还可能有 header 里的 kv form ，还可能有 trailer 的 header 、body ，body 还可能 content-length 或者 trunked ，考虑到社区、历史、兼容因素，可以理解这样的做法。但是你说实际上这协议好不好，我是真没法说好。

饿殍遍野难民潮的时候，富人家施舍点粥米穷人都觉得香。
自己技术积累不够的阶段，社区、别人随便给个能用的轮子就觉得好用、牛逼。

美好的事物不能普遍占据主流——这才是主流的现实情况，劣币驱逐良币的历史故事和当下正在发生、未来也会不断发生的事情都多了去了，都是什么天时地利人和、顺应时代、场景者得天下罢了。

但美，仍然是美。

@debuggerx
> 达克效应：越无知的人越自信。

提出这句的时候也可以先送给自己，思考下自己是否听懂了别人在说什么。。。

> 总是有“高人”恨不得重新发明整个互联网。。。

第一，我没说过要重新发明，不是非要重复造轮子而是减少使用上的坑，少即是多
第二，我上一楼聊了点 http2.0 3.0 的，历史、社区兼容性占了很大因素，否则可能早就被优化了。考虑兼容，所以没法只能慢慢先从标准上推进、逐渐更迭，就像老龄社会一样只能等老旧项目自然死亡。
优化不意味着重新发明，而是软着陆，否则，如果不需要优化，你以为谷歌闲的蛋疼搞 quic 、社区闲的蛋疼接纳 quic 并且成为实际的 3.0 ?

拜托楼上某些位大神夸人或者讽刺之前先多了解下技术本身的点，比如 tcp http 协议的实现、历史时期的局限、有那些缺点、以后的优化方向，而不是只看眼下大家都这么用就跟着一块用，人云亦云不知所云也就算了，至少拿出点你们的观点、论据好吧，有论据 vs 无论据口嗨，我嫌累了

另外再跟你们说吧，我自己的 api 类项目里，连 GET 都不用的，统一 POST+结构化 body(json/pb/msgpack/...)

本来交互协议主要两点：
一是路由，RPC 里叫方法，有的游戏为了节省流量和性能会用数值类型、叫命令号之类的，各个领域自定义协议的项目叫法都类似
二是参数。

HTTP 协议本身算是互联网早期产品，设计者当年也都是摸着石头过河，但因为整个互联网不是自家项目，一旦协议定下来，要考虑全网兼容性，所以即使是缺点也不好及时匡正。包括不限于本帖里说的 METHOD 安全性，还有比如 keepalive 之前的短连接、请求不带 id 无法向多数 rpc 那样可以乱序响应所以即使支持 keepalive 和 server side pipeline 了仍然有线头阻塞的问题，甚至再往４层说，tcp 也渣，４层本身也存在线头阻塞的问题，所以各位可以看到，为啥 http2.0 还没普及，quic/http3.0 都出来了并且更被认可，而 quic/http3.0 是 udp 的，可以解决更多问题。

@rust 我得谢谢你夸我牛，哈哈哈，这一点我认，，

@dcsuibian #77
不要只当成 api 接口服务，还有可能同一套 nginx 有文件服务，系统还可能有其他的风险，能减少一个漏洞的点就减少一个，能减少一点工种上的耦合就减少一点耦合（最主要的是 PUT api 接口完全不是不可替代的）

@dcsuibian
那 PUT 是不是多了一点被人上传恶意文件的可能？
转的帖子里有：
“恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上，所以 PUT 等方法对 nginx 来说是不安全的。”

至于黑客怎么玩，我不懂、不瞎吹。

如果说运维、安全人员、以及开发人员都对开放 PUT 的路由做好控制就没事，但就像我上面说的整个工程、团队协作各种耦合成本甚至审批流程，都提高了许多，尤其楼主这种好像还是不同公司之间的。

#74 如果不知道这个，那我能理解为啥好几位说没看懂了。

@dcsuibian
首先，你知不知道 PUT 和 DELETE 主要是可以用来上传和删除资源的 :joy:

@dcsuibian #51

> 这篇明显是有问题的，网上转过来也得自己思考下。
> 如果实实在在地打印过 http 请求中的内容，看过 http 的格式就知道 method 的最大区别就是第一行的格式。
>（ http 是基于 tcp 的，只要你把 http 请求收到的 tcp 内容打出来看看就知道了）

我还算了解一点 tcp 和 http ，我这有一份手撸的 golang poller tcp 框架，支持了 http 异步解析，其中包括一份完整的 http parser：
github.com/lesismal/nbio/blob/master/nbhttp/parser.go

> 什么叫“从 Java 代码的角度考虑问题”？这跟什么语言都根本没关系，是 http 协议的内容。
> “在研发的代码里，终端（浏览器或客户端）过来的流量，最终通过 java 的注解，携带参数进入到了研发写了一个
> 方法里来了。”写这篇文章的人，明显就是直接上手 spring boot ，连基本的 http 协议都没了解过。

不管是不是 spring boot ，我都没出来你说这篇文章明显有问题是指什么问题。那篇文章作者的意思是从运维、安全部门部署的网关 /代理软件的层面不能允许 PUT/DELETE 这些方法，而从开发的层面不管什么 Method 都能拿到相关参数进行验证。
“这跟什么语言都根本没关系” —— 这句是对的。

> 至于什么 nginx 会遇到问题，那就去配啊。

nginx 的问题，，
我转的帖子的作者的意思是不同部门 /工种在整个工程实践的不同层上的安全考量角度，这跟用什么语言或者 java 用什么框架没关系，甚至 nginx 怎么配置都不适合这么实践——这一点我在上一楼（#43 ）回复前面小哥的内容里面也提到过了，层主也可以看下

蹭住也可以多思考下，然后再看看我是不是转帖时候没思考 :joy:

@ryd994

> 用于 Web 服务的 Nginx 为什么要带 dav 模块编译？各大发行版的默认 Nginx-minimal 就是没有 dav 模块的。你为什么编译的时候不可以关掉

人家原文里说：
```2 、为什么说 PUT 、DELETE 是不安全的方法？
对于 nginx ，可以使用 HttpDavModule 编译 nginx （./configure --with-http_dav_module ），开启 PUT 、DELETE 等方法。开启后，恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上，所以 PUT 等方法对 nginx 来说是不安全的。
```

这意思没说默认就有 dav 模块吧？也没说默认就开启吧？人家这意思说的就是默认不开启、如果需要开启单独编译吧？所以你要不要再自习看看 :joy:


> 其次，Nginx 的 dav 模块是需要 dav_methods 指令开启的。还可以根据不同路径使用不同的设置

你有没有想过今天给你开一个特殊的明天给他开一个特殊的，安全部门还得维护各种，开发与运维、安全人员耦合，而且毕竟留了口子，哪天不小心、或者包括人员离职交接、新功能上线导致纰漏留了漏洞等情况？而对于开发而言，统一协议规范、提高这点安全标准并不费多大事，为什么要为了开发自己的便利去与更多部门产生工程上的耦合？代码讲究高内聚低耦合，但代码是服务于整个工程的，工程思维要考虑整体，包括架构、运维、安全相关的部门协作等各种，只考虑自己方便不是一个好的努力方向

而且，我上楼转那个帖是为了说明 PUT 不安全相关的问题，所以，nginx 编译方案并不适合作为安全问题甩锅的理由


> 自己不会配置 Nginx 还要怪 restful 不行？

抛开 nginx 不谈，restful 就好用吗？
1. 真实项目里有多少人在用真正的 restful （只是用了各种 method 就以为是 restful 这种不算）？
2. 有多少人真正理解了 restful ？不怕各位笑话，我就没太懂，因为搞得太绕太复杂，要理解它所谓的精妙设计就要不少心智成本，就像有人讨论说的，它跟 OOP 一样存在过度抽象的问题，需要前期消耗很多顶层设计、预先设计的成本，我只是人云亦云、具体我是不了解了，因为好的东西讲究大道至简少即是多，这种搞一堆套路定义的东西、把本来可以简单的问题复杂化，看半小时还没入门、让人云里雾里的东西，我默认它是垃圾。
3. 虽然我不真的懂 restful ，但是可以简单对比下 restful 和 GET/POST+结构化 body 的方式，最简单的思考，restful 不仅多种 method 要仔细设计，仍然也需要 body 参数的结构化设计，而 GET/POST+结构化 body ，省去了 method 设计这块的心智成本，哪个更简单省力？另外，抛开 web 领域，其他服务器领域，命令号 /路由+结构化 body 到处再用，IM/游戏 /分布式系统内部 RPC 交互，也就 HTTP 这垃圾协议早期设计者内心戏太多搞得这么复杂，号称的文本协议可读性好都是扯淡，即使二进制协议，浏览器或者其他工具转换一道可视化出来也不是啥问题，但对于整个互联网流量、算力会带来巨大的节约，相应的也是巨大的性能提升。早期的用户量小，这点协议复杂带来的成本不高，现在都互联网爆发的时代了、大数据的时代了，HTTP 协议的复杂性带来的能源消耗都是不小的开销，只是历史包袱太重没法随便切换成更高效的协议，我目测相比于更高效的二进制协议，它浪费的能源甚至不比挖矿少。

所以，是大家 “怪” restful 不行还是它真的不行？

@XTTX mattermost 很 slack ，我也先收藏个，谢谢！