WCF Data Service 5.1.0-rc2 Released

DB Blogs

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":"http://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.

DB Blogs

Follow