V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  hxysnail  ›  全部回复第 1 页 / 共 14 页
回复总数  263
1  2  3  4  5  6  7  8  9  10 ... 14  
主机和路由的工作流程都一样:

1. 从 IP 包中取出目的地址,然后查询路由表,看下一跳的地址 N 是什么?
2. 接下来,通过数据链路层,把 IP 包发给下一跳 N ,步骤如下:
- 执行 ARP 协议,查询下一跳 N 的 mac 地址;
- 封装数据链路层帧,将 IP 包发给下一跳,目的 mac 地址是上一步通过 ARP 协议查询到的。

具体可以参考这篇文章: https://fasionchan.com/network/ip/routing/
@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 个月的,估计是双职工休完产假就送托班的。
28 天前
回复了 guofushan2903 创建的主题 健康 拔过智齿的老哥,疼吗
我拔过一个长歪的,拔的时候有麻药没感觉,麻药退了之后就挺疼的,还发热请假了两天,但还能够接受。
主要看创口吧,之后拔的几个没长歪的,就还好。
72 天前
回复了 standchan 创建的主题 生活 分享一下我家族的人在大事上犯的蠢事
没文化、没见识是这样的啦,你跟他们说也是白说,根本说不到一个频道上。
知识改变命运,穷不可怕,可怕的是愚昧。
其实重点不是一个接口还是多个接口的问题,甚至我们可以这么理解: http 协议它就是一个接口!为什么呢?——通过 method 、path 、header 、body 来区分不同的业务功能,跟你通过 body 里面的 code 字段还有其他业务数据一个道理。

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

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

提一点点建议:有机会还是要读点书,或者学一些技术傍身,这样以后路更好走一些
91 天前
回复了 ChaYedan666 创建的主题 程序员 感叹一下,现在外包老哥们都好厉害
会不会不能说明什么问题,跟精通区别很大的啊。我接触下来,越是水平一般的,你跟他聊他越是这也会那也会,基本只要接触点皮毛就说会。

你提及的 spring 和 springcloud 这种框架性的东西,都不是太难的技术点,而且好多东西都是触类旁通的。正常后端甚至语言都能无缝衔接,因为语言仅仅只是工具而已。只要计算机底层原理扎实,这些都不是事。

像以前实习培训时,团队提供了迷你项目考核,甚至都不予许我们用已有的框架,必须自己设计并封装一个 web 框架。因为他们的理念就是,作为开发必须懂框架的运行原理、设计理念,而不是只会掉别人的接口。
1  2  3  4  5  6  7  8  9  10 ... 14  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3253 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 12:02 · PVG 20:02 · LAX 05:02 · JFK 08:02
Developed with CodeLauncher
♥ Do have faith in what you're doing.