周志明的软件架构课
周志明
博士,远光软件研究院院长,《深入理解Java虚拟机》等书作者
赠一得一
22835 人已学习
课程目录
已更新 55 讲 / 共 70 讲
开篇词 (2讲)
开篇词 | 如何构建一个可靠的分布式系统?
免费
导读 | 什么是“The Fenix Project”?
演进中的架构 (6讲)
01 | 原始分布式时代:Unix设计哲学下的服务探索
02 | 单体系统时代:应用最广泛的架构风格
03 | SOA时代:成功理论与失败实践
04 | 微服务时代:SOA的革命者
05 | 后微服务时代:跨越软件与硬件之间的界限
06 | 无服务时代:“不分布式”云端系统的起点
架构师的视角 (24讲)
07 | 远程服务调用(上):从本地方法到远程方法的桥梁
08 | 远程服务调用(下):如何选择适合自己的RPC框架?
09 | RESTful服务(上):从面向过程编程到面向资源编程
10 | RESTful服务(下):如何评价服务是否RESTful?
11 | 本地事务如何实现原子性和持久性?
12 | 本地事务如何实现隔离性?
13 | 全局事务和共享事务是如何实现的?
14 | 分布式事务之可靠消息队列
15 | 分布式事务之TCC与SAGA
16 | 域名解析系统,优化HTTP性能的第一步
17 | 客户端缓存是如何帮助服务器分担流量的?
18 | 传输链路,优化HTTP传输速度的小技巧
19 | 如何利用内容分发网络来提高网络性能?
20 | 常见的四层负载均衡的工作模式是怎样的?
21 | 服务端缓存的三种属性
22 | 分布式缓存如何与本地缓存配合,提高系统性能?
23 | 认证:系统如何正确分辨操作用户的真实身份?
24 | 授权(上):系统如何确保授权的过程可靠?
25 | 授权(下):系统如何确保授权的结果可控?
26 | 凭证:系统如何保证与用户之间的承诺是准确完整且不可抵赖的?
27 | 保密:系统如何保证敏感数据无法被内外部人员窃取滥用?
28 | 传输(上):传输安全的基础,摘要、加密与签名
29 | 传输(下):数字证书与传输安全层
30 | 验证:系统如何确保提交给服务的数据是安全的?
春节特别放送 (3讲)
春节特别放送(上)| 有的放矢,事半功倍
春节特别放送(下)| 积累沉淀,知行合一
用户故事 | 詹应达:持续成长,不惧未来
分布式的基石 (14讲)
31 | 分布式共识(上):想用好分布式框架,先学会Paxos算法吧
32 | 分布式共识(下):Multi Paxos、Raft与Gossip,分布式领域的基石
33 | 服务发现如何做到持续维护服务地址在动态运维中的时效性?
34 | 路由凭什么作为微服务网关的基础职能?
35 | 如何在客户端实现服务的负载均衡?
36 | 面对程序故障,我们该做些什么?
37 | 要实现某种容错策略,我们该怎么做?
38 | 限流的目标与模式
39 | 如何构建零信任网络安全?
40 | 如何实现零信任网络下安全的服务访问?
41 | 分布式架构中的可观测到底说的是什么?
42 | 分析日志真的没那么简单
43 | 一个完整的分布式追踪系统是什么样子的?
44 | 聚合度量能给我们解决什么问题?
不可变基础设施 (6讲)
45 | 模块导学:从微服务到云原生
46 | 容器的崛起(上):文件、访问、资源的隔离
47 | 容器的崛起(下):系统、应用、集群的封装
48 | 以容器构建系统(上):隔离与协作
49 | 以容器构建系统(下):韧性与弹性
50 | 应用为中心的封装(上):Kustomize与Helm
周志明的软件架构课
15
15
1.0x
00:00/00:00
登录|注册

09 | RESTful服务(上):从面向过程编程到面向资源编程

周志明 2020-12-07
你好,我是周志明。前面两节课,我们学习了远程方法调用 RPC,今天我们接着学习另一种主流的远程服务访问风格:RESTful 服务。

REST 与 RPC 的对比

