从业务角度论证如何采用 REST 风格架构

在一系列题为“REST 对话”的连载博文中，Duncan Cragg“为eBay 列举了应该给他们的集成API 采用一种真正REST 方法的论据”。在《业务对话》一文中，Duncan 从业务角度对REST 风格架构的采用进行了论证。

Duncan（以一种对话风格）向一个虚构的 eBay 架构师解释说，使用 RESTful 方法构架业务流程要比使用以 WS-* 规范为基础的 SOA 构建方法更简单，但更强大。关于应用架构师的角色，他说道：

在设计应用层资源交互，或者也可能是在架构师使用某些现有资源类型以及使用帮他完成业务逻辑的‘资源激活’代码时，架构师的工作是：资源类型或业务层。要是使用 WS-*，只会把这项任务搞得混乱和复杂。

“当你是从资源而不是动作出发进行思考时，所有事情都变得更清晰了”，在谈到用面向资源架构（ROA）来处理诸如服务发现和描述、客户端状态和会话，业务流程的问题时，Duncan states 这样说道。他还提到：

最好由松散的协议和已建立的惯例作为起始点；只在绝对必要时才添加约束、契约和中央控制。确保中央控制仅在模式（schema）之上。

使你的企业能够‘Mashable’，这样每个人都会对你感恩戴德。在 URL 中暴露数据的 UUID 和 GUID。在标准内容类型内对数据进行转换和修饰。

对于在这样一种架构中管理客户端的状态，他警告说：

任何隐藏状态都是一个危险信号。只要在 URI 中暴露状态信息，你就会知道一切运转正常。[……] 如果你发现你自己在会话或 cookies 中隐藏状态，或是通过设置 no-cache 返回该客户端专用的不同数据，或是如果你通过会话把连续的交互紧紧地绑在了一起，你就走向了一条不归路。

他承认这样一种方法可能很难在企业内推广，但是又表示它“更紧密地映射到了业务操作和互操作的实际发生方式”。

REST[……] 很自然地映射到声明性的业务规则上。当你从“流程思维”转换到“资源思维”时，你还必须把思维转换成声明性的。与协调两个手工编码的接口间数据的导入导出不同，你只能把它们全都链接起来，并指望人们可以提取（derefernce）和发现你的数据。

请分享你在企业中推广 Restful 风格的经验，另外再看看原文和这个系列文章。

查看英文原文： RESTful Business Conversations