RESTful WCF Part 2 of n

A while back (can’t remember exactly when) I started saying I was going to write a bit about RESTFul WCF, you can see my 1st post at http://sachabarber.net/?p=460. In that post I mentioned that I would probably do the following:

The schedule of posts is probably going to be something like this

1. The new RESTful WCF attributes
2. Serialization options (this article)
3. Hosting
4. CRUD operations using RESTful WCF

Well this is basically part2. Your options for serialization when working with RESTful WCF

In this blog entry we will be covered the following serialization options.

Message

• DataContract
• XML
• Hybrid
• JSON

This blog entry says nothing about how to deal with the resources once they are made available from the RESTful WCF service, is is assumed that the reader will know what to do with the exposed resources.

Here is a hint, have a look at XLINQ or any of the numerous XML APIs.

Helper Methods

Before we start I would just like to point out that the attached service looks like this

   1:  using System;
   2:  using System.Collections.Generic;
   3:  using System.Linq;
   4:  using System.Runtime.Serialization;
   5:  using System.ServiceModel;
   6:  using System.ServiceModel.Channels;
   7:  using System.Text;
   8:  using System.ServiceModel.Web;
   9:  
  10:  namespace DataService
  11:  {
  12:      [ServiceContract(SessionMode = 
  13:          SessionMode.NotAllowed)]
  14:      public interface ISomeService
  15:      {
  16:  
  17:          /// <summary>
  18:          /// The OperationContracts below show how to use different 
  19:          /// Serialization techniques such as 
  20:          /// <list type="Bullet">
  21:          /// <item>Message (the most customizable/flexability)</item>
  22:          /// <item>DataContract</item>
  23:          /// <item>XML</item>
  24:          /// <item>Hybrid approach</item>
  25:          /// </list>
  26:          /// </summary>
  27:  
  28:          [OperationContract]
  29:          [WebGet(UriTemplate = "/")]
  30:          Message GetRoot();
  31:  
  32:          [OperationContract]
  33:          [WebGet(UriTemplate = "/DC/{firstName}/{lastName}")]
  34:          Person GetRootPersonUsingDataContract(String firstName, 
  35:              String lastName);
  36:  
  37:          [OperationContract]
  38:          [WebGet(UriTemplate = "/DC/PeopleList")]
  39:          PersonList GetRootPersonListUsingDataContract();
  40:  
  41:          [OperationContract]
  42:          [XmlSerializerFormat()]
  43:          [WebGet(UriTemplate = "/XMLSer/{animalBreed}")]
  44:          Animal GetRootAnimalUsingXmlSerialization(String animalBreed);
  45:  
  46:          [OperationContract]
  47:          [XmlSerializerFormat()]
  48:          [WebGet(UriTemplate = "/XMLSer/AnimalList")]
  49:          AnimalList GetRootAnimalListUsingXmlSerialization();
  50:  
  51:  
  52:          [OperationContract]
  53:          [WebGet(UriTemplate = "/HYBRID/{firstName}/{lastName}")]
  54:          Message GetRootPersonUsingHybridStylee(String firstName,
  55:              String lastName);
  56:  
  57:          [OperationContract]
  58:          [WebGet(UriTemplate = "/HYBRID/PeopleList")]
  59:          Message GetRootPersonListUsingHybridStylee();
  60:  
  61:  
  62:          /// <summary>
  63:          /// The OperationContracts below show how to use different 
  64:          /// ResponseFormats such as XML/JSON
  65:          /// </summary>
  66:  
  67:          [OperationContract]
  68:          [WebGet(UriTemplate = "/DC/XML/{firstName}/{lastName}", 
  69:              ResponseFormat=WebMessageFormat.Xml)]
  70:          Person GetRootPersonUsingDataContractXML(String firstName, 
  71:              String lastName);
  72:  
  73:          [OperationContract]
  74:          [WebGet(UriTemplate = "/DC/XML/PeopleList", 
  75:              ResponseFormat = WebMessageFormat.Xml)]
  76:          PersonList GetRootPersonListUsingDataContractXML();
  77:  
  78:  
  79:  
  80:          [OperationContract]
  81:          [WebGet(UriTemplate = "/DC/JSON/PeopleList",
  82:              ResponseFormat = WebMessageFormat.Json)]
  83:          PersonList GetRootPersonListUsingDataContractJSON();
  84:   
  85:      }
  86:  }

