Combo RESTful WCF with Windows Service Hosting and Dynamic Response Format

The Goal
I have been working through the plausibility of multipurpose WCF services that are hosted in a windows hosting environment.  As part of my research, I wanted to prove that you could host a single service as a standard service to be consumed by a client proxy and scale it out from there to webHTTP and RESTful behavior.  The biggest goal I had was to make the service dynamically reply in the same format in which it was consumed without having a drawn out implementation to handle the messaging.

The Project
After some reading and messing around I have completed the following project which does exactly what I had hoped.  This single WCF implementation will allow for a straight service call, a RESTful call and respond dynamically with xml or json to the REST query based on the content type value of the request header.  All while being hosted in a windows service that can be dynamically deployed.  I came up with a very simple project that allows for interaction with a listing of albums.  The example is simple, but the devil of this was not in the actual data elements, so I flagged the scalability of that as irrelevant to the goal of illustrating the mechanism.

The Services
I created a basic WCF service to perform CRUD on my album repository. You will notice the service decorations on the interface indicating both an operation contract and a WebInvoke/WebGet behavior and template.

[ServiceContract(Name = "AlbumContract", 

     Namespace = "RESTCombo.Services", 

     SessionMode = SessionMode.Allowed)]

public interface IAlbumSvc:IMetadataExchange

{

    [OperationContract]

    [WebGet(UriTemplate = "/Albums/{id}"), 

        Description("Returns the album with the passed ID")]

    Album GetAlbum(String id);

    [OperationContract]

    [WebGet(UriTemplate = "/Albums"), 

        Description("Returns the entire list of albums")]

    List<Album> GetAlbums();

    [OperationContract]

    [WebInvoke(Method = "POST", UriTemplate = "/Albums"), 

         Description("Adds a new album to list of albums")]

    void AddAlbum(Album album);

    [OperationContract]

    [WebInvoke(Method = "PUT", UriTemplate = "/Albums"), 

         Description("Updates an existing album")]

    void UpdateAlbum(Album album);

    [OperationContract]

    [WebInvoke(Method = "DELETE", UriTemplate = "/Albums/{id}"), 

         Description("Removes an album from list of albums")]

    void DeleteAlbum(String id);

}

The WebGet and WebInoke decoration allows the services to respond as a RESTful WCF service based on the URI template.  The service implementation should be decorated as follows:

[ServiceBehavior(Name = "RESTCombo.Services.AlbumSvc", 

    ConcurrencyMode = ConcurrencyMode.Single, 

    InstanceContextMode = InstanceContextMode.Single,

    IncludeExceptionDetailInFaults = true)]    

[AspNetCompatibilityRequirements(

    RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]

public class AlbumSvc : IAlbumSvc

I'm going to skip posting the implementation of the services themselves as they are actually irrelevant to the discussion.  The entire project is attached at the end of the post if you would like to review the code.

The Configuration
While most of the configuration is fairly straight-forward, there are a couple of items worth pointing out.  Notice the multiple bindings for the single service.  Each must respond on its own port.  You can have as many bindings as needed up to one per protocol.  The webHttp endpoint behavior is vital to this mechanism.  helpEnabled allows users to use the '/help' switch at the end of a query to get a service overview page as shown here.

defaultOutgoingResponseFormat is our selection for the default response to a webHttp request. automaticFormatSelectionEnabled allows the response to dynamically detect the request format and respond in kind.

<?xml version="1.0"?>

<configuration>

  <startup>

    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>

  </startup>

  <system.serviceModel>

    <services>

      <service name="RESTCombo.Services.AlbumSvc">

        <host>

          <baseAddresses>

            <add baseAddress="http://localhost:8080/AlbumSvc/" />

            <add baseAddress="net.tcp://localhost:2122" />

          </baseAddresses>

        </host>

        <endpoint  binding="webHttpBinding" contract="RESTCombo.Services.IAlbumSvc"

                  bindingConfiguration="RESTBindingConfiguration" 

                   behaviorConfiguration="RESTEndpointBehavior"/>      

        <endpoint address="net.tcp://localhost:2122/AlbumSvc/" binding="netTcpBinding"

                  contract="RESTCombo.Services.IAlbumSvc"/>

      </service>

    </services>    

    <bindings>

     <webHttpBinding>

        <binding name="RESTBindingConfiguration">

          <security mode="None" />          

        </binding>

      </webHttpBinding>      

      <netTcpBinding>

        <binding name="DefaultBinding">

          <security mode="None"/>

        </binding>        

      </netTcpBinding>

    </bindings>

    <behaviors>      

      <endpointBehaviors>

        <behavior name="RESTEndpointBehavior">           

          <webHttp helpEnabled="true" defaultOutgoingResponseFormat="Xml"

                   automaticFormatSelectionEnabled="true"/>

        </behavior>

      </endpointBehaviors>

      <serviceBehaviors>                        

        <behavior name="DefaultBehavior">

          <serviceMetadata httpGetEnabled="true" />

          <serviceDebug includeExceptionDetailInFaults="false"/>

        </behavior>       

      </serviceBehaviors>

    </behaviors>  

    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" 

                               aspNetCompatibilityEnabled="true" />

  </system.serviceModel>

</configuration>

The Testing
We will just fast-forward through the hosting setup and service implementation.  Now that services are configured, built and running, we can perform the response testing and see how it all comes together.  When browsing to the webHttp base address and invoking the services via RESTful queries, I receive the following responses for the list and single respectively.

Then, to prove the JSON / XML switch, I used a fiddler software to create and review requests and responses.  First, I constructed an XML request and trapped the response.

Then, I constructed a JSON request and trapped the response.

As you can see, the service is responding to me in the request format.  For the client proxy implementation, review the source code attached at the end of the post.  The big victory here is the open and scalable approach to an SOA.  By doing dynamic communication in this manner, we are enabling a service to be consumed in the way that an integrator can best leverage.  This allows us to have a single implementation of intelligence and functionality while allowing any integrating software to choose the manner in which it interacts.  This is very powerful and very scalable and should allow your services to be consumer agnostic and focus strictly on intelligence.  For further review, download the entire project here.