面向资源的服务端框架的设计特征

作者 Dilip Krishnan 译者 马国耀 发布于 2009年6月14日

领域

架构 & 设计,

企业架构

主题

设计 ,

SOA ,

REST

标签

框架

Dhananjay Nene，曾写过一篇记录REST的历史的好文章，在这里他探讨了设计一个面向资源的框架（ROF）应具备的几种特征，这篇文章的另一个探讨内容是尝试捕捉应用程序的细粒度对象模型与资源模型之间的关系。

ROF应有一个抽象层来将资源表示成端点

假设有一个Order资源，如果在OrderController上引入一个Approve方法，那么这种做法就和上述特征相违背。好的做法是建模一个OrderApproval资源，成功完成时，把Order资源的状态修改成“approved”

鉴于资源操作的一致性预期，这些动作将会魔术般地自动完成。

ROF应提供典型的生命周期管理的附加支持。（如，验证）

框架提供资源接口方法的默认实现[并且]框架也应允许开发者插入或覆盖自己的实现。[并支持生命周期管理的任务，如验证。]

ROF应可以让开发者覆盖和注册自己的方法以处理PUT，POST和DELETE操作带来的下游影响。

我曾把REST系统类比成一个DBMS系统，在这里客户端应用程序可以在数据库表（对应于REST的资源）上直接操作SQL语句，如 SELECT、INSERT、UPDATE、DELETE（对应于HTTP/REST中的GET、PUT、POST和DELETE），而业务逻辑可以被实现为触发器。因此，框架应该为开发者提供定义触发器的机制。

ROF应为开发者提供一种机制以让他们描述或映射资源抽象与实际程序结构之间的关系。

实现的方法很多，如XML, YAML, DSL和Annotation——任你选择。另外，还可以定义实际的对象（如POJO），它所映射的资源特征或这个类可以通过基于元数据的元数据编程让其在运行时暴露自己。框架应提供对（业务模型）关系的描述和内省（introspected）。

ROF应支持跨资源的外键，把资源表现成映射底层业务对象引用的URI。

资源通过URI引用其他资源，而底层业务对象通过对象引用指向其他业务对象。通过资源描述和URI映射，框架可提供URI和对象应用之间的透明的引用和/定位引用资源的机制。

以上列举出来的ROF特征看起来是RESTful服务理应具备的特征，而另外一些特征可能需要进一步的解释和讨论，或许只作为升华和完备。

ROF应提供用于定位资源的工厂方法，或者应允许其他资源或业务对象的注入。

开发者可能从两个层面使用框架，粗粒度（资源）或细粒度（业务对象）。框架应该提供对这类活动的支持。

ROF应允许资源或媒体类型描述与资源表示一起发送：因为REST支持媒体类型的自动发现和自动描述，框架也应该允许这类媒体类型的元数据信息对客户端可见。实际的元数据可以使用任何合适的典型标准描述，如RDFa，XML模式片段等。

尽管Dhananjay指出的这些特征已相当全面，但文章并没有强调非功能性方面的需求，如监视、审计和日志、事务管理、对象池等。欲了解详细内容一定要读原文
查看英文原文：Design Characteristics Of Resource Oriented Server Frameworks

译者 马国耀 关注企业级应用相关的开发、架构及思想的发展。尤其对Java EE、SOA、ESB和Cloud Computing等领域持有浓厚兴趣。

• 更早的 >