That the service implementation makes use of several helper methods that look like this

   1:  private Person GetPerson(
   2:      String firstName, String lastName)
   3:  {
   4:      return new Person { FirstName = firstName, LastName = lastName };
   5:  }
   6:  
   7:  private PersonList PersonList()
   8:  {
   9:      return new PersonList {
  10:          new Person { FirstName = "firstName1", LastName = "lastName1" },
  11:          new Person { FirstName = "firstName2", LastName = "lastName2" },
  12:          new Person { FirstName = "firstName3", LastName = "lastName3" },
  13:          new Person { FirstName = "firstName4", LastName = "lastName4" }
  14:      };
  15:  }

Message

Message is the most flexable of all the different Serialization techniques offered my WCF, as its the closest to the actual Channel that is used to transmit the Message, and it also offers the most freedom to customise the serialization process. As a side effect it also requires the most work.

For example when we have a service method like this

   1:  [OperationContract]
   2:  [WebGet(UriTemplate = "/")]
  3:  Message GetRoot();

And the actual service implementation looks like this.

   1:  //Matches [WebGet(UriTemplate = "/")]
   2:  public Message GetRoot()
   3:  {
   4:  
   5:      var stream = new MemoryStream();
   6:      XmlDictionaryWriter writer =
   7:          XmlDictionaryWriter.CreateTextWriter(stream);
   8:      writer.WriteStartDocument();
   9:      writer.WriteStartElement("Root");
  10:      writer.WriteStartElement("Hello");
  11:      writer.WriteElementString("Name", "sacha");
  12:      writer.WriteEndElement();
  13:      writer.WriteEndElement();
  14:      writer.WriteEndDocument();
  15:      writer.Flush();
  16:      stream.Position = 0;
  17:  
  18:      XmlDictionaryReader reader =
  19:          XmlDictionaryReader.CreateTextReader(
  20:          stream, XmlDictionaryReaderQuotas.Max);
  21:      return Message.CreateMessage(
  22:          MessageVersion.None, "", reader);
  23:  }

We would get the following

Which is cool, but this is a lot of work to get these resources, which we could get in other ways. Lets consider some of the other options.

DataContract

Is by far the easiest approach as we simply rely on the existing WCF DataContractSerializer, which does all the heavy work for us. The issue with this approach is that the XML we end up with may not always be what we are after, and we don’t have that much control over it. So if this is an issue, you could always go for Message type Serialization or one of the other options here.

In order to demonstrate DataContract Serialization we start with an actual DataContract class/DataContract collection, which for the attached demo code look like this

   1:  [DataContract()]
   2:  public class Person
   3:  {
   4:      [DataMember]
   5:      public String FirstName;
   6:  
   7:      [DataMember]
   8:      public String LastName;
   9:  
  10:  }
  11:  
  12:  
  13:  [CollectionDataContract(Name = "People", Namespace = "")]
  14:  public class PersonList : List<Person>
  15:  {
  16:  }

So we can then have some service methods that are defined like this.

   1:  [OperationContract]
   2:  [WebGet(UriTemplate = "/DC/{firstName}/{lastName}")]
   3:  Person GetRootPersonUsingDataContract(String firstName, 
   4:      String lastName);
   5:  
   6:  [OperationContract]
   7:  [WebGet(UriTemplate = "/DC/PeopleList")]
   8:  PersonList GetRootPersonListUsingDataContract();

