11｜将模型实现为RESTful API（下）
徐昊
该思维导图由 AI 生成，仅供参考
你好，我是徐昊。今天我们来聊聊继续如何将模型映射为 RESTful API。
上节课我们学习了如何将领域模型实现为 RESTful API 的宏观步骤，分为四步：
通过 URI 表示领域模型；
根据 URI 设计 API；
使用分布式超媒体设计 API 中涉及的资源；
使用得到的 API 去覆盖业务流程，验证 API 的有效性。
并着重学习了，如何通过 URI 表示领域模型；并在得到与领域模型对应的 URI 之后，使用类似角色 - 目标 - 实体法的分析方法，获得 API 候选。那么今天我们就继续学习后面两步，通过分布式超媒体设计 API 中涉及的资源，并将使用 API 覆盖业务流程，以验证 API 的有效性。
RESTful API 是一种什么样风格的 API？
到目前为止我们得到的 API 候选，比如 GET /users 等，还不能被称作 RESTful API，而仅仅可以被叫做基于 HTTP 的远程过程调用（HTTP RPC）。那么 RESTful API 到底是一种什么样的 API 呢？
RESTful API 是指符合 REST 架构风格的 API 设计，而 REST 架构风格是对互联网规模架构（Internet Scale Architecture）的总结与提炼。这一切都源于 Roy Fielding 提出的一个问题：既然互联网（Internet）是人类迄今为止构造的最大的软件应用，那么到底是什么样的架构原则，支撑了如此规模的异构且互联的系统呢？我们能从中学习到什么，以帮助我们更好地构建软件？
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
RESTful API是基于REST架构风格的API设计，通过分布式超媒体信息获取系统实现渐进式服务消费。本文深入探讨了分布式超媒体的概念，以及如何描述API中的资源，包括使用HAL来定义超媒体格式，以及如何通过超链接构成渐进式服务消费。重点讨论了集合资源和缓存策略对分页等问题的解决方案，展示了如何将客户端与服务端充分解耦。此外，强调了将API重新映射回业务流程的重要性，以及与业务方验证API是否能够满足所有需求的过程。通过深入的技术讨论和实例分析，全面阐述了RESTful API设计原则和实现方法，为读者提供了宝贵的学习和参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《如何落地业务建模》，新⼈⾸单¥68
《如何落地业务建模》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(24)
- 最新
- 精选
大海浮萍置顶看完restful api第二章，还是有些疑问，比如在采购订单场景下，修改订单（修改基本信息）和发布订单（修改状态，通知下游），感觉只能都设计成 PUT /order/{order_id}，那如何区分这两种用例呢，请赐教作者回复: 修改状态是post 修改信息是put
2021-07-214
绝露有没有写过文章，描述那4个小时发生了什么。 非常好奇。作者回复: 没有
2021-07-2126
支离书服务器永远不需要考虑客户端的需求。 --这话客户端同学不答应啊，并且考虑大部分中小公司现状，前端人员一般没有后端人员资历深，让前端因为分页数不一致就加一堆逻辑恐怕也不现实啊。。更何况要把集成与订制的责任交给前端了。。作者回复: 如果你需要web的scale 那么就要这么做 不需要随便怎么做都可以
2021-08-1132
Geek_fe0336看来不会弹吉他的软件工程师不是好咨询师啊！编辑回复: 也可以是：不会考证李商隐是gay的软件工程师就不是好的咨询师！
2021-12-121- 支离书/users一直返回最新注册的用户，那么就不是固定的50个了吧？第一页的数据个数就一直在变了。。就必须靠客户端解决这个问题了，不仅是在每页个数不同时需要客户端解决了
作者回复: 从有缓存的开始 到最新的
2021-08-111 
邓志国这种客户端，是又一次发明了浏览器吗？作者回复: 这是客户端应该有的样子
2021-07-231
Oops!我的理解是本节主要讲了RESTFUL API的一个准标准：HAL，前端开发的时候也需要遵循这个标准才能woker吧。比如分页的例子，前端按50每页加载，后端20每页的往外吐，那前端就需要理解这个next链接隐含的含义，即next链接返回接下来的数据，但是不一定符合页面分页模式，然后前端需要一直调用next,直到凑足50条，是这样吗？另外，关于缓存，按文中所提模式，如果查询条件比较复杂多变，比如有排序项，过滤等，那这个缓存会不会过于复杂。进一步的，如果允许用户注销，用户注销后，前面缓存的这个用户信息该怎么处理？作者回复: 查询一般post 表示不可缓存
2021-07-211
赵晏龙【服务器永远不需要考虑客户端的需求】这是我在这一章里面学到的最重要的东西，结合你讲的渐进式服务消费，确实能解决一些问题。作者回复: www就这么感 在规模优先的系统下 唯一选择
2021-07-191
輪迴渐进式服务消费很新颖的思路，这种方式对多变的前端开发是否合适？移动端设备的性能与存储的取舍都需要考虑。作者回复: 不新颖 就是从web总结出来的
2021-08-12
帅气のboy实际业务中要让前端接受这个方式可能会很难。但是这个思想可以指导服务端将业务代码写成分层结构，越底层的越是通用不变的，越上层的就可以是下层多个接口的组合作者回复: 是个定位问题 定位为业务能力 和定位成后端 前端的心态是不一样的
2021-08-03
收起评论
