WCF Data Service 5.1.0-rc2 Released

發行項
09/26/2012

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:

~~JSON Light~~ The new JSON serialization format
$format/$callback
New client-side events for more control over the request/response lifecycle

The new JSON serialization format

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?

The feel of a custom REST API

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.

 {    "odata.metadata":"https://contacts.svc/$metadata#MyContactsService/Contacts/@Element",    "LastUpdatedAt":"2012-09-24T10:18:57.2183229-07:00",    "FirstName":"Pilar",    "LastName":"Ackerman",    "Age":25,    "Address":{       "StreetAddress":"5678 2nd Street",       "City":"New York",       "State":"NY",       "PostalCode":"98052"    },    "EmailAddresses":["pilar@contoso.com","packerman@cohowinery.com"],    "PhoneNumbers":[       {          "Type":"home",          "Number":"(212) 555-0162"       },       {          "Type":"fax",          "Number":"(646) 555-0157"       }    ] }

In an upcoming blog post, we’ll dig more into what’s so awesome about this new format.

The benefits of a standardized 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:

How do I construct URLs?
What is the schema of the request and response payloads?
What HTTP verbs are supported, and what do they do?
How do I format the request and response payloads?
How do I do advanced operations like custom queries, sorting, and paging?

Standardization + custom feel = new format

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.

Code gen

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.

$format/$callback

In this release we’ve also provided in-the-box support for $format and $callback. These two system query options enable JSONP scenarios from many JavaScript clients. As a personal comment, I’ve also really appreciated not having to jump into Fiddler quite as much to look at JSON responses.

New client-side events

Finally, we have added two new events on the client side.

BuildingRequest

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.

ReceivingResponse

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.

But wait, there’s 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:

Relative URLs: When the server generates a URL and that URL actually needs to be in the new JSON serialization format, the server should automatically try to make it a relative URL.
Actions/functions: There’s a little bit more smoothing necessary for action and function support.
Disable the new format: Hopefully you’d never want to do this, but we have a common practice of allowing you to disable features in WCF Data Services.
Bugs: We have some bugs and inconsistencies that we already know about that need to be fixed before we have release quality.

Known Issues

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.

We need your help

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 mastaffo@microsoft.com.

Comments

Anonymous
September 30, 2012
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.
Anonymous
October 01, 2012
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
Anonymous
October 02, 2012
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.
Anonymous
October 02, 2012
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.
Anonymous
October 03, 2012
The comment has been removed
Anonymous
October 14, 2012
Also anxiously awaiting the final release! Good work guys, this is exactly what oData has needed since it's conception!
Anonymous
October 14, 2012
Yes, anxiously awaiting the new release too, this is a major release, wish it was implemented a long time ago! Good work guys!
Anonymous
October 15, 2012
Sounds good. Will the DS Client framework be able to use the JSON light format, or does it still only work with ATOM?
Anonymous
October 17, 2012
Uffe, 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. -Sean
Anonymous
November 06, 2012
@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) { if (!e.IsBatchPart) { HttpWebRequestMessage requestMessage = e.RequestMessage as HttpWebRequestMessage; if (requestMessage != null) { requestMessage.HttpWebRequest.CookieContainer = cookieContainer; } } }
Anonymous
November 19, 2012
Would love to see the spatial integration with EF DB-first models fixed / interoperate.
Anonymous
May 21, 2013
Interesting post!!! HoustonTotal home services is to provide our clients with quality services houston painting that we would be proud to call our own.
Anonymous
July 21, 2013
Where can I find the final release?
Anonymous
July 28, 2013
i like this

共用方式為