And the actual service implementation looks like this.

   1:  //Matches [WebGet(UriTemplate = "/DC/{firstName}/{lastName}")]
   2:  public Person GetRootPersonUsingDataContract(
   3:      String firstName, String lastName)
   4:  {
   5:      return GetPerson(firstName, lastName);
   6:  }
   7:  
   8:  
   9:  //Matches [WebGet(UriTemplate = "/DC/PeopleList")]
  10:  public PersonList GetRootPersonListUsingDataContract()
  11:  {
  12:      return PersonList();
  13:  }

Here is an example of this running through the browser.

XML

XML Serialization has been around a while and to make use of it we need to adorn our classes with special attributes to aid the serialization process. In the example code we use the following class.

   1:  [XmlRoot(Namespace = "", ElementName = "Animal")]
   2:  public class Animal
   3:  {
   4:      [XmlAttribute(AttributeName="breed")]
   5:      public String Breed;
   6:  }
   7:  
   8:  
   9:  [XmlRoot(Namespace = "", ElementName="Animals")]
  10:  public class AnimalList : List<Animal>
  11:  {
  12:  }

So we can then have some service methods that are defined like this.

   1:  [OperationContract]
   2:  [XmlSerializerFormat()]
   3:  [WebGet(UriTemplate = "/XMLSer/{animalBreed}")]
   4:  Animal GetRootAnimalUsingXmlSerialization(String animalBreed);
   5:  
   6:  [OperationContract]
   7:  [XmlSerializerFormat()]
   8:  [WebGet(UriTemplate = "/XMLSer/AnimalList")]
   9:  AnimalList GetRootAnimalListUsingXmlSerialization();

And the actual service implementation looks like this.

   1:  //Matches[WebGet(UriTemplate = "/XMLSer/{animalBreed}")]
   2:  public Animal GetRootAnimalUsingXmlSerialization(String animalBreed)
   3:  {
   4:      return new Animal { Breed = animalBreed};
   5:  }
   6:  
   7:  
   8:  //Matches[WebGet(UriTemplate = "/XMLSer/AnimalList")]
   9:  public AnimalList GetRootAnimalListUsingXmlSerialization()
  10:  {
  11:      return new AnimalList {
  12:          new Animal { Breed = "breed1"},
  13:          new Animal { Breed = "breed2"},
  14:          new Animal { Breed = "breed3"},
  15:          new Animal { Breed = "breed4"}
  16:      };
  17:  }

Here is an example of this running through the browser.

Hybrid Approach

If you want to work with strongly typed object but also want to use Messages where you have more control over the serialization process you can go for a hybrid approach which works something like this. We could have some service methods that are defined like this.

   1:  [OperationContract]
   2:  [WebGet(UriTemplate = "/HYBRID/{firstName}/{lastName}")]
   3:  Message GetRootPersonUsingHybridStylee(String firstName,
   4:      String lastName);
   5:  
   6:  [OperationContract]
   7:  [WebGet(UriTemplate = "/HYBRID/PeopleList")]
   8:  Message GetRootPersonListUsingHybridStylee();

And the actual service implementation looks like this.

   1:  //Matches [WebGet(UriTemplate = "/HYBRID/{firstName}/{lastName}")]
   2:  public Message GetRootPersonUsingHybridStylee(String firstName,
   3:      String lastName)
   4:  {
   5:      Person p = GetPerson(firstName, lastName);
   6:      return Message.CreateMessage(MessageVersion.None, "*", p);
   7:  }
   8:  
   9:  
  10:  //Matches [WebGet(UriTemplate = "/HYBRID/PeopleList")]
  11:  public Message GetRootPersonListUsingHybridStylee()
  12:  {
  13:      PersonList pl = PersonList();
  14:      return Message.CreateMessage(MessageVersion.None, "*", pl);
  15:  }

Using the same helper methods as before.

This approach allows us to use strongly typed DataContract objects but use Messages, which allow us to have more control over the serialization process, as it is in the developer control rather than the actual DataContractSerializers.

