关于REST的一些思考

August 22, 2015 // Tagged in: REST RESTFUL

REST,即表述性状态转移(传递)(英文:Representational State Transfer)
非常拗口的翻译以及英文描述。

“学而不思则罔,思而不学则殆” ,子曰的太对了。 想得多不写出来, 攒的多了也就忘记了,俗语好脑袋不如烂笔头也是非常有道理di~~。

我对REST的理解,是从业务开始理解的,并没有拜读过Roy Fielding博士的那篇论文,大概是因为英文,有好的翻译当然还是会看下的。 写到这里,觉得还是不要懒了,至少给个链接。

roy的论文 Architectural Styles and the Design of Network-based Software Architectures 中文版本翻译

软件架构的核心抽象原则: 通过封装来隐藏系统的一些细节, 从而更好的识别和支持系统的属性。

我的理解:
根据项目的实际需求来设计架构风格, 而不是用已有(或者旧有的)架构去套用实际的应用和需求。
首先REST就是根据web的特点来实现的一种架构约束或者风格。

REST强调:
1、 组件交互的可伸缩性
2、 接口的通用性
3、 组件的独立部署
4、 用来减少交互延迟
5、 增强安全性
6、 封装遗留系统的中间组件

首先, 这几点都提到了组件(components),最近组件(web components)很流行啊,翻篇到2000年也蛮流行。
论文中提到的:
组件 :计算和状态的所在地。
处理元素:状态的转换。
看到没有,表述性状态转移,觉得表述性状态转换更实在一些,但没有转移更能体现web的特点。

组件就是计算和状态的所在地, 也是文绉绉的,我的理解是组件是一个带交互的资源集合,既可以细化到一个业务资源(图书馆系统的书架),也可以理解为图书馆系统本身,更可以认为是部署这个系统的一个脚本文件。这样就牵扯到组件粒度的概念,如何把一个具体的业务划分为一个组件。
(PS:另外论文也提出了一点, 软件运行时的架构和源代码架构本身也是要区分的。)

说完组件,我们说元素:

一个软件架构由一些架构元素(组件,连接器,数据)的配置来定义,这些元素之间的关系受到约束,以获得想要得到一组架构属性。

组件也可以是一个元素,连接器也是一个元素,数据也是一个元素。 组件:计算和状态的所在地的元素 连接器:定义组件之间的交互的元素 数据:被使用和被转换的的元素