One of the the coolest things about Data Services is its provider model.
Any data-source can be exposed as an OData Data Service simply by implementing a few interfaces. SharePoint 2010 implements these interfaces to expose list data, and you can too, to expose just about anything: Facebook? Twitter? You name it.
Once you’ve done that you can query the data using any of the OData clients, including PowerPivot, LINQ over Data Services etc etc.
Now Data Services ships a couple of providers in the box, including one for the Entity Framework and one that works against in memory objects using reflection.
In this series of posts I will walk through creating a Custom Data Service Provider (DSP) slowly layering in more and more capabilities.
There are 5 new interfaces:
Astoria uses this interface to reason about available ResourceTypes, Properties, Keys, NavigationProperties and ResourceSets.
Astoria converts all GET requests into calls against this interface.
If your Data Source is Read/Write, you need to implement this interface because Astoria uses it for all PUT, POST and DELETE requests.
If you want to gain ‘fine grained control’ over Server Driven Paging you need to implement this interface.
If you want to support Media Link Entries you need to need to implement this interface because Astoria uses it to manipulate the underlying stream.
In Part 2 we’ll see how Data Services learns about your custom DSP and gets hold of your implementation of these interfaces…