@ivvei #88 咱不杆哈

①部分修改那里，我把 Method 打错了，应该是 PATCH
②我不知道前面那里那个地方五花八门了。拿我们自定义的 action 部分来说，我们至少保障 action 是一致的，想搜索数据就调_search 接口，比如：

- POST /Datas/_search
- POST /Hosts/_search
- POST /BusinessSystems/_search

再比如，我们所有软删除数据接口，action 都是_markDeleted ，不会 A 叫 softDelete ，B 叫 softRemove

- POST /Datas/{id}/_markDeleted
- POST /Hosts/{id}/_markDeleted
- POST /BusinessSystems/{id}/_markDeleted

/some/resource/path 只是想表达有些 action 是在数据集上，比如/Datas ；有些 action 是在单个数据记录上，比如/Datas/{id}；甚至有些 action 是在子数据上，比如/Datas/{id}/SubDatas/{subid}。

哪里五花八门了？

你不会看到/some/resource/path 跟/Datas 不一样就觉得五花八门吧……

我通篇都在强调统一一致的范式，而不是在强调就应该采用跟我一样的思路。我不在乎范式是什么，我反对前后不一致，没有任何规则的 POST 而已。

“不要说别人就五花八门，说自己就是合理约定。”你这么说不就想说别人双标嘛……还真不是……

今天想起要回这个贴，是因为上周我手下的人刚别其他项目的接口坑了一下。他们告诉我的人，要换个接口，返回的数据字段没变。我的人就去换了，因为对方说接口一样，数据字段没变，他们就偷懒没验证。结果上生产就出了个小问题，因为数据有个字段结构不太一样……

同一个字段，有一个接口是返回逗号分隔的字符串，另一个返回一个字符数组……理论上，同一种数据，不同的查询场景，返回的数据字段结构没必要不一样吧？这才是我强调的五花八门。

然后，我在自己项目的开发群里强调了范式规范，不知怎么发图片，直接贴我说的文字：

理论上，接口再垃圾，只要我们验证充分，问题肯定不会到生产上。
就算接口不好，最多也只是在开发阶段被坑，影响你的研发效率而已。
冤有头，债有主，谁坑你就去怼谁。
我以前经常跟你们强调，字段命名要前后一致，严禁五花八门，最近几次缺陷就是典型的案例。质疑别人前，我们自己要先做到这一点。

注意看， [质疑别人前，我们自己要先做到这一点。] 我们对自己的水平心里有数。

大家是不是对 Restful 有什么误解，Restful 多出来好几种 method ，是 GET/POST 的超集，不存在能力比 GET/POST 更弱吧？

我维护的项目，采用 Restful 协议，迭代了好多年，没发现有什么坑啊

比如，一个资源普通的增删改，能有什么问题？

POST /Datas # 新增
GET /Datas/{id} # 查询
PUT /Datas/{id} # 修改（整体替换）
PUT /Datas/{id} # 修改（部分更新）
DELETE /Datas/{id} # 删除

对于特殊的业务逻辑，我们约定好一个在某个资源上做的一个动作，范式如下：
POST /some/resource/path/_action

举个例子，我们想让数据支持软删除：
POST /Datas/{id}/_markDeleted # 软删除（打标记但数据不删）

再举个例子，搜索数据集合，Body 传一个 Filter （比如 Name 符合某个正则表达式）：
POST /Datas/_search

{
"Filter": {
"Name": {
"$regex": "abc"
}
}
}

最后一个例子，某条数据记录想发一条通知出来：
POST /Datas/{id}/_notify

迭代了这么多年，没发现有什么所谓的业务逻辑套不进去的问题啊。

还看到一个说法说，Restful 需要写好多个接口，然后再让前端来整合？这不是典型的接口 [粒度] 问题嘛……

站在后端的角度，接口粒度合理拆细是可以，难不成来个场景你加个接口刷一刷存在感吗？别人我不知道，我对手下的后端的要求就是合理地细，让前端可以灵活组合完成特定、个性化的业务场景。

站在项目统筹管理的角度，如有某种组合很常用，你让前端自己一遍遍地去拼接也不合理吧？这个时候不就提供一种粒度更粗，但更固化的接口出来吗？这样双方不都得到满足吗？同样别人我不知道，我对手下的前端的要求，就是接口不合理，需要不断重复组合的逻辑，就要反馈给后端。然后一起消除重复性。

