通用RESTful数据API框架

Question

我们正在为一些关键数据集实施运营数据存储（＆＃34;客户的单一视图＆＃34;＆＃34;员工的单一视图＆＃34;）以主要向前台办公应用程序提供有意义的集成数据（主要是B2E ....即提供者和消费者都是内部控制的，没有外部暴露）。

所有＆＃34;单一观点＆＃34;将以一个缓慢变化的主业务实体（＆＃34;客户＆＃34;，＆＃34;员工＆＃34;，＆＃34;资产＆＃34;，＆＃34;产品＆＃34;）为中心儿童/卫星实体在性质上更具交易性/快速变化（即预订，订单，付款等）。不同的单一观点＆＃34;将重叠并相互联系。

因此，这个ODS将成为不同的记录系统之间的数据抽象层。和垂直的参与系统，提供可交叉的数据领域，将客户与生产者分离

当然，如果无法访问数据，ODS就毫无意义。因此，我正在寻找某种优雅的方式在ODS之上实现基于资源的数据服务层，具有以下一些特征

• 无状态
• REST Level 3（HATEOS）但很可能仅限于GET（即创建，更新，删除将针对实际＆＃34;记录系统＆＃34执行;以便应用业务逻辑）< / LI>
• 企业数据模型之间的抽象（=域实体作为表示公开）和物理数据模型（=实际数据存储在物理表中）......没有物理数据模型泄漏
• 支持常见查询功能，例如分页依据，分页等。
• 易于开发人员使用，与物理数据模型和后端系统更改分离
• 理想情况下不受约束关系数据库的限制，即使现在这可能是可选的。

我遇到的关键标准是OData，但有一些问题，但

• 它从标准（现在是OASIS）开始以MS为中心，但更重要的是从实现角度（.NET，WCF数据服务）。我们是一家企业java商店。
• 一些领跑者（netflix，ebay）已经落实了他们的OData服务，这一直是一件令人担忧的事情
• OData被吹捧为一个神奇的黑盒子，它会或多或少地自动暴露底层数据模型。这意味着它们之间没有人工翻译和建模，因此服务层不提供作为关键要求之一的抽象。

现在，其中一些缺点可能并不那么重要，因为我们不打算将数据服务层暴露给外部世界，而是在我们自己的环境中使用它（即相当少的消费者可以然后问题是OData增加了多少价值。

我知道那里没有免费的午餐： - ）

是否有其他方法可以实现通用数据访问层？

很多，尼克

Answer 1

回答您对OData的疑虑：

• OData以MS为中心的陈述不再适用。特别是当您使用Java编写服务或客户端时，这对您来说是一个非常好的消息。 Apache Olingo project目前是以开源方式维护和开发的，而Microsoft只是其中的一个贡献者。该项目基于OData V2版本，也将支持OData V4。
• Netflix和Ebay确实不再公开他们的OData服务了。但根据OData.org对OData生态系统的监测，有新的OData服务和客户不断发布。 （OData.org已开始accept contribution to the ecosystem）
• 我不确定我是否正确理解了这个项目。但如果我这样做，OData vocabularies（OData标准中的一部分）可能能够解决您的问题。与使用术语注释的OData模型一样，您可以为服务功能添加更多“人工规范”，并对数据和模型进行更多控制。结果是，客户端将能够智能地“人工翻译”数据和模型，以更好地与服务进行交互。更好的词汇表是，尽管协议保留了注释的规范命名空间，但您也可以定义自己的词汇表，并让任何想要使用您的服务的人接受它，因为OData的词汇表是可扩展的，如定义的那样在OData协议中。

此外，尽管您的计划是仅公开数据服务以进行有限访问。 OData特性，例如queryablility，RESTful数据API和new OData V4 compelling features，例如增量响应，异步请求，服务器端聚合，肯定会帮助您编写更高效，更强大的数据发布和消费故事。