Problems with the WCF Web API

Topics: Web Api
Jan 19, 2012 at 11:19 AM

Hi,

I thought I'd start a discussion about the WCF Web API from the point of view of someone developing a website or mobile application. The use case is quite simple: Make an Ajax call to the service sending an optional JSON object and receive a JSON object or an array of JSON objects in response. I am struggling to find anything useful in the WCF Web API. Here are my thoughts.

 

Media Type Processors

This is a way to return a different result type from a service call depending on the accept header. E.g. XML, JSON, or an image.

Problem: We only ever need JSON from the service. While it would be brilliant to serve up images from the server, it is not possible to influence the accept header when the browser makes a request for the URL specified in the src attribute of an image tag.

 

The JsonValue dynamic type as an input parameter and return value

The following example demonstrates usage:

    public JsonValue Post(JsonValue contact)
    {
        var postedContact = (dynamic)contact;
        var contactResponse = (dynamic)new JsonObject();
        contactResponse.Name = postedContact.Name;
        contactResponse.ContactId = nextId++;
        return contactResponse;
    }

Problem: While this is fine as a return value, we don't really want to work with loosely typed objects on the server side. Ideally the WCF pipeline should attempt to convert the input stream into whatever CLR type has been specified as the input parameter, in a case-insensitive fashion, very much like how ASP.Net handles it. Ignoring case is important because JSON on the browser is generally camel case, while CLR types tend to favour Pascal case.

 

 

Queryability

 This appears to be a way of querying the service either by specifying URL parameters or using the HTTP client class. The latter is not relevant for the web, and there are better alternatives to the former, namely a more restful and structured approach. The suggested technique of simply exposing the entire database through a single service call is not very appealing.

 

HTTP Client

Not relevant for the web. Could possibly be used for inter-service communication.

 

HTTPRequestMessage and HTTPRespnseMessage

Possibly the only thing that is useful. This makes the service more testable. But surely this can be implemented via a WCF operation behaviour?

 

Request and Response Processors

These convert elements of a URI into CLR types. But really all we need is to convert JSON to CLR types. And that is already well-established.

 

Am I missing the point?

Jan 19, 2012 at 3:33 PM

1) you can write a handler to force always json input/output

2) That is OData.. its a web standard becoming very popular. http://www.odata.org/ Lots of people would disagree that in the URL isnt a better alternative.

3) You don't really need an HTTP Client for javascript because frameworks do it for you already. jQuery, prototype.

4) You do not have to use JsonValue... you can make an input class and just accept that, and it will serialize your input to it. It only supports one input model. This is common to normal "1 for 1" MVC controller to input model design methods.

Coordinator
Jan 19, 2012 at 7:46 PM

One of the main benefits of Web APIs is that you can support a broad set of clients: browser, mobile, desktop, tablets, etc., and depending on the client you are targeting different formats become interesting. There are a lot of interesting formats out there: ATOM, OData, XML Binary formats, etc. Even on the web JSON is not the only interesting format. The Contact Manager sample, for example, includes a VCARD formatter which can be used to import contacts directly into gmail.

When dealing with JSON data you can use strongly typed input parameters (just like you can for any format that you have a formatter for). In many cases using JsonValue to deal with JSON data dynamically can be pretty convenient since the data in the browser is loosely typed anyway, but it is not the only way to deal with JSON data. Admittedly, our JSON serialization story does have some rough edges and we are looking to make improvements here. Some Web API users, for example, have implemented a JSON.NET formatter. We are also deeply integrating Web API with MVC and the integrated stack will support full MVC-style model binding.

You are right that the HttpClient is important for server to server calls, but it also will be fully supported in Win8 Metro apps, so there is an important client scenario as well. By building on HttpRequestMessage and HttpResponseMessage we also get a symmetric HTTP story on the client and server.

Request and response processors are really about enabling you to factor out HTTP processing from your operations so that your operations can focus on business logic. They also enable you to pull in additional information not in the request and pass it to the operation. Most of the translation from the request to input parameters is actually done by the formatters.

Additional benefits you get form Web API include:

· Ability to self-host your Web API in your own process (ex in Azure Worker Role, or a Windows Service)

· Rich test client and automatic help page generation

· Full support for the new Task-based async programming model

Hope this helps.

Daniel Roth

Feb 13, 2012 at 10:49 AM

>>You are right that the HttpClient is important for server to server calls, but it also will be fully supported in Win8 Metro apps

Daniel, do you have any experience or success with installing .6 version to a Win8/Metro C# application?  When I try and install from Nuget, it installs and then uninstalls.

Feb 13, 2012 at 12:41 PM
We have not enabled this support yet, but when we do, it will be a special Win8 Metro-compatible version of System.Net.Http.Formatting.
Feb 13, 2012 at 1:02 PM

Thanks Brad, I guess you can't say if you are working toward that goal to coincide with the win8 beta at the end of February?

Feb 13, 2012 at 5:11 PM
We haven't decided on the exact release date & vehicle yet, but I think long-term you can expect that the best way to get it will be NuGet.
Coordinator
Feb 14, 2012 at 5:42 PM

You can still use HttpClient by itself though in Win8 Metro as it is part of .NET 4.5.

Daniel Roth

Feb 14, 2012 at 6:31 PM

Danial, please tell me you know of a simple example of using the HttpClient in 4.5 for CRUD.

Thanks.

Coordinator
Feb 14, 2012 at 7:19 PM

The HttpClient in 4.5 is virtually identical to what we are shipping with Web API:

var client = new HttpClient();

client.BaseAddress = new Uri(baseAddress);

Console.WriteLine(client.GetStringAsync("/api/hello").Result);

Daniel Roth

Feb 14, 2012 at 7:21 PM

Thanks Daniel,

>>The HttpClient in 4.5 is virtually identical to what we are shipping with Web API:

Do you mean the .6 version?

 

 

Coordinator
Feb 15, 2012 at 4:55 AM

The .6 version is a bit stale, but yes, the APIs are very close. The HttpClient that ships with ASP.NET Web API will be identical to the 4.5 version.

Daniel Roth

Feb 15, 2012 at 2:20 PM
Edited Feb 15, 2012 at 10:02 PM

Dan, I miss spoke, I meant the preview 6, which came out way after win8 dev preview came out.  So if you are saying that 4.5 that I have in VS11 is identical to preview 6, then I would think that preview 6 would have been out before the build conference so that is could have been incorporated into 4.5.  I must be confused, could you please help out my cripled mind?  There seem to be methods hanging off of the 6 preview httpclient that are not available to me in the hclient in vs11.

Thanks,

Terrence

 

edit: now I know why I said ".6 version".  On the wcf.codeplex site it says Preview Version 6, but in the Nuget package the latest is "Version: .6 "

Coordinator
Feb 17, 2012 at 4:19 PM

Right, the Preview 5 version of HttpClient is a bit stale. For example, HttpClient now only supports async methods so that you don’t accidentally block a thread (which could freeze your UI, use up valuable server resources, etc).

Daniel Roth