通用RESTful数据接口框架

Question

我们正在为一些关键数据集(“客户的单一视图”、“员工的单一视图”)实现一个操作数据存储，主要为前台应用程序(主要是B2E)提供有意义的集成数据。供应商和消费者都受到内部控制，没有外部曝光)。

所有的“单一视图”将围绕着一个变化缓慢的主业务实体(“客户”、“雇员”、“资产”、“产品”)，该实体具有相关的子/卫星实体，这些实体在性质上更具事务性/快速性(即预订、定单、付款等)。不同的“单一观点”将相互重叠和相互关联。

因此，这个ODS将成为不同的“记录系统”和垂直的接触系统之间的数据抽象层，从而提供一个可遍历的数据宇宙，使客户端与生产者脱钩。

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

• 无国籍
• REST级别3 (HATEOS)，但很可能仅限于GET(即创建、更新、删除将针对实际的“记录系统”执行，以便应用业务逻辑)
• 企业数据模型(=域实体以表示形式公开)和物理数据模型(=实际数据存储在物理表中)之间的抽象(物理数据模型的...no泄漏)
• 支持常见的查询功能，如order、分页等。
• 易于开发人员使用，与物理数据模型和后端系统更改分离。
• 理想情况下，即使这暂时是可选的，也不局限于关系数据库。

我遇到的关键标准是OData，但是有几个问题

• 从标准(现在的OASIS)来看，它非常以MS为中心，但更重要的是从实现的角度来看(.NET，WCF数据服务)。我们是一家企业爪哇店。
• 一些领跑者(netflix，ebay)已经推出了他们的OData服务，这一直是一件令人担忧的事情。
• OData被吹捧为一个神奇的黑匣子，它或多或少会自动公开底层的数据模型。这意味着之间没有“人工翻译”/modelling，因此服务层没有提供作为关键需求之一的抽象。

现在，这些缺点中的一些可能并不那么关键，因为我们不打算向外部世界公开数据服务层，而是在我们自己的环境中使用它(也就是可以控制的数量相当少的消费者).But，然后问题是OData增加了多少值。

我知道外面没有免费午餐：)

对于如何实现通用数据访问层，还有其他方法吗？

很久以前，尼克

Answer 1

要回答您对OData的关切：

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

此外，尽管您的计划是只为有限的访问公开数据服务。OData特性，如查询性、RESTful数据API和新的OData V4引人注目的特性 (如增量响应、异步请求、服务器端聚合)，肯定会帮助您编写更高效、更强大的数据发布和消费故事。