这是一个创建于 3184 天前的主题，其中的信息可能已经有所发展或是发生改变。
我觉得 REST 的其它 5 个约束：请求由客户端发起、会话状态由客户端维护、响应内容可缓存、统一接口、按需代码，都挺好理解的。但是唯独“分层系统（ Layered System ）：通过限制组件的行为（即每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的。”（引用自维基百科） 这一条是怎么都理解不了。
- 这里提到的组件指的是什么？一个 Model 还是一个服务？
- 这里的“紧邻层”又是什么？这里“层”的概念是什么？
- 为什么要分层系统？（如果前两个明白了，这个可能也就迎刃而解了）
 | 1 justdoit123 OP 补充一句，我去谷歌搜索出来的资料，对这一条约束的解释基本都是像维基百科那样一笔带过。各位能否给个形象、具体的解释？ |
 | 2 sivacohan PRO 没啥形象解释。和面向对象一样，也是一种系统设计 /架构思想。 这个描述在 UNIX 里面比较常见。记不清是《 UNIX 编程思想》还是《 UNIX 高级环境编程》里面看到的了。 紧邻层这个说法我没听过，不过看你描述挺像胶合层的。 基本逻辑就是一个程序干好一件事，一个输入，一个输出。两个程序想要组合，利用胶合层。类似管道, tee 之类的东西。 |
 | 3 libook 2017-04-07 08:45:43 +08:00 首先， REST 只是一种 API 的设计风格，具体还要根据业务特点和应用场景进行选择和定制。 降低系统复杂度的两个基本方法就是分层和解耦。 举个例子，一种系统层级方案是 路由-控制器-数据模型-数据库 ，那么对于路由层来说，它只能看到控制器层，并且可以调用控制器曾的任何一个控制器，路由不能看到数据模型层甚至数据库层，也不能对他们进行任何调用和操作，这样路由层的程序只需要了解控制器层的接口以及如何调用就可以了，不需要关心控制器层是如何第哦啊用数据模型层的。 类似的思想与 REST 结合起来，我能想到的比较贴切的例子是微服务。 比如一套服务系统的分层方案是 订单服务-支付服务-账户服务-用户服务 ，那么每两层之间是使用 RESTful 的 WEB API 进行通信的，同时订单服务也只能访问到支付服务，而不能访问到账户服务，也只需要关心支付服务的接口，而不需要关心支付服务是如何调用账户服务的。 不过看起来好像是系统架构相关的，和 API 设计没啥关系。。。 你可以参考一下 https://github.com/ZhangBohan/http-api-design-ZH_CN |
 | 4 baiyi 2017-04-07 10:08:08 +08:00  |
| 5 baiyi 2017-04-07 10:08:26 +08:00  |
Select Language