Updated [2/29/2012]: added more information on why HTTP and thus WebAPI is important.

I’ve been part of several conversations over the past few weeks where someone posited the question: Now that WebAPI is out, how do I (or my customers) decide when to use it or WCF? This question actually has many different flavors?

• Is WCF done? Does WebAPI replace WCF? Should I stop using WCF HTTP?
• Why is WebAPI part of ASP.NET? Wasn’t WebAPI originally a WCF framework?
• If WebAPI is part of ASP.NET, why don’t I just use MVC? What does WebAPI give me over MVC?

 

Is WCF done?

WCF is not done, nor is it going away anytime soon. WCF is the framework to use to build services that are flexible with regard to transport, encoding, and various protocols. This was precisely what WCF was designed for and what it does extremely well. WCF enables me to write service code and contracts which can then be exposed over various bindings (transport, security, etc.). That hasn’t changed and continues to be the case. If you are building a service in your organization and plan to support multiple protocols, or simply use protocols other than HTTP (tcp, name pipes, udp, etc.) then WCF continues to be your choice.

If you happen to want to expose your service over HTTP with WCF you have two high level choices: SOAP over HTTP or web HTTP. Obviously SOAP over HTTP is simply a different endpoint/binding choice, again where WCF shines. You can also expose your service using the WCF HTTP model that has been around since .NET 3.5. This model changes the dispatching to happen based on URI templates and HTTP verbs rather than SOAP actions. The WCF HTTP model also provides some help in providing help documentation, surfacing faults in an HTTP friendly way (think status codes) and returning content in web friendly formats such as JSON. 

But, and there had to be a but, WCF was built as a transport-neutral fashion, that’s a selling point; except when you do care about the transport and really want to leverage HTTP for example.

 

Why is WebAPI part of ASP.NET and not WCF?

Somewhere during development WCF WebAPI became ASP.NET WebAPI.[1] Knowledge that this occurred is often what leads to the previous questions about the fate or uses of WCF. In my opinion, and this is just that, WCF as the backbone of WebAPI was not the best option because in order to care about HTTP you had to work around a lot of WCF infrastructure. Things the core Message abstraction were not built to embrace any transport and didn’t easily support (note I said “easily”) the various content types that might be negotiated.

When talking with colleagues and looking at what people are doing to build web APIs the most common choice was overwhelmingly NOT WCF. In fact, the top choices were either an open source platform or using MVC controllers to return JSON results to client pages. The reason, as I see it, is that all these platforms made it easier to get a web API up and running while allowing you close control over HTTP when you care. For someone simply trying to return some objects to a client as JSON within their MVC web application it is really simple to add a method to the existing controller and return that data. No configuration, no bindings, nothing but their models and existing controllers.

HTTP is important

Getting close to HTTP allows you to take advantage of the protocol. This means I can fully leverage features of HTTP such as caching, etags, status codes and the like. Why is this important? There are a variety of reasons but I’ll focus on a few. Caching GET requests is a huge part of HTTP and of scaling any web site/service. One of SOAPs big failings is that it relies exclusively on HTTP POST when using HTTP as a transport and so cannot take advantage of caching of requests, even if those requests are returning slowly changing or unchanging data. Getting close to HTTP allows me to set expiration headers easily on the response and control the caching of my content on the client intermediaries, etc.

Being able to work easily with ETags enables me to leverage conditional gets and manage application concerns such as concurrency. Status codes allow me to be explicit when responding to clients about what happened with their request.  As an example, when someone posts a new resource to my service I want to respond with success (2xx status code) but I also want to provide the right code indicating that the resource was created (201) and provide the location header so the client knows the exact URL of the resource just created. Being close to HTTP gives me the ability to send the appropriate status code and the appropriate headers so the client can get a richer response, all with the existing HTTP protocol.

 

It makes sense, when you care about HTTP, to use MVC . . . but MVC is not the best tool for building services either.

 

What does WebAPI give me over MVC?

ASP.NET MVC provides some great tools that could be leveraged for services including model binding and routing. For most people building web APIs, however, there are other concerns as well. As a simple example, I’ve always felt a little uncomfortable building services in MVC because of the standard routing model that includes the action in the URI. A little thing, sure, and something I could work around with some MVC extensions of my own. Web API provides me a model for routing based on HTTP verb rather than a URI that contains an action. This puts me close to the HTTP protocol, simplifies my routing and seems right to me. In addition, Web API allows me to fully leverage content negotiation to enable returning various representations of my objects/resources. This means I have a pluggable model for allowing the client to tell me what representation they would like (text/xml, application/json, text/calendar) and choosing the best formatter to create the best match representation. All this comes with the ability to use the routing, dependency resolution, unit testing, and model binding.

