Dhananjay Nene，曾写过一篇记录 REST 的历史的好文章，在这里他探讨了设计一个面向资源的框架（ROF）应具备的几种特征，这篇文章的另一个探讨内容是尝试捕捉应用程序的细粒度对象模型与资源模型之间的关系。
对Dhananjay 而言，由于一些流行的框架如Struts，Django 和Ruby on Rails 等，有几个特征是ROF 理应具备的。然而，把它们明确地列举出来，并为其下个定义，可以促进ROF 走向成功和流行。Dhananjay 讨论了以下几个方面的特征。
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 应提供用于定位资源的工厂方法，或者应允许其他资源或业务对象的注入。
开发者可能从两个层面使用框架，粗粒度（资源）或细粒度（业务对象）。框架应该提供对这类活动的支持。
ROF 应允许资源或媒体类型描述与资源表示一起发送：因为 REST 支持媒体类型的自动发现和自动描述，框架也应该允许这类媒体类型的元数据信息对客户端可见。实际的元数据可以使用任何合适的典型标准描述，如 RDFa，XML 模式片段等。
暂无签名
中国卓越技术团队访谈录（2022 年第二季）
本迷你书精选了微软 Edge、蚂蚁可信原生、明源云、文因互联、Babylon.js 等技术团队在技术落地、团队建...
评论