Here is an example of this running through the browser.

JSON

Some of you out there may actually be used to web development and are well used to (and even into, just for the record I am not a web guy) working with Javascript/manual Ajax calls. As I say I am most certainly not a web chap, but for completeness let’s look at how we might serialize some RESTful resource results to JSON.

As before most of the heavy lifting is done by way of the some WCF attributes.

Lets firstly look at the service interface method which looks like this, it can be seen that we simply use the WebMessageFormat.Json enum to specify that we want the resources serialized as JSON

   1:  [OperationContract]
   2:  [WebGet(UriTemplate = "/DC/JSON/PeopleList",
   3:      ResponseFormat = WebMessageFormat.Json)]
   4:  PersonList GetRootPersonListUsingDataContractJSON();

And then for the actual service implementation we have this

   1:  //Matches [WebGet(UriTemplate = "/DC/JSON/PeopleList", 
   2:  //          ResponseFormat = WebMessageFormat.Json)]
   3:  public PersonList GetRootPersonListUsingDataContractJSON()
   4:  {
   5:      return PersonList();
   6:  }

Using the same helper methods as before.

And to ensure this works we could use a small sample HTML page (included with the demo code), which I have only tested and got working with IE7. It should work with FF but I didn’t spend too much time on it, as that is not the point I am trying to make, I am merely showing you how the RESTful JSON stuff works.

   1:  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
   2:  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   3:  <html>
   4:  <head>
   5:  <title>JSON Test</title>
   6:  <script type="text/javascript">
   7:  
   8:  function getXmlHttp()
   9:  {
  10:      var xmlHttp;
  11:      try {
  12:          xmlHttp = new XMLHttpRequest();
  13:      }
  14:      catch(e) {
  15:          try {
  16:              xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
  17:          }
  18:          catch (e) {
  19:              try {
  20:                  xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
  21:              }
  22:              catch (e) {
  23:                  alert("the sample only works in browsers with Ajax support");
  24:                  return false;
  25:              }
  26:          }
  27:      }
  28:  
  29:      return xmlHttp;
  30:  }
  31:  
  32:  
  33:  var serviceURI = "http://localhost:8085/SomeService/DC/JSON/PeopleList";
  34:  
  35:  function getStuff()
  36:  {
  37:  
  38:      var xmlHttp=getXmlHttp();
  39:      xmlHttp.onreadystatechange = function() {
  40:          if (xmlHttp.readyState == 4) {
  41:              alert("xmlHttp.readyState");
  42:              var result = (eval(xmlHttp.responseText));
  43:              var person = null;
  44:              alert(result);
  45:              for (var i = 0; i < result.length; i++) {
  46:                  person = result[i];
  47:                  alert("Person found, Firstaname : " + 
  48:                  person.FirstName + " LastName : " + person.LastName);
  49:              }
  50:          }
  51:  
  52:      }
  53:      xmlHttp.open("GET", serviceURI, true);
  54:      xmlHttp.setRequestHeader("Accept","application/json");
  55:      xmlHttp.send(null);
  56:      
  57:  }
  58:  
  59:  </script>
  60:  
  61:  </head>
  62:  
  63:  <body >
  64:  <form name="form1" action="javascript:getStuff()">
  65:  <input type="submit" value="Enter"> </form>
  66:  </body>
  67:  </html>

And here is a demo of it running (again against the simple WCF service console host app, that is included with the attached demo code)

As I say I am NOT a web man, but again for completeness I WILL be showing you how to host RESTFul WCF services inside ASP .NET/IIS and how to work with a ASP .NET AJAX ScriptManager object in the subsequent post. Which to my mind if I was into the web, would be how you would want to go about things, as you would then get away with not having to write all this crappy javascript AJAX code. Ouch. That simply can not be cool. I know ASP .NET AJAX is heavy but come on, that xmlHttp.onreadystatechange YUUUUUCKKKK