师傅最长的路是什么路？REST和RESTful API有什么区别？架构风格和模式是什么？
问题：架构设计的行业最佳实践是什么
REST → RESTful API
REST有一个有点拗口的中文名字“表述性状态转移”，忽略名字的深度含义，简单来说REST规范了HTTP API协议：URL作为资源名词定义、Head作为动词控制参数、Body作为业务数据参数。REST最大的贡献除了规范协议也在团队内达成了API共识。
那么有一个问题：REST和RESTful API有什么区别？
首先看下这两个模型的定义
然后简单对比下之间的差异点
| 模型 | 用途 | 场景 |
|---|---|---|
| REST | 抽象的架构设计思路 | 理论方法使用 |
| RESTful API | API的一种设计方法 | API层使用 |
最后总结如下
- REST - 一种架构风格，表述性状态转移规范描述
- RESTful API - 一种架构模式，针对Connector的API规范
RESTful API是REST架构风格在Connector连接器问题场景下的应用
行业最佳实践
每个行业都有行业知识沉淀，软件行业的“架构设计”层面知识沉淀是“架构风格和模式”，“代码设计”层面知识沉淀是“设计模式”，“代码”层面的知识积累是“框架+中间件”等，这些设计成果就是在不同业务场景下前人采坑后总结并沉淀的知识。
下面表格中的设计风格就是一些“行业最佳实践”，研发同学应该都了解过相关知识，本次要把学过的知识再次总结抽象提升，下面每一个设计风格都可以单独总结成章，在此不展开说明。
| 架构风格 | 描述 |
|---|---|
| CS | 客户端服务器 |
| BS | 浏览器服务器 |
| 插件化 | 功能单元以插件方式管理 |
| 组件化 | 功能单元以组件方式管理 |
| 发布订阅 | 订阅Topic回调触发使用 |
架构风格是什么
架构风格 - An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style. 架构风格即约束。
REST是一种架构风格，表述性状态转移规范约束。
| 架构风格 | 描述 |
|---|---|
| CS | 客户端服务器 |
| BS | 浏览器服务器 |
| 插件化 | 功能单元以插件方式管理 |
| 组件化 | 功能单元以组件方式管理 |
| 发布订阅 | 订阅Topic回调触发使用 |
| 管道过滤器 | Servlet/Filter |
| 消息总线 | 消息总线 |
| REST | 表述性状态转移 |
| DDD | 领域驱动业务建模 |
架构模式是什么
架构模式 - 架构风格在某个特定上下文问题中的解决方案。
RESTful API是一种架构模式，是REST风格在Connector API场景中的问题解决方案。
| 架构模式 | 所属架构风格 | 描述 |
|---|---|---|
| MVC | 组件化 | Model-View-Controller |
| MVVM | 组件化 | Model-View-ViewModel |
| ESB | 消息总线 | 企业服务总线 |
| 三层架构 | 分层架构 | 表现层-业务层-持久化层 |
| 微核心架构 | 插件化 | |
| 管道命令行 | 管道过滤器 | Channel-Filter |
| 六边形架构 | 分层架构 | 应用层-插件层-适配器层 |
| Clean架构 | 分层架构 | |
| RESTful API | REST | 表述性状态转移 |
| CQRS | DDD | 领域驱动设计 |
| Event Sourcing | DDD | 领域驱动设计 |
注：架构风格和模式并没有行业标准定义
风格模式设计方法
架构风格 + 架构模式 = 风格模式设计方法
行业有架构风格和模式的定义，但是相信大部分研发同学并没有使用过，没有使用过1是因为没看过；2是因为比较难用。领域驱动开发（DDD）在行业中享有盛名，但是在产品代码层面很难落地一样，风格模式在具体项目中很难应用并且没有标准使用方法。
类比思维也是常用的思维方式，下面用一种类似来说明风格和模式的作用。
如何设计寺庙宫殿
建筑设计和架构设计有一定共通性，借鉴风格模式的设计的思路和方法去思考如何设计寺庙宫殿。
寺庙宫殿
首先抽象下寺庙宫殿的共性风格是什么，以成果导向思考需要达到什么约束就成为寺庙宫殿。参照上图直接抽象出架构风格。
- 庄严肃穆
- 有一定高度
- 有房顶和尖角颜色鲜艳
- 门和装饰多
然后使用架构风格的约束条件，在中西方不同场景下针对性设计如下。
| 架构模式 | 模式表达 |
|---|---|
| 中式寺庙模式 | 多层角、主色红色黄色、左中右三道门、琉璃瓦 |
| 西式宫殿模式 | 多层楼、连廊和柱子、多门窗、多雕刻 |
最后得到的就是有一定专业深度的架构设计成果，风格和模式的另外一个作用是发现冲突或不和谐，比如下面视图，明显存在风格模式冲突的混搭风设计，混搭风不是问题，问题是容易导致团队无法很好达成共识并导致最终设计不一致。
建筑混搭风
在代码层面同理，如果将不同层次间的代码合并到一起，一定会有明显的代码“坏味道”。
代码混搭风
分层架构风格模式
使用架构风格和模式方法描述分层架构设计。
分层架构
- 架构风格 - 分层架构，约束（分层，上层依赖下层，下层不依赖上层）
- 架构模式 - 三层系统架构、N-Layer层系统架构
分层架构风格的具体应用，六边形架构模式和Clean架构模式
领域驱动风格模式
使用架构风格和模式方法描述领域驱动设计。
领域驱动设计
- 架构风格 - 业务建模，约束（上下文、领域、子领域、实体和服务）
- 架构模式 - 微服务领域设计、CQRS、Event Sourcing
结构化设计总结
| 结构化设计 | 设计总结 |
|---|---|
| 架构风格 | 一组约束条件 |
| 架构模式 | 架构风格在某个特定上下文中的解决方案 |
| Architecture Style | architecture approach. |
| Architecture Pattern | { problem, context } → architecture approach. |
行业中的最佳实践就是积累的各种架构风格和模式。