In addition WebAPI allows you to self-host your services a la WCF (and in fact uses a little WCF under the covers to enable this) so you can, if you choose, go outside ASP.NET / IIS as the host of your service and continue to leverage all these great benefits. This enables you to host your HTTP services in any  .NET appdomain and still use the same routes, controllers, etc.

 

So . . . ?

WCF remains the framework for building services where you care about transport flexibility. WebAPI is the framework for building services where you care about HTTP.

 

What do YOU think?

 

[1] To be exact, after the 6th preview release of WCF WebApi

For BizTalk folks, the release today of the EAI and EDI capabilities built on the Azure Service Bus represents one of the first major steps toward integration in the cloud. You can check out the blog post on the Windows Azure blog detailing the features, but essentially you have routing, mapping with lookup capabilities and EDI support in the cloud (that’s minimizing what you get here, but a general summary). There is also an SDK to enable you to create the required artifacts on your development machine and deploy them up to the Azure environment.

I’m excited to see new capabilities released on Service Bus, which is, in my mind, a major differentiator in the PASS space. Nobody has anything that comes close to the type of stuff Microsoft is doing here and plans to do on the Service Bus in the future. This, coupled with the announcement around BizTalk Server 2010 R2 and its support for the cloud means that the BizTalk space continues to be interesting and ever expanding. As anyone who does integration work knows, it’s not going away anytime soon, and it’s great to see Microsoft investing in both on-premise and cloud solutions to help customers integrate their disparate systems.

I’m looking forward to seeing this project grow and add new features over time, and even more to seeing how customers take advantage of these capabilities in the cloud.

Well, as you might have noticed if you got redirected here, by blog has moved to this new location after being hosted over at Pluralsight for the past few years. This change happened rather quickly, so I’m in the process of moving all of the existing posts over into this new blog. Hopefully, your redirected requests will bring you directly to the post you are looking for, but if not, please search for them. 

I apologize for the inconvenience. I knew this change was coming at some point, which is why I had this blog setup, but the switch came rather unexpectedly and I’m scrambling to get the data migrated.

Thanks to all who attended my talks on LightSwitch and jQuery templates / data linking at last week’s Minnesota Developers Conference. I’ve received several requests for the demo code and slides which I have included here as links.

Of note for those looking at the jQuery demonstration code, I updated the movie review linking sample to show how to update the rendered template content with the new values from the input form. True to form, this was only a matter of a few lines of code. 

 

Demo code:

LightSwitch asset manager

jQuery templates and data-link

 

Slides:

LightSwitch

jQuery

I’ve been working with AppFabric lately and one of the things I like to do is use PowerShell to get a sense of the current state of my workflows. Unfortunately, I don’t like the format of the output as I find it hard to read.  You can see an example of the default output here.

What I want is a nice succinct table.  So, I fiddled around a bit with PowerShell’s format-table command and was able to get my data looking like this:

The command is pretty simple. I use the Property parameter to the format-table command to identify three properties that I want, using expressions to go after the specific values in which I’m interested.

get-asappserviceinstance -groupby status | format-table -property @{n='Count';e={$_.Count}}, @{n='Status';e={$_.Groups[0].GroupValue}}, @{n='Status';e={$_.Groups[1].GroupValue}}

The expressions go into the objects returned by AppFabrics get-asappserviceinstance command when grouping by status.

Hopefully this will prove useful to those of you working with Windows Server AppFabric and PowerShell.

Last week I had the pleasure of presenting two sessions at the Heartland Developer’s Conference (HDC). I love this show and meeting people from the central region, as well as catching up with colleagues. It’s always a great time and this year was no different.

For those who attended, you can find the samples I used at the links below. Thanks for coming, I hope you enjoyed the show as much as I did.

 

WF 4 from hello world to real world

Choosing service technology