总结：①后端接口粒度在合理的前提下，尽量细；②对于常用组合，再封装更固化和个性化的粗粒度接口。

还有一个问题，说前端框架封死了只能 GET/POST……挖槽，前端垃圾关你啥事？关 Restful 啥事？能 diss 他就 diss 他，不能 diss 他的就捏着鼻子接受吧。

还有人提到，说客户公司只允许用 GET/POST ，怎么说呢？都做乙方了，当然没办法了，甲方说啥就是啥……但这是你还是有办法在 POST 方法的基础上，自行定义一套给 Restful 类似的协议，无法是把原本用 Method 来表达的信息搬到 body 里而已。举个例子：

POST /Datas/{id}

{
"Action": "UPDATE",
"Data": ……
}


因此，重点不是 Restful or GET/POST ，重点是接口要满足一套统一而且规范的范式。

我同意有人提到说 GET 、POST 是负责人不负责任的做法。就 POST 请求，然后 path 爱怎么定就怎么定，数据爱怎么传就怎么传，最终一定是座代码屎山。举个例子，我合作过的项目，就纯 POST 的，但接口五花八门。同一种数据，不同接口返回的格式有些字段名还不太一样，一不留神就被坑到。这就是垃圾。被坑的次数多了，别人就会抗拒跟他合作。

据我的观察，绝大部分程序员，特别是外包根本就没有驾驭抽象范式的能力。没能力也就算了，不少人还喜欢浮于表面，夸夸其谈。说到底，“无规则不成方圆”，这么简单的道理，我们几千年前的老祖宗都懂。但不少所谓的新时代开发工程师，还在重复着开发一个垃圾接口，再写一份垃圾文档来描述这个垃圾接口的死路。

https://fasionchan.com/network/ 几年前写的，又有段时间没写了……

真正信任对方的人，其实谁管都无所谓。

我们家目前就是这种状态，两个人各管一部分，投资渠道也差不多，大额存单和指数基金定投。她没提过要管钱，我也没提过要管钱。平时也会互相转来转去，比如要凑钱买另一种大额存单的时候。

然后我们共同维护了一个在线表格，统计各种账号的余额和负债情况。每个月 1 号都会一起花半个小时更新这张表格，表格自动统计出上个月的收支情况。没有可以要管理所有钱，但全家有多少钱，分别分布在什么账户上都是公开的。我们 care 家庭作为一个整体的财务情况，而不会去计较谁的账号钱多，谁的账号钱少。

我觉得这种状态挺好的，可以参考一下。

重点不是钱谁来管，而是钱的管理过程公开透明，而且双方的指导思想要一致。举个例子，一个人花钱大手大脚，一个人守财如命，多半还是会有很多矛盾的。因此，归根到底，还是要找到三观一致的人结婚，亦或者尽量磨合。

我家小朋友 1 岁多，现在在公司附近找了个托班，上班送过去，下班接回家。托班最小有 6 个月的，估计是双职工休完产假就送托班的。

我拔过一个长歪的，拔的时候有麻药没感觉，麻药退了之后就挺疼的，还发热请假了两天，但还能够接受。
主要看创口吧，之后拔的几个没长歪的，就还好。

没文化、没见识是这样的啦，你跟他们说也是白说，根本说不到一个频道上。
知识改变命运，穷不可怕，可怕的是愚昧。

其实重点不是一个接口还是多个接口的问题，甚至我们可以这么理解： http 协议它就是一个接口！为什么呢？——通过 method 、path 、header 、body 来区分不同的业务功能，跟你通过 body 里面的 code 字段还有其他业务数据一个道理。

那么，重点是什么呢？重点是设计哲学——对不同业务进行分析，总结共性，做适当抽象，并最终形成一套严谨、一贯的规则（或者说约定）。不管是 rest 风格，还是就根据 code 进行处理，都是一样的。

但话说回来，rest 确实有它的缺陷，比如用 method 来表达动作，用 statuscode 来表现结果，由于 method 和 statuscode 无法根据业务自由扩展（特别是 method ，你很难新增一种新 method ），在复杂的业务面前，有点束手束脚。其他的倒还好。

努力都会好的，祝福

提一点点建议：有机会还是要读点书，或者学一些技术傍身，这样以后路更好走一些