09 | RESTful服务（上）：从面向过程编程到面向资源编程
REST 与 RPC 的对比
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
RESTful服务是一种面向资源的编程思想，与RPC有着根本的差异。REST并非一种远程服务调用协议，而是一种架构风格与网络的软件架构设计。其核心特征包括统一接口、超文本驱动和自描述消息。REST适用于移动端、桌面端或分布式服务端的节点之间通讯，但在追求传输效率和简化调用的场景中，REST的潜力有限。RESTful服务的概念和特点使其成为一种主流的远程服务访问风格，与RPC有着不同的思想和概念。REST的特征包括服务端与客户端分离、无状态、可缓存、分层系统、统一接口和按需代码。这些特征使得REST成为一种具有高抽象程度和通用性的编程思想，尽管在实际应用中仍存在一些挑战和争议。 在REST提出以前，人们设计分布式系统服务的唯一方案就只有RPC，RPC是将本地的方法调用思路迁移到远程方法调用上，开发者是围绕着“远程方法”去设计两个系统间的交互的，比如CORBA、RMI、DCOM，等等。而REST提出以资源为主体进行服务设计的风格，为它带来了不少好处。REST的重要标志是统一接口，它把对资源的标准操作都映射到了标准的HTTP方法上去，降低了服务接口的学习成本。此外，资源天然具有集合与层次结构，而REST绑定于HTTP协议，使得它能更好地匹配在HTTP基础上构建的互联网，在效率与扩展性方面也会有可观的收益。 总的来说，REST的面向资源的设计风格为服务设计带来了许多优势，但是否选用REST的API设计风格，需要权衡的是需求场景、团队的设计，以及开发人员是否能够适应面向资源的思想来设计软件、来编写代码。REST通常能够更好地匹配在HTTP基础上构建的互联网，在效率与扩展性方面也会有可观的收益。
请先领取课程
全部留言(33)
- 最新
- 精选
- lmdcx这是我见过对 REST 描述最透彻的文章（尽管老师的主要目的可能并非此意） 多说无益，我其实就想点个赞，可惜没有点赞按钮~
作者回复: 感谢认可，谢谢你的赞。
2020-12-077105 
术子米德🤔☕️🤔☕️🤔 REST的Stateless，是指业务无状态，并不是资源无状态 对于资源的操作引起的资源状态切换，还是在服务端 只是基于资源的业务的状态，不由服务端保持和维护，就是所谓的Stateless REST风格的对资源操作，带来的最大益处就是业务的组合性极其方便，而且因为业务状态不在服务端，因此服务端在只需维护资源状态的情况下，非常容易实现横向扩展作者回复: 对的
2020-12-0737
tt这节课的启发好大。 对于REST，之前的第一印象就是服务端无状态，有利于水平扩展，但更多的是停留于具体的技术层面。 过程如果有意义的话，一定会产生一个结果，这个结果就是资源的状态发生了转移（幂等前提下的重试不算），但是过程细节更多，所以抽象程度无法做到向面向资源看齐。 在一个过程中，可以对有关联关系的不同层次与结构的资源同时进行处理。但是面向资源却不容易做到。 我能想到的例子是转账操作，同时操作两个资源即账户，而且要保证事务的ACID。在转账的过程中要处理很多异常情况，尤其是涉及到多方交易的时候，所以写这样的交易就非常复杂，容易出错。 如果用面向资源的角度去考察，可以看成是对三个资源的操作:转出账户、转入账户以及事务。这里把事务列为单独的资源，是为了呼应上面提到的一个资源状态变化引起的关联资源的变化。 如果转账操作利用TCC(try-confirm-cancel)的方法，我觉得就是一种更偏向于面向资源的做法，每次只改变一个资源的状态。如果某个关联资源的状态改变失败，就对它发起一个逆操作（比如冲正）。这样可以做到很高的并发，在做到保序性的前提下，做差错处理也很简单。相当于把一个复杂操作分解成了多个简单操作，这样开发起来也很快，很容易复用。有点类似CISC和RISC指令集的关系。作者回复: 很好的思考，希望后面的课程也能对你有用。
2020-12-07226
公众号：业余草谷歌的QUIC有没有未来作者回复: 谷歌的gQUIC不会再有什么发展了，但谷歌捐献给IETF的iQUIC，现在都成了HTTP/3，当然会有未来。后面介绍链路传输的课程中会讨论到这个问题。 另外，QUIC的低延迟特性，现在在很多视频直播中都有重要的应用。
2020-12-07210
閃電ㄢ奇±κλ`周老师，GraphQL有没有未来作者回复: 预言家会被狼人刀的，我不敢随意下结论。 不过，既然它已经不温不火地存在了几年，未来大概率应该也不会消失但同时火不起来吧。
2020-12-105
刘智恒讲的非常详细！点赞！同时我对于超文本驱动这一部分内容有一个问题 在CSR/SSR场景下由ajax获取资源+javascript渲染资源的方式属于超文本驱动吗？ 在这种模式下转换页面这个操作有可能是完全由客户端js决定的，似乎和超文本关系不大？如果与超文本关系不大的话，超文本驱动还能作为REST的核心特征吗？作者回复: 超文本驱动中的“驱动”，是指“使资源发生变化的信息来源”，这些信息是随着前一次资源请求返回下来的。至于后续这些信息是在client还是在server去使用，是被JS或者什么其他途径使用并不重要。 如果仍然觉得抽象，可以在google上以“HATEOAS”为关键词搜索一下，看一两个例子很容易就明白了。
2020-12-1034
相信你的直觉
周老师对于架构的设计讲得非常通俗易懂 并且老师讲架构之时，通常都有比较之处，联系贴近生活，各有优缺点。让人茅塞顿开 突然发现软件架构设计已经不仅仅是科学了 已经上升成哲学了 我在想，面向机器，面向过程，面向对象，面向资源，各种思想层出不穷，没有孰优孰劣，应用场景不同，那么适应的思想就不同，我想老师同大家一样，一定是有那么自己擅长的架构和编程思想 思想和技术的路没有尽头，只有不断的演变和进化……作者回复: 感谢认可。
2020-12-073
zhanydREST和RPC，如果效率上没要求的话，哪个简单就用哪个，貌似REST方式更简单啊。作者回复: rest更简单是因为rest绑定于http，几乎在所有场景中都可用，而且都有天然的client。使用门槛比大部分rpc低 但另一方面，rest抽象程度通常更高，说白了就是有可能通过更少的接口来表达出相同的语义。这个角度的“用”并不会比rpc简单。
2020-12-072
J.Smile说实话，这么多年用rest的时候非常少。从功能开发实现的角度来说，非rest跟rest都可以做到。但区别恰恰就在于rest的一个缺点（这里相对来说，其实不够准确）---理解上不够直观。Rest是一种面向资源的架构设计风格，既然是风格，那就具备了可选性这一点，对于习惯了像springmvc传统请求方式来说，并不觉得Rest style有什么实现的必要性。所以，一般面试的时候，还是不要轻易说自己使用过rest，对rest熟悉、精通之类的。😄作者回复: 根据团队的实际情况去做决策，不拘泥与纸上谈兵的“最好”或“最佳实践”，也是架构师应有的思维。
2020-12-072
书生REST这种风格确实让接口变的更可读，但是在网关层面更难管理，尤其是path parameter，请教下老师是怎么处理的。（比如说灰度的时候按照路径去匹配灰度名单，有路径参数就很麻烦）作者回复: 有参数更加便于网关去路由才对，等后面关于服务网关的课程更新后看看能否解答你的疑问。
2020-12-0821