面向资源的基于网络的架构风格REST

Roy T. Fielding博士是许多基本Web协议的主要设计者, 其中包括HTTP和URIs. Roy在他的博士学位论文中定义了术语REST. REST是一种面向资源的基于网络的架构风格, 全称表述性状态转移(Representational State Transfer). 这个抽象的名字的由来Roy是这样解释的:

The name "Representational State Transfer" is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.

我的理解是:

符合REST风格的基于网络的架构中, 服务端应用通过提供资源的方式来暴露功能:
1.资源有ID
        如: WEB架构中, URI协议.
2.资源有统一接口
        如: WEB架构中, HTTP动词: get代表"现", 可缓存, 具有幂等性; put代表"变", 具有幂等性; delete代表"灭", 具有幂等性; post代表"生".
3.资源有状态, 资源状态有多重表述
        如: WEB架构中, HTTP内容协商.
4.资源状态表述中要将其他相关资源用资源ID连接起来
        如: WEB架构中, 超媒体被当做应用状态引擎.
5.服务端应用不保存会话状态
        如: WEB架构中, HTTP协议无状态.
客户端与服务端应用交互过程中, 客户端通过资源ID和资源统一接口来请求指定资源的访问. 服务端应用通过返回应用状态表述来响应客户端的请求. 应用状态由存储在服务端的资源状态和保存在客户端的会话状态组成, 而应用状态表述则是附着着会话状态的资源状态表述. 应用状态可以由应用状态表述来表示, 所以被称为Representational State(表述性状态或具象状态).

InfoQ上的一篇文章深入浅出REST中总结了REST的5个关键原则, 可作为实践指导:

1.为所有资源定义ID

2.将所有资源链接在一起

3.使用标准方法

4.资源多重表述

5.无状态通信

另一篇文章解答有关REST的十点疑惑中探讨了如下几个常见问题:

01.REST也许适用于CRUD, 但并不适用于"真实的"业务逻辑

02.没有正式的契约与描述语言

03.谁真会把他们应用中如此多的实现细节暴露出来?

04.REST只能配合HTTP使用, 它不是传输协议无关的

05.没有实际的, 明确且一致的指南教你如何设计REST式应用

06.REST不支持事务

07.REST是不可靠的

08.不支持发布/订阅

09.无异步交互

10.缺少工具

文章在RESTful应用程序中的超媒体深入的讨论了"超媒体即应用状态引擎(hypermedia as the engine of application state)"的含义, 可加深对REST的理解.