Showing results for Design Notes - OData

We recently put together a document that contains some of our thinking about JSON light as well as a whole slew of sample payloads. We would love to hear any feedback you have on the format; you can comment in the accompanying OneNote. We will be accepting public feedback on JSON light until May 4, 2012. We will also provide a preview release of t...

Problem Statement OData (the protocol used by WCF Data Services) enables you to address the relationships between Entries. This functionality is required to be able to create or change a relationship between two instances, such as an Order_Detail that is related to a given Order. Currently the OData protocol requires clients and servers to agree up...

One of the scenarios we have heard feedback around is the ability for the a client of a data service to determine the total number of entities in a set without having to retrieve them all. The following video discusses this scenario in more detail and some of our thoughts regarding how to make the experience better.    Astoria Design ...

As we already discussed in a previous blog post, one of the problem spaces related to data services we’d like to take on is synchronization-capable services, enabling offline scenarios. We’re still in the early stages of the project, where direction can be adjusted and good feedback can be very influential. Giving good feedback without...

We mentioned that we were doing some early thinking of “Astoria Offline” back in Mix 2008, where we even demo’ed an early proof of concept. Now we’ve been working on various design aspects of Data Services for its future versions, and synchronization/offline support is one of them. It’s still an experimental thing with...

The goal of Astoria in V1 is to easily expose a data source using the REST approach to the web (with support for concurrency, versioning, auth, etc).  In general, the way we think about serialization formats (ie. how we represent entites on the wire) is that they are a tool and an application will select the best tool (ie. serialization format...

So far Astoria has used “merge” semantics for update. That is, an “update” operation (an HTTP PUT request) replaces the values of the properties for the target entity that are specified in the input payload; this applies both to properties and links. If a property or link is not present in a PUT operation, it means “leave it with its current value”...

Different applications have different requirements around consistency and how concurrent modifications are handled. I’ll oversimplify and put all these applications in two buckets: either you care about controlling concurrent changes or you don’t. If you’re creating a REST interface to your data and don’t care about concurrency (e.g. no deep consis...

Astoria service allows reading/querying of data via the already-established IQueryable interface – this helps in abstracting Astoria from the underlying data source. But there is no existing interface for the update operations (CUD – create, update, delete operations). Hence we came up with IUpdatable interface to support CUD operations and support...

We have received a fair amount of feedback regarding a number of use cases where it would be beneficial to enable a client of a data service to “batch” up a group of operations and send them to the data service in a single HTTP request.  This reduces the number of roundtrips to the data service for apps that need to make numerous requests to t...