hxysnail 最近的时间轴更新
hxysnail

hxysnail

V2EX 第 70743 号会员,加入于 2014-08-13 13:19:57 +08:00
今日活跃度排名 13353
小米路由不支持光猫桥接模式拨号吗?
路由器  •  hxysnail  •  164 天前  •  最后回复来自 NickMe
27
想换一台洗衣机,大家有什么推荐的吗
生活  •  hxysnail  •  317 天前  •  最后回复来自 lanbatian
36
想问各位大佬, iOS 不越狱的话有哪些靠谱的科学上网方式?
Chamber  •  hxysnail  •  2023-03-07 14:19:20 PM  •  最后回复来自 KouYiGuo
6
老婆下周生日,送点什么礼物好?
生活  •  hxysnail  •  2023-01-10 23:20:17 PM  •  最后回复来自 hxysnail
116
有大佬熟悉高并发技术吗?有空进来交流一下
  •  1   
    程序员  •  hxysnail  •  2022-11-27 22:16:38 PM  •  最后回复来自 hxysnail
    45
    想买个显示器写代码看文档用,大家有啥好推荐吗?
    程序员  •  hxysnail  •  2022-11-12 12:12:38 PM  •  最后回复来自 RipperJack666
    40
    hxysnail 最近回复了
    主机和路由的工作流程都一样:

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

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

    但话说回来,rest 确实有它的缺陷,比如用 method 来表达动作,用 statuscode 来表现结果,由于 method 和 statuscode 无法根据业务自由扩展(特别是 method ,你很难新增一种新 method ),在复杂的业务面前,有点束手束脚。其他的倒还好。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5702 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 20ms · UTC 02:18 · PVG 10:18 · LAX 19:18 · JFK 22:18
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.