@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 的问题相对明显，并且这两个方法并非不可替代、禁用它俩用其他简单方案替代成本也不高