title: Universal RESTful Data API framework
body: <p>we are implementing an operational data store for some key data sets ("single view of customer", "single view of employee") to provide meaningful integrated data primarily to front office applications (primarily B2E....i.e. both provider and consumer are controlled internally, no external exposure).</p>
  
  <p>All the "single views" will be centered around a slow changing master business entity ("customer", "employee", "asset", "product") which has related child/satellite entities which are more transactional/fast changing in nature (i.e. bookings, orders, payments etc.). The different "single views" will be overlapping and interconnected.</p>
  
  <p>So this ODS would become a data abstraction layer between disparate "systems of record" and vertical systems of engagement, providing a traversable data universe decoupling clients from producers</p>
  
  <p>Of course, an ODS is pointless if there is no way to access the data. Therefore, I am looking for some kind of elegant way to implement a resource based data services layer on top of the ODS with some of the following characteristics</p>
  
  <ul>
  <li>Stateless</li>
  <li>REST Level 3 (HATEOS) but most likely limited to GET's (i.e. create, update, delete would be executed against the actual "system of record" in order to apply business logic)</li>
  <li>abstraction between enterprise data model (=domain entities are exposed as representations) and physical data model (=actual data is stored in physical tables)...no leakage of physical data model</li>
  <li>support for common query features, such as order by, paging etc.</li>
  <li>easy to use for developers, decoupled from physical data model and backend system changes</li>
  <li>Ideally not constrained to relational db's even though this could be optional for now.</li>
  </ul>
  
  <p>The key standard I came across for that would be OData, but there is a couple of concerns though</p>
  
  <ul>
  <li>It is very MS centric both from a standard (now OASIS) but more importantly from an implementation perspective (.NET, WCF Data services). We are an enterprise java shop.</li>
  <li>A couple of frontrunners (netflix, ebay) have sunsetted their OData services which is always a concerning thing</li>
  <li>OData has been touted as a magic blackbox which exposes the underlying datamodel more or less automatically. That means that there is no "human translation"/modelling in between, and the service layer therefore doesn't provide the abstraction that is one of the key requirements.</li>
  </ul>
  
  <p>Now, some of these disadvantages might not be that critical as we don't plan to expose the data services layer to the external world, but rather use it within our own environment (i.e. rather small number of consumers which can be controlled).But then the question is how much value OData adds.</p>
  
  <p>I do know that there are no free lunches out there :-)</p>
  
  <p>Are there any other approaches of how to implement a generic data access layer ?</p>
  
  <p>thx a lot, Nick</p>