@
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 而已。
“不要说别人就五花八门,说自己就是合理约定。”你这么说不就想说别人双标嘛……还真不是……
今天想起要回这个贴,是因为上周我手下的人刚别其他项目的接口坑了一下。他们告诉我的人,要换个接口,返回的数据字段没变。我的人就去换了,因为对方说接口一样,数据字段没变,他们就偷懒没验证。结果上生产就出了个小问题,因为数据有个字段结构不太一样……
同一个字段,有一个接口是返回逗号分隔的字符串,另一个返回一个字符数组……理论上,同一种数据,不同的查询场景,返回的数据字段结构没必要不一样吧?这才是我强调的五花八门。
然后,我在自己项目的开发群里强调了范式规范,不知怎么发图片,直接贴我说的文字:
理论上,接口再垃圾,只要我们验证充分,问题肯定不会到生产上。
就算接口不好,最多也只是在开发阶段被坑,影响你的研发效率而已。
冤有头,债有主,谁坑你就去怼谁。
我以前经常跟你们强调,字段命名要前后一致,严禁五花八门,最近几次缺陷就是典型的案例。质疑别人前,我们自己要先做到这一点。
注意看, [质疑别人前,我们自己要先做到这一点。] 我们对自己的水平心里有数。