很多人都会拿 REST 来跟 RPC 对比优劣,其实,无论是思想上、概念上,还是使用范围上,REST 与 RPC 都不完全一样,它们在本质上并不是同一个类型的东西,充其量只算是有一些相似,在应用中会有一部分功能重合的地方。
REST 与 RPC 在思想上存在差异的核心,是抽象的目标不一样,也就是面向资源的编程思想与面向过程的编程思想之间的区别。
面向过程编程和面向对象编程,想必你应该都听说过,但什么是面向资源编程呢?这个问题等我一会儿介绍完 REST 的特征之后,再回头细说。
那么,二者在概念上的不同,是指 REST 并不是一种远程服务调用协议,甚至我们可以把定语也去掉,它就不是一种协议。
因为协议都带有一定的规范性和强制性,最起码也该有个规约文档,比如 JSON-RPC,它哪怕再简单,也要有个《JSON-RPC Specification》来规定协议的格式细节、异常、响应码等信息。但是 REST 并没有定义这些内容,虽然它有一些指导原则,但实际上并不受任何强制的约束。
经常会有人批评说,某个系统接口“设计得不够 RESTful”,其实这句话本身就有些争议。因为 REST 只能说是一种风格,而不是规范、协议,并且能完全达到 REST 所有指导原则的系统,也是很少见的。这个问题我们会在下一讲中详细讨论。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该文章仅可阅读部分内容,如需阅读完整文章,请先通过赠一得一解锁课程
赠一得一
登录 后留言

