A while ago (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:
- The new RESTful WCF attributes
- Serialization options (this article)
- Hosting
- CRUD operations using RESTful WCF
Well, this is basically part 2. Your options for serialization when working with RESTful WCF are given here.
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, it 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: 18: 19: 20: 21: 22: 23: 24: 25: 26: 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: 63: 64: 65: 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 flexible of all the different Serialization techniques offered my WCF, as it's 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:
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. Let's consider some of the other options.
DataContract
This 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 looks 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:
2: public Person GetRootPersonUsingDataContract(
3: String firstName, String lastName)
4: {
5: return GetPerson(firstName, lastName);
6: }
7:
8:
9:
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:
2: public Animal GetRootAnimalUsingXmlSerialization(String animalBreed)
3: {
4: return new Animal { Breed = animalBreed};
5: }
6:
7:
8:
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:
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:
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.
Let's 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:
2:
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 Internet Explorer 7. 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