awesome-fenix
awesome-fenix copied to clipboard
fenixsoft
「Comment」https://icyfenix.cn/architect-perspective/general-architecture/api-style/rest.html
https://icyfenix.cn/architect-perspective/general-architecture/api-style/rest.html
@dengchaoh 在互利网中，面向资源来进行网络传输是这三十年来HTTP协议精心培养出来的用户习惯。 周大哥，“在互利网中”是笔误，“在互联网中”？
感谢！已修改，下次commit时更新
周老师，对于返回{code: xxx, message: "xxx", data: xxx}这种设计如何看待？是否是违背了RMM第2级的使用HTTP协议的Status Code，因此是RMM 1级？
@UUNNFLY 周老师，对于返回{code: xxx, message: "xxx", data: xxx}这种设计如何看待？是否是违背了RMM第2级的使用HTTP协议的Status Code，因此是RMM 1级？
这种与REST谈不上有什么关系，最初的源头是JSON-RPC协议，但JSON-RPC Specification中也只是规定了在error中带code和message，现在有不少程序，包括一些较为有名的产品都发展到凡是交互就必定返回个code的程度。我个人不太感冒，但确实是很普遍的现状。
将“REST 与 RPC 在思想上差异的核心是抽象的目标不一样，既面向过程的编程思想与面向资源的编程思想两者之间的区别。”后半句中的“面向过程的编程思想”和“面向资源的编程”位置互相调换一下会不会好一点？第一次读到以为 REST 是“面向过程”，RPC 是“面向资源”，这和上一章的理解产生了偏差。
将“REST 与 RPC 在思想上差异的核心是抽象的目标不一样，既面向过程的编程思想与面向资源的编程思想两者之间的区别。”后半句中的“面向过程的编程思想”和“面向资源的编程”位置互相调换一下会不会好一点？第一次读到以为 REST 是“面向过程”，RPC 是“面向资源”，这和上一章的理解产生了偏差。
有道理，已修正
@fenixsoft
将“REST 与 RPC 在思想上差异的核心是抽象的目标不一样，既面向过程的编程思想与面向资源的编程思想两者之间的区别。”后半句中的“面向过程的编程思想”和“面向资源的编程”位置互相调换一下会不会好一点？第一次读到以为 REST 是“面向过程”，RPC 是“面向资源”，这和上一章的理解产生了偏差。
有道理，已修正
“既面向过程的编程思想与面向资源的编程思想两者之间的区别” 是不是应该是“即”
"以前，人们面向方法去设计 RPC API，譬如 CORBA 和 DCOM，随着时间推移，接口与方法越来越多却又各不相同，开发人员必须了解每一个方法才能正确使用它们，这样既耗时又容易出错。
—— Google API Deign Guide" 这里的“Deign”应该为“Design”
有点疑惑, 医生和档期都是资源， 如果2个资源有关系时该怎么设计？
获取医生档期 GET /doctors/mjones/schedule?date=2020-03-04&status=open HTTP/1.1
那如果是要获取所有医生的档期该怎么命名呢?
预约确认 POST /schedules/1234 HTTP/1.1
为什么不是 POST /doctors/mjones/schedules/1234 HTTP/1.1
@sunyj-003 有点疑惑, 医生和档期都是资源， 如果2个资源有关系时该怎么设计？
获取医生档期 GET /doctors/mjones/schedule?date=2020-03-04&status=open HTTP/1.1
那如果是要获取所有医生的档期该怎么命名呢?
预约确认 POST /schedules/1234 HTTP/1.1
为什么不是 POST /doctors/mjones/schedules/1234 HTTP/1.1
2、有档期ID=1234（1234就是代表mjones医生在14:00~14:50的档期），即使没有/doctors/mjones这些请求信息，服务器端也是能获取医生信息的。
个人认为面向资源编程只是面向过程编程的一种特例，怎么说呢，资源的形成源自于建模，在图形学中，已经建立好的单个模型我们称之为对象，也即资源。REST对于web这种已经建立好的访问模式来说，自然是以资源先入为主了
Rest 对监控来说是不是不够友好，比如 GET /user/1 这种，本来想监控 查询用户接口的QPS， 但是会按路由展示了 每个用户查询了多少次
@sunyj-003 有点疑惑, 医生和档期都是资源， 如果2个资源有关系时该怎么设计？
获取医生档期 GET /doctors/mjones/schedule?date=2020-03-04&status=open HTTP/1.1
那如果是要获取所有医生的档期该怎么命名呢?
预约确认 POST /schedules/1234 HTTP/1.1
为什么不是 POST /doctors/mjones/schedules/1234 HTTP/1.1
我也有这样的疑惑，上文中不是提到了统一接口吗？应该用GET、Put去操作资源
@loadnil 个人认为面向资源编程只是面向过程编程的一种特例，怎么说呢，资源的形成源自于建模，在图形学中，已经建立好的单个模型我们称之为对象，也即资源。REST对于web这种已经建立好的访问模式来说，自然是以资源先入为主了
是否可以这么认为？面向对象时把太多东西设置为了对象，这对调用方产生了不必要的麻烦。而面向资源编程，则只代码中关心的最最重要的部分抽象为资源
REST 与 HTTP 完全绑定，不适合应用于要求高性能传输的场景中。
其实REST和HTTP并无完全绑定的关系，正如您文中所说的REST是架构风格，HTTP是应用层的协议。只因REST是伴随设计HTTP和URI协议过程中的产生的理论指导思想。比如在2014年一个基于UDP的CoAP(http://coap.technology)就是符合REST的架构风格的另外一个协议。
关于性能的问题，Fielding在他的那篇博士论文中把性能拆分为用户感知的性能、网络性能和网络效率三部分来衡量。通常来讲RPC关注的点大都在于提升网络性能（选择基于TCP而不是HTTP）、网络效率（采用protobuf而不是json），而很少去关注用户感知的性能这个指标。但是这个指标其实才是我们最终追求的最重要的衡量指标，所以REST中定义了缓存+分层系统这2个架构约束，然后HTTP支持了这两个约束，由此才催生出了CDN，这也对应了REST论文中的一个观点（An interesting observation about network-based applications is that the best application performance is obtained by not using the network）。同时HTTP/2也在改善了HTTP协议本身的性能，HTTP/3在尝试解决传输层TCP的性能问题，这些协议层面的优化在应用层是完全无感知就可以享受到的，这一点相比RPC的私有协议是要更通用方便一些的。不过也正是其通用的request/response模型，导致其无法适用于需要双向实时通信这种场景。
REST的目标在于如何有效的利用网络；RPC的目标大都在于如何屏蔽网络差异，让消费方尽可能的当作一个本地function来使用用。
