WCF REST Services: Setting the response format based on request’s expected type

October 31st, 2008

I just attended the Microsoft PDC in LA.  One of the many excellent sessions was a pre-conference on WCF, part of which was presented by Ron Jacobs. Ron did a fantastic job of explaining WCF REST Services and the WCF REST Starter Kit.

One of the examples he showed from the WCF REST Starter kit was an example where the response type (JSON or XML) is dynamically set based on the HTTP request’s requested content type in the "Accepts" HTTP Header.

That example works by switching between two different operation implementations (methods).

I liked the idea of using the requested content type to automatically return JSON or XML depending on the requested content type, but I wasn’t so keen on having to implement two methods.

I thought I’d try to get a similar thing working but using a single operation implementation which is called no matter whether or JSON or XML are requested.

The DynamicResponseType attribute

This is how it works.  You decorate your method with an additional DynamicResponseType attribute which I have defined:

   1: [ServiceContract]
   2: [ServiceBehavior(IncludeExceptionDetailInFaults = true, InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)]
   3: [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
   4: public class Service1
   5: {
   6:     [OperationContract]
   7:     [WebGet(UriTemplate = "GetData?param1={i}&param2={s}")]
   8:     [DynamicResponseType]
   9:     public SampleResponseBody GetData(int i, string s)
  10:     {
  11:         return new SampleResponseBody() { 
  12:             Name = "Test",
  13:             Value = s, 
  14:             Time = DateTime.Now.ToShortTimeString() 
  15:         };
  16:     }
  17: }
  18:  
  19: public class SampleResponseBody
  20: {
  21:     public string Name { get; set; }
  22:     public string Value { get; set; }
  23:     public int IntValue { get; set; }
  24:     public string Time { get; set; }
  25: }

An example client

Then when the client requests a specific type (XML or JSON), it is served automatically.

Below I have a pure HTML/Javascript client with two buttons, each of which call the same  GetWebRequest function when they are clicked but passing a different requested content type as a parameter.  The GetWebRequest function issues an HTTP request to the WCF operation I showed above.

The first button says it wants JSON, and the second XML.  This is done by setting the "Accept" request header:

   1: <body>
   2:     <form id="form1" runat="server">
   3:     <div>
   4:     
   5:     <input type="button" value="Click to request JSON" 
   6:         onclick="GetWebRequest('application/json');" />
   7:     
   8:     <input type="button" value="Click to request XML" 
   9:         onclick="GetWebRequest('application/xml');" />
  10:     
  11:     </div>
  12:     <asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>
  13:     </form>
  14:  
  15: <script type="text/javascript">

   1:  


   2:   function GetWebRequest(acceptType) {  


   3:     var wRequest = new Sys.Net.WebRequest();


   4:     wRequest.get_headers()["Accept"] = acceptType;


   5:     var url = "/Service1.svc/GetData?param1=12&param2=";


   6:     wRequest.set_url(url + new Date());


   7:     wRequest.set_httpVerb("GET");


   8:     wRequest.add_completed(OnWebRequestCompleted);


   9:     wRequest.invoke();


  10:   }


  11:  


  12:   function OnWebRequestCompleted(executor, eventArgs) {


  13:     alert(executor.get_responseData());


  14:   }


</script>
  16: </body>

This is the form that gets displayed initially:

image

When you click on the first button we request JSON from the WCF Service operation:

image

When you click on the second button we request XML from the same WCF Service operation:

image

How it works.

I’ve created my own  WCF ServiceHostFactory which I wire up in the SVC file:

   1: <%@ ServiceHost Language="C#" 
   2:     Debug="true" 
   3:     Service="WcfService2.Service1" 
   4:     CodeBehind="Service1.svc.cs" 
   5:     Factory="DamianBlog.ServiceHostFactory2Ex" %>

In my ServiceHostFactory2Ex class I ensure that my own WebServiceHost class gets created.

Then in my own WebServiceHost I ensure that my own WebHttpBehavior replaces the standard one.

Next in my own WebHttpBehavior I override the GetReplyDispatchFormatter method and return my own IDispatchMessageFormatter.

In my own IDispatchMessageFormatter I implement the SerializeReply method and then use a JSON formatter or XML formatter depending on the "Accepts" HTTP request header which I pick up from the OperationContext.Current.RequestContext.RequestMessage.

The full source is available for download here http://damianblog.com/WCFDynamicResponseDemo.zip.

Rob Jacobs blogs at http://blogs.msdn.com/rjacobs/

Posted by dmehers Filed in WCF

8 Responses to “WCF REST Services: Setting the response format based on request’s expected type”

  1. Ron Jacobs Says:
    October 31st, 2008 at 3:08 pm

    Nice work! I’ve heard this request from many people. We are working on some ideas to make it easier for people to get this done in the future.

  2. Scott Wojan Says:
    November 2nd, 2008 at 3:38 am

    Nice work around for the flawed implementation by Microsoft, however I don’t think “Service1.svc/GetData?param1=12&param2=” is a particularly restful URI

  3. WCF and REST, An approach to using the Content-Type and Accept HTTP Headers for Object Serialization - Daptivate > by Kyle Beyer Says:
    November 17th, 2008 at 6:49 am

    [...] this past week I saw that Damian Mehers blogged another approach with sample code.  I really liked how the approach Damian used required nothing more than a method Attribute to [...]

  4. Kyle Beyer Says:
    November 17th, 2008 at 7:02 am

    Hey Damian - Awesome work on this! I really like how you boiled it down to a single method attribute.

    One thing I noticed while starting to use it in conjunction with the WCF REST starter kit is that there also needs to be support for dynamic *request* serialization. So, I’ve extended your code a bit and merged it into the starter kit code to enable this.

    You can download source here: http://daptivate.com/archive/2008/11/16/wcf-and-rest-an-approach-to-using-the-content-type-and-accept-http-headers-for-object-serialization.aspx

    Interested to hear your thoughts and suggestions.

  5. dmehers Says:
    November 18th, 2008 at 5:00 pm

    Hi Kyle,

    Sounds like a great addition — I tried to get it working but hit a problem because they hadn’t made one of their methods virtual — don’t remember which one.

    Cheers,
    Damian

  6. Mot Says:
    March 19th, 2009 at 5:58 pm

    Damian, thank you very much for this solution!

    Is it possible to use your workaround when having more than one endpoint specified?

    I’m wanting to provide a soap interface and a rest (which offers the flexibility your providing with the .dll) interface.

    Thanks in advance,
    Mot

  7. dmehers Says:
    March 24th, 2009 at 10:44 pm

    Hi Mot,

    This is really specific to REST, using the REST starter kit … if you find a way of making it work with a SOAP interface then I’d be very interested in hearing about it though.

    /Damian

  8. mob Says:
    June 20th, 2009 at 5:21 am

    Check out WCF REST Contrib, it handles this for you:

    http://wcfrestcontrib.codeplex.com/

    It comes with a POX and form url encoded formatter and allows you to easily define your own custom formatters.

    m

Leave a Reply