Today we are releasing refreshed NuGet packages as well as an installer for WCF Data Services 5.1.0-rc2. This RC is very close to complete. We do still have a few optimizations to make in the payload, but this RC is very representative of the final product.
The RC introduces several new features:
We’ve blogged a few times about the new JSON serialization format. We think this new format has the feel of a custom REST API with the benefits of a standardized format. What does that mean exactly?
If you were to create a custom REST API, you probably wouldn’t create a lot of ceremony in the API. For example, if you were to GET a single contact, the payload might look like the payload below. In this payload, objects are simple JSON objects with name/value pairs representing most properties and arrays representing collections. In fact, the only indicator we have that this is an OData payload is the first name/value pair, which helps to disambiguate what is in the payload.
"StreetAddress":"5678 2nd Street",
In an upcoming blog post, we’ll dig more into what’s so awesome about this new format.
One of the reasons OData is so powerful is that it has a very predictable set of patterns that enable generic clients to communicate effectively with a variety of servers. This is very different from the custom REST API world, where clients need to read detailed documentation on each service they plan to consume to determine things like:
When we combine the terseness and custom feel of the new format with the power of standardization, we get a payload that is only ~10% of the size of AtomPub but is still capable of producing the same strong metadata framework.
We’ve simplified the process for telling the client to ask for the new serialization format. Now all you need to do is call context.UseJsonFormatWithDefaultServiceModel() (the jury’s out as to whether this will be the final API name, but you can be sure it will be as simple as a single method call). To get to that level of simplicity, we had to modify some things in code gen, so you’ll need to download the installer we just released if you want to simplify the process of bootstrapping a client.
Finally, we have added two new events on the client side.
SendingRequest2 (and its deprecated predecessor SendingRequest) fires after the request is built. WebRequest does not allow you to modify the URL after construction. The new event lets you modify the URL before we build the underlying request, giving you full control over the request.
This is an event the community has requested several times. When we receive ANY response on the client, we will fire this event so you can examine response headers and more.
There are still some things for us to do, but most applications will be unaffected by them (or will experience a free performance boost when we RTW). Please understand that these are our current plans, not promises. That said, here’s the remaining list of work we hope to complete by RTW:
Among the other bugs and issues we’ve already identified, you should be aware that if you install the MSI referenced above, any new code gen’d service references will require the project to reference WCF Data Services 5.1.0. We will have an acceptable resolution for this problem by RTW.
This is a big release. We could really use your feedback, comments and bug reports as we wind down this release and prepare to RTW. Feel free to leave a comment below or e-mail me directly at firstname.lastname@example.org.
Thanks for releasing an installer. I know that NuGet is the big push right now, but some company infrastructures don't play nice with direct NuGet downloads.
When will it be possible to assign a CookieContainer to a DataServiceContext?
We use several web service endpoints (some of them are odata), pushing cookies on every request is very annoying, especially when server updates them during odata request - update is simple lost
When can we expect the final release? I am eagerly awaiting it and plan to use it for our product to reduce the overhead of sending 10000's of rows using xml.
Thank you for the recent release. I am also waiting for the stable version because I expect to get a lot of advantages by using JSON light format.
Same here - on my initial tests, its saving cutting down data sent over the wire by about 70%.
Also anxiously awaiting the final release! Good work guys, this is exactly what oData has needed since it's conception!
Yes, anxiously awaiting the new release too, this is a major release, wish it was implemented a long time ago! Good work guys!
Will the DS Client framework be able to use the JSON light format, or does it still only work with ATOM?
The client can use the new JSON serialization format by calling context.UseJsonFormatWithDefaultServiceModel().
You have to install www.microsoft.com/.../details.aspx this for the code generator to be up to date however.
@Lex Lavnikov - You can assign a CookieContainer by using the SendingRequest2 event on DataServiceContext. Pass the SendingRequest2EventArgs instance into the following method:
internal static void EnsureCookieContainer(SendingRequest2EventArgs e)
HttpWebRequestMessage requestMessage = e.RequestMessage as HttpWebRequestMessage;
if (requestMessage != null)
requestMessage.HttpWebRequest.CookieContainer = cookieContainer;
Would love to see the spatial integration with EF DB-first models fixed / interoperate.
Interesting post!!! HoustonTotal home services is to provide our clients with quality services houston painting that we would be proud to call our own.