精选留言(17)

  • 叨客
    这是我见过对 REST 描述最透彻的文章(尽管老师的主要目的可能并非此意)
    多说无益,我其实就想点个赞,可惜没有点赞按钮~

    作者回复: 感谢认可,谢谢你的赞。

    2020-12-07
    5
    45
  • 术子米德
    🤔☕️🤔☕️🤔
    REST的Stateless,是指业务无状态,并不是资源无状态
    对于资源的操作引起的资源状态切换,还是在服务端
    只是基于资源的业务的状态,不由服务端保持和维护,就是所谓的Stateless
    REST风格的对资源操作,带来的最大益处就是业务的组合性极其方便,而且因为业务状态不在服务端,因此服务端在只需维护资源状态的情况下,非常容易实现横向扩展

    作者回复: 对的

    2020-12-07
    14
  • tt
    这节课的启发好大。

    对于REST,之前的第一印象就是服务端无状态,有利于水平扩展,但更多的是停留于具体的技术层面。

    过程如果有意义的话,一定会产生一个结果,这个结果就是资源的状态发生了转移(幂等前提下的重试不算),但是过程细节更多,所以抽象程度无法做到向面向资源看齐。

    在一个过程中,可以对有关联关系的不同层次与结构的资源同时进行处理。但是面向资源却不容易做到。

    我能想到的例子是转账操作,同时操作两个资源即账户,而且要保证事务的ACID。在转账的过程中要处理很多异常情况,尤其是涉及到多方交易的时候,所以写这样的交易就非常复杂,容易出错。

    如果用面向资源的角度去考察,可以看成是对三个资源的操作:转出账户、转入账户以及事务。这里把事务列为单独的资源,是为了呼应上面提到的一个资源状态变化引起的关联资源的变化。

    如果转账操作利用TCC(try-confirm-cancel)的方法,我觉得就是一种更偏向于面向资源的做法,每次只改变一个资源的状态。如果某个关联资源的状态改变失败,就对它发起一个逆操作(比如冲正)。这样可以做到很高的并发,在做到保序性的前提下,做差错处理也很简单。相当于把一个复杂操作分解成了多个简单操作,这样开发起来也很快,很容易复用。有点类似CISC和RISC指令集的关系。

    作者回复: 很好的思考,希望后面的课程也能对你有用。

    2020-12-07
    5
  • 公众号:业余草
    谷歌的QUIC有没有未来

    作者回复: 谷歌的gQUIC不会再有什么发展了,但谷歌捐献给IETF的iQUIC,现在都成了HTTP/3,当然会有未来。后面介绍链路传输的课程中会讨论到这个问题。
    另外,QUIC的低延迟特性,现在在很多视频直播中都有重要的应用。

    2020-12-07
    5
  • 閃電ㄢ奇±κλ`
    周老师,GraphQL有没有未来

    作者回复: 预言家会被狼人刀的,我不敢随意下结论。
    不过,既然它已经不温不火地存在了几年,未来大概率应该也不会消失但同时火不起来吧。

    2020-12-10
    2
  • 相信你的直觉
    周老师对于架构的设计讲得非常通俗易懂
    并且老师讲架构之时,通常都有比较之处,联系贴近生活,各有优缺点。让人茅塞顿开
    突然发现软件架构设计已经不仅仅是科学了
    已经上升成哲学了
    我在想,面向机器,面向过程,面向对象,面向资源,各种思想层出不穷,没有孰优孰劣,应用场景不同,那么适应的思想就不同,我想老师同大家一样,一定是有那么自己擅长的架构和编程思想
    思想和技术的路没有尽头,只有不断的演变和进化……

    作者回复: 感谢认可。

    2020-12-07
    2
  • 书生
    REST这种风格确实让接口变的更可读,但是在网关层面更难管理,尤其是path parameter,请教下老师是怎么处理的。(比如说灰度的时候按照路径去匹配灰度名单,有路径参数就很麻烦)

    作者回复: 有参数更加便于网关去路由才对,等后面关于服务网关的课程更新后看看能否解答你的疑问。

    2020-12-08
    1
  • zhanyd
    REST和RPC,如果效率上没要求的话,哪个简单就用哪个,貌似REST方式更简单啊。

    作者回复: rest更简单是因为rest绑定于http,几乎在所有场景中都可用,而且都有天然的client。使用门槛比大部分rpc低
    但另一方面,rest抽象程度通常更高,说白了就是有可能通过更少的接口来表达出相同的语义。这个角度的“用”并不会比rpc简单。

    2020-12-07
    1
  • STOREFEE
    非阻塞方式:读函数不停的进行读动作,如果没有报文接收到,等待一段时间后超时返回,这种情况一般需要指定超时时间。
    阻塞方式:如果没有接收到报文,则读函数一直处于等待状态,直到报文到达。

    消息队列:优点是异步,解耦 ,削峰,缺点是系统复杂性增加,数据一致性难以保证等问题。
    2020-12-07
    1
  • 大力水手Jerry
    一课一思:除长连接、消息管道外,还有队列和缓存。长连接是一种通讯链路使用模式,主要应用场景比如高可用中服务的探活,数据库连接资源的池化,其特点是操作频繁,点对点通讯,而且两点连接数有限。消息管道也是一种通讯机制,其本质是内存共享,主要用于进程或者线程间通讯。消息队列用于解耦,不同节点之间的服务可以通过消息队列进行通讯,提高系统的吞吐率。分布式缓存用于提升系统响应速度。需要指出的是,REST和RPC是一种编程抽象模型,而长连接、消息管道、队列和缓存只是一种通讯机制,它们可能被融入到编程模型中。
    2021-02-24
  • 刘章
    个人理解:
    RESTful 基点是 HTTP, RESTful 风格使以资源为基础,使 URL 表现力表现力更强、更可读性。

    RPC 是远程接口调用,可以通过 HTTP RESTful 实现 RPC


    2021-02-01
  • Helios
    2017年在做重构的时候参考了github v3的api做了设计,主要是url设计,返回值设计等。
    不得不说比把动词放在url里面的类rpc的风格好太多了。但是公司写php的同事就是不能接受,比如修改用户cart如果用rest风格就是/users/1/carts/3 然后通过put方法把信息放在body里面,一些同事认为是/user/cart/modify 通过post方法放在body里面。

    最后真的改变不了人的习惯,用了后者……
    2021-01-31
  • tt
    资源天然具有层次结构,那是不是意味着使用路径传参比用查询字符串传参更有优势呢?

    想想也不尽然,如果查询条件特别复杂,也许还是query string更合适
    2021-01-28
  • 刘智恒
    讲的非常详细!点赞!同时我对于超文本驱动这一部分内容有一个问题
    在CSR/SSR场景下由ajax获取资源+javascript渲染资源的方式属于超文本驱动吗?
    在这种模式下转换页面这个操作有可能是完全由客户端js决定的,似乎和超文本关系不大?如果与超文本关系不大的话,超文本驱动还能作为REST的核心特征吗?

    作者回复: 超文本驱动中的“驱动”,是指“使资源发生变化的信息来源”,这些信息是随着前一次资源请求返回下来的。至于后续这些信息是在client还是在server去使用,是被JS或者什么其他途径使用并不重要。
    如果仍然觉得抽象,可以在google上以“HATEOAS”为关键词搜索一下,看一两个例子很容易就明白了。

    2020-12-10
  • J.Smile
    说实话,这么多年用rest的时候非常少。从功能开发实现的角度来说,非rest跟rest都可以做到。但区别恰恰就在于rest的一个缺点(这里相对来说,其实不够准确)---理解上不够直观。Rest是一种面向资源的架构设计风格,既然是风格,那就具备了可选性这一点,对于习惯了像springmvc传统请求方式来说,并不觉得Rest style有什么实现的必要性。所以,一般面试的时候,还是不要轻易说自己使用过rest,对rest熟悉、精通之类的。😄

    作者回复: 根据团队的实际情况去做决策,不拘泥与纸上谈兵的“最好”或“最佳实践”,也是架构师应有的思维。

    2020-12-07
  • 贤伟
    物联网场景下:物联网协议LwM2M是基于IPSO 抽象物的对象和资源的。通过URL ObjectId/ObjectInstanceId/ResourceId 来定位资源,通过统一接口包括read,write,execute,observe操作资源.
    2020-12-07
  • Jxin
    1.感觉还是面相行为好点。毕竟基于http的面向资源,在复杂行为的描述能力上,还是有所欠缺。
    2.另外,也是最重要的原因。人们本能会选择比较舒服的方式,除非面相资源有极大优势,不然人们就很难从面相行为这种直观的表述去选用反人类的面相资源。而现实情况,面相资源优势确实不显。

    作者回复: 权衡而已,只谈得失,不谈好坏。

    2020-12-07
收起评论
17
返回
顶部