From Damir Dobric (http://developers.de/blogs/damir_dobric):

 

Patch to fix an issue where autostart services start in the wrong application pool:

http://support.microsoft.com/kb/983484

This only applies to Windows 7 and Server 2008 R2 as IIS 7.5 is the only supported platform for autostart in a service. 

 

 

Patch to fix issues where the IIS Manager or PowerShell cmdlets fail due to schema issues in IIS configuration files. 

http://support.microsoft.com/kb/980423

 

There are a number of different error messages that result from this core issue.  In addition to this patch, you should already have installed the hotfix described in the following article:

http://support.microsoft.com/kb/970773

Then go take this survey and let Microsoft feel your pain!  Not sure anyone will get zapped by their chair when you send feedback, but the team is actively looking into how to make the interop story better, so be sure to get your voice heard.  Oh, and it’s a short survey so not a huge time commitment.

http://mymfe.microsoft.com/Feedback.aspx?formID=283

A former student approached me with a problem related to the Web programming model using WCF in .NET 3.5.  In short, he was using a custom IErrorHandler to create a custom fault message, but the client was always receiving a generic error.  Even more of a problem was that the custom error was an HTML formatted message, despite having set the response format on the service to JSON.  This caused big problems for the AJAX client trying to reason over that response.  I knew that WCF REST Starter Kit and WCF 4 both allowed for custom error messages, so I did some digging to see what might be at the root of the problem.  It turns out that the WebHttpBehavior inserts its own IErrorHandler and it was getting in the way of the custom handler he was adding.  After pointing this out to Dave, he quickly realized he could create a class that derived from the WebHttpBehavior and override the AddServerErrorHandlers to insert his own error handler.  He also created the requisite BehaviorExtensionElement so the new endpoint behavior could be added in the configuration file. 

 

public class JsonWebHttpBehavior : WebHttpBehavior
    {
        protected override void AddServerErrorHandlers(ServiceEndpoint endpoint,
        System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)
        {
            endpointDispatcher.DispatchRuntime.ChannelDispatcher.ErrorHandlers.Add(
               new JsonErrorHandler(endpointDispatcher.DispatchRuntime.ChannelDispatcher.IncludeExceptionDetailInFaults));
        }
    }

    public class JsonWebHttpElement : BehaviorExtensionElement
    {
        protected override object CreateBehavior()
        {
            return new JsonWebHttpBehavior();
        }

        public override Type BehaviorType
        {
            get { return typeof(JsonWebHttpBehavior); }
        }
    }

 

The job of the custom error handler is to create a custom fault class that provides data back to the calling application.  This solution nicely takes into consideration the IncludeExceptionDetailsInFaults property to correctly send the details only when configured to do so.  In this case, the status code is always set to 500 to trigger the correct error handling in the client library, but you could also modify this to send more specific HTTP status codes depending on the error message caught on the server. 

 

[DataContract]
    public class JsonFault
    {
        [DataMember]
        public string ExceptionType;

        [DataMember]
        public string Message;

        [DataMember]
        public string StackTrace;
    }

    public class JsonErrorHandler : IErrorHandler
    {
        public JsonErrorHandler(bool includeExceptionDetailInFaults)
        {
            this.includeExceptionDetailInFaults = includeExceptionDetailInFaults;
        }

        public bool HandleError(Exception error)
        {
            return false;
        }

        public void ProvideFault(Exception error,
            System.ServiceModel.Channels.MessageVersion version,
            ref System.ServiceModel.Channels.Message fault)
        {
            JsonFault jsonFault;
            if (includeExceptionDetailInFaults)
            {
                jsonFault = new JsonFault
                {
                    ExceptionType = error.GetType().FullName,
                    Message = error.Message,
                    StackTrace = error.StackTrace
                };
            }
            else
            {
                jsonFault = new JsonFault
                {
                    ExceptionType = typeof(System.Exception).FullName,
                    Message =
                        "An error occurred on the server. See server logs for details.",
                    StackTrace = null
                };
            }

            DataContractJsonSerializer serializer =
                new DataContractJsonSerializer(typeof(JsonFault));

            fault = Message.CreateMessage(version, null, jsonFault, serializer);
            fault.Properties.Add(WebBodyFormatMessageProperty.Name,
                new WebBodyFormatMessageProperty(WebContentFormat.Json));
            WebOperationContext.Current.OutgoingResponse.ContentType = "application/json";
            WebOperationContext.Current.OutgoingResponse.StatusCode =
                System.Net.HttpStatusCode.InternalServerError;
        }

        private bool includeExceptionDetailInFaults;
    }

 

 

You could certainly make modifications to only provide faults for certain types of exceptions (which is what .NET 4 does) log information in the HandleError method, etc.  Many thanks to Dave Grundgeiger for the inspiration to look into this and the final solution which he designed and allowed me to share here. 

In addition to now having WF 4 offered as a private on-site course, we have several upcoming public offerings of our Double Feature course which has been updated to .NET 4.  I’m excited to be teaching the course at the end of July in Boston and to cover the new features in WCF including configuration enhancements and REST improvements.  The bigger change, of course, is the entirely new WF 4 programming model.  In these open enrollment classes, we will be covering the new programming model, activity development and the runtime services such as persistence and tracking.  We’ll also cover the convergence of these two technologies in Workflow Service and the new message correlation capabilities introduced in .NET 4. 

So, if you are interested in an intense week of training in the Boston (July 26) or SoCal (Oct 11) area on these two great frameworks, register or save a seat before the classes fill up!