10 | RESTful服务（下）：如何评价服务是否RESTful？
Richardson 成熟度模型
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
RESTful服务的评价标准基于Richardson成熟度模型（RMM），将服务接口分为0至3级。0级是基于RPC风格的服务设计，1级引入资源概念，2级引入HTTP协议的标准方法，3级则是超文本驱动。文章通过实际例子展示了不同级别的REST服务接口设计，从简单的RPC风格到完全解耦的超文本驱动。随着级别的提升，服务的抽象程度逐渐提高，解决了查询、预约、错误处理和安全性等问题。最终，达到第3级REST的服务端API和客户端可以完全解耦，使得服务调整和API升级变得简单。文章总结了REST的优点和受到的非议，为读者提供了对REST实践的全面了解。 REST的不足与争议主要包括面向资源的编程思想只适合做CRUD、REST与HTTP完全绑定不适用于要求高性能传输的场景、REST不利于事务支持、REST缺乏对资源进行“部分”和“批量”的处理能力等问题。作者对这些问题进行了深入的分析和讨论，指出了这些问题的根源以及可能的解决方案。文章还提到了REST的优点和适用场景，为读者提供了全面的思考和实践指导。 总的来说，本文通过对RESTful服务评价标准和相关争议的分析，为读者提供了对REST实践的全面了解，同时展示了对REST优点和不足的深入思考，为读者提供了有价值的技术参考。
请先领取课程
全部留言(34)
- 最新
- 精选
陈珙谢谢老师的分享。 我也谈谈自己实践REST和RPC后的感想，主要在第一、第二的争议点，感触非常的深。之前我们用REST到第2成熟度。 第一点争议，包括我现在的想法也是认为面向资源更加是适合做数据读写接口的场景，例如某nosql的应用服务API封装，或者提供某内部使用API的微服务更加适合。如果作为提供给前端使用，处理起复杂业务的时候不好抽象。其次就是原本一个接口可以处理的复杂逻辑，但是因为REST原因导致接口粒度要细到N个，假如由前端人员对接，那么就会增大他们的业务组合难度（我更加倾向大部分的业务逻辑由后端解决，前端尽量关注数据展示与动画交互，数据离后端人员最近） 那么粒度细了后就会引申出第二点说的性能问题，因为要做个接口的编排组合。其次也是REST也是被HTTP绑得死死的，那么就不得不去关注那些细节，例如：HTTP StatusCode，参数除了body可能还会header，也有可能是uri参数，对于实际开发的便捷度不好。 课程还提到GraphQL，那么该技术的确能缓解Query的部分问题，但是同时也有不可能避免的问题是，数据源和他的属性怎么让使用端很好了解并对接？ 那么对于这种存在争议性大的东西，我建议尽可能的少引入团队，争议性大就意味着大家对他的理解的共性越少，无论是引入推广还是实施的具体效果都会存在很长周期的磨合与统一。但也不是一文不值，我们做的是解决方案，解决的是针对性的问题场景，对于一些比较清晰比较接近数据的场景例如NoSQL的API，或者简单的业务场景方便抽象的、相对需求稳定的，例如某内部微服务的API，我认为是可以尝试使用的 个人见解，期待老师的回复作者回复: 我完全同意做技术决策时，将团队本身的实际情况作为重要的决策依据。做架构和设计肯定不是参加考试答题，没有什么标准答案可言，必定有利有弊才需要做权衡。具体到REST上，如果团队普遍能够接受GraphQL，那是挺香的；但如果团队中多数人都需要专门学习之后才能使用它，那引入它带来认知负荷的提高，弊端就很可能完全盖过了收益。 类似的权衡，在REST和RPC中也是一样的，这几节介绍RPC与REST的文章中，我都极力避免可能产生“哪一种更好”的表述，只是陈述它们各自解决的问题、思路与利弊，为做权衡决策时提供参考。
2020-12-2334- 有铭就我的观察，其实rest的接受度也没高到哪里，虽然它作为一种理论广为人知。但是实际实践中很少有看到实践的很好的纯rest,大部分还是混合的。究其原因，我个人觉得是：抽象这个问题对人的大脑有要求，有心智负担。而现在的市场主流需求是：水平一般的人也能快速上手写代码。所以对抽象能力有要求的实现，就曲高和寡。这也是为什么“事务脚本（crud boy）”这种被绝大部分程序猿都厌恶的东西，却覆盖最广。
作者回复: 是的，这是大部分软件的现状。
2020-12-1016 - Helios我们当初践行rest的时候也遇到了这两个问题，批量接口和一次设计多个资源问题。 老师可不可以讲讲rest中的资源和代码中实体的区别
作者回复: REST中的资源的边界并没有官方的或者公认的标准答案。一般应该与你构建系统方法论保持一致，譬如DDD中，有的观点是应该直接将Resources映射到Domain Entities上。 这些观点都有争议，怎样的设计才是更好的设计，在软件业中是类似于“PHP是世界上最好的语言”的问题。
2021-02-013 
夜辉第 1 级成熟度：Resourcesz中获取医生档期应该要用get吧作者回复: 这是故意的，作为反面教材。1级和2级的差别就是HTTP Verbs
2021-04-292
Johnson老师，想了解一下，使用restful，类似于登录、注册、修改密码、重置密码、忘记密码这些功能，url使用什么形式比较好？希望老师能回复一下。谢谢！作者回复: 这种“取名字”一类的问题，很难说哪一种属于比较好。你可以直接观察一些网站是如何做的。譬如极客时间的短信登陆是https://account.geekbang.org/account/sms/login，取ticket是https://account.infoq.cn/account/ticket/token
2021-01-171
时二少老师，请教个问题 关于REST实践的设计CRUD时 1 同一个route, 通过不同方法（GET POST PUT DELETE）来实现CRUD 2 定义不同的route来实现CRUD 以前都是使用第2种方式。 如果REST是面向资源，感觉第1种更合理一下作者回复: 一般来说推荐第一种，REST明确提倡HTTP Verbs，通俗理解就是将动词映射到HTTP的方法上，而不是独立的HTTP Resource上。
2021-04-24
李二木可以增加一节讲讲对抽象的理解吗 ，抽象对于架构设计还是很重要的。作者回复: 这门课程的主体内容是务实的，就是多谈具体技术，少谈方向理论，虽然我在其他地方有写过一些这方面务虚的文章，但并没有选进课程中来。
2020-12-302
小白老师，想问一下 http请求经常出现 getUsernameById 这种命名的url，那他也是一种RPC 风格吗 或者说RPC风格和RPC协议 是两种概念吗作者回复: 风格（style）和协议（specification）确实不是同一个概念。协议是具体的约束，譬如“这个电饭锅符合3C规范”，这是遵循协议；风格是宽泛的原则，“这个电饭锅是厨房电器”，这是适用风格。
2020-12-102- 蓝桥春雪RPC：是从实现者的角度来定义接口 REST：是从使用者的角度来定义接口2020-12-0941
neohopeREST的成功很大程度上源于HTTP及JSON使用的广泛性，其资源的思维确实很巧妙。 但其实不少REST落地成了HTTP协议收发JSON，直接把“HTTP方法”变成了JSON中的一个KV，进行了扩展；而且进一步封装了HTTP的返回值，将HTTP400/500，封装成了JSON，从而可以反馈更多的信息。换句话说，REST的一些问题，可以通过适当的灵活来解决。但唯独“传输效率”这个问题无法突破HTTP+JSON的极限。 个人认为，微服务之间内部通讯使用RPC提升传输效率，Web及外部通讯使用REST或HTTP+JSON可能是一个比较好的折中性选择。2021-03-297