Beyond HTML: Returning JSON and XML Data From Your MVC Endpoints
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
If your web application is like many others built today, you are busy looking at how to add JSON and XML-based REST services to that application. Many of your fellow web developers are adopting ASP.NET MVC because it offers the ability to create readable URL structures for your applications. Wouldn’t it be great if, after creating the primary MVC application, you could reuse those pages to create the REST services too? After all, you are already building applications with beautiful user interfaces (UIs) that people understand how to access. You are already spending the time to create clean URL structures.
Certainly, that was true for me. I took a moment and thought, “What would I need to do to make the JSON and XML services flow from my UI efforts?”
In this article, I assume you are already familiar with MVC. I explain the differences in how computers ask for resources for presentation to people and for presentation to other code. I then explore how to use this difference to generate different resource representations, and what to do to recognize the data format the client specifies in a GET request. First, we look at what a resource actually is. We then look at Multipurpose Internet Mail Extension (MIME) types. To deliver a more complete picture of how this fits into a RESTful service, the example code shows how to implement full REST management of the data managed by the endpoint.
Getting Resources in Context
A resource is a thing: a purchase order, a book review, the list of your friends’ activities. Every resource accessible by URL has at least one representation. For example, you may have a Person resource represented by the following C# class:
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public IEnumerable<Person> FamilyMembers { get; set; }
}
To store Person objects, you might host the resource at a URL like http://http://www.scottseely.com/people/{Id}, where {Id} represents the ID of a given Person resource. When a web browser requests the resource, the browser uses the following HTML representation to display the Person to the user:
<html xmlns="http://http://www.w3.org/1999/xhtml" >
<body>
<div>
<h3>Scott</h3>
<h3>Seely</h3>
<h3>Family Members:</h3>
<p>Jean Seely</p>
<p>Vince Seely</p>
<p>Angie Seely</p>
<p>Phil Seely</p>
</div>
</body>
</html>
Why did the service return HTML and how did the browser know that the representation is HTML? HTTP allows clients to request specific representations of a resource and for HTTP messages to indicate the type of data within the message through MIME types. There are MIME types for HTML (text/htmlor application/xhtml+xml), XML (text/xml or application/xml), JSON (application/json), and others. You can see a complete list of all MIME media types at http://www.iana.org/assignments/media-types/index.html. To communicate the type of resource within a message, the HTTP message includes a header named Content-Type. For example, Google’s home page indicates the content type as:
Content-Type text/html; charset=UTF-8
To request the resource using a specific format, the caller uses the HTTP Accept header, listing the MIME types in order of preference. When requesting Google’s home page as HTML, Firefox sends the following Accept string:
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
This indicates that the browser wants the resource from http://www.google.com as a plain HTML page or as an XHTML page or as whatever the server wants to send (*/*). The q parameter indicates the preference of the MIME type on a scale of 0 to 1. When not expressed, q is set to 1.0.
Using MVC to Represent Resources
When you develop an MVC page using the standard mechanisms, you pass data between the model, view, and controller using a collection named ViewData. ViewData represents the essential information contained in the page. It is the resource being asked for. Each method that handles an inbound request populates ViewData and returns an appropriate ActionResult. If the ActionResult is a ViewResult instance, as it is when you return View() from a Controller method, the ViewData is passed to the result to be consumed and displayed. For example, when going to the home page of the MVC application, I might populate the ViewData, and hence the resource represented by the URL, with the following code:
public ActionResult Index()
{
ViewData["Message"] = "Welcome to ASP.NET MVC!";
ViewData["Person"] =
new Person
{
FirstName = "Scott",
LastName = "Seely",
};
return View();
}
This indicates that the resource has two values, Message and Person. Message contains the value, “Welcome to ASP.NET MVC!” Person has a value which is an object. When rendered as HTML, the two values appear with some chrome to beautify the page or to ease navigation within the site. If the content represented for consumption by some other code, we would want something other than HTML. For example, a client asking for XML should receive this:
<data>
<Message>
<string
xmlns="http://schemas.microsoft.com/2003/10/Serialization/">
Welcome to ASP.NET MVC!
</string>
</Message>
<Person>
<Person xmlns:i="http://http://www.w3.org/2001/XMLSchema-instance">
<FirstName>Scott</FirstName>
<LastName>Seely</LastName>
</Person>
</Person>
</data>
Likewise, a request for JSON should show:
{ "Message":"Welcome to ASP.NET MVC!",
"Person":{
"FirstName":"Scott",
"LastName":"Seely"
}
}
To decide which format to show, the ActionResult returned from the Controller should look at the HTTP Accept header in the request message and format the ViewData appropriately. Instead of worrying about this for each individual message, we can create a new Controller that knows when to return HTML, XML, or JSON. Let’s call this new type AcceptTypeController. To handle its job, AcceptTypeController looks at all the Accept MIME types the client accepts and generates the right ViewResult by overriding View(string viewName, string masterName, object model). If the caller asked for JSON or XML, we return a new type, AcceptTypeResult. For HTML, we delegate to the parent class. The Controller gets access to the request Accept header through Request.AcceptTypes. The AcceptTypes array is the MIME strings listed in preferred order, so we loop through this list until we hit a MIME type we understand and return the right ViewResult instance.
protected override ViewResult View(
string viewName, string masterName, object model)
{
ViewResult retval = null;
// Get the accept type. If it is HTML,
// let the base class handle the response.
// Otherwise, use our custom ViewResult type.
foreach (var acceptType in Request.AcceptTypes)
{
// Accept type is expressed in order of preference.
// Make sure to allow for all known types
if (string.Equals("application/json", acceptType,
StringComparison.OrdinalIgnoreCase))
{
retval = new AcceptTypeViewResult(new
JsonDataWriter(Response.OutputStream))
{ ViewData = ViewData };
break;
}
if (string.Equals("application/xml", acceptType,
StringComparison.OrdinalIgnoreCase) ||
string.Equals("text/xml", acceptType,
StringComparison.OrdinalIgnoreCase))
{
retval = new AcceptTypeViewResult(new
XmlDataWriter(Response.OutputStream))
{ ViewData = ViewData };
break;
}
if (string.Equals("text/html", acceptType,
StringComparison.OrdinalIgnoreCase) ||
string.Equals("application/xhtml+xml", acceptType,
StringComparison.OrdinalIgnoreCase))
{
retval = base.View(viewName, masterName, model);
break;
}
}
// If we have nothing that matches, send back HTML.
return retval ?? base.View(viewName, masterName, model);
}
By this point, the code has already decided how to handle dispatching based on the Accept header. The AcceptTypeViewResult is extremely compact. When called upon to write out the result, it delegates that responsibility to its internal DataWriter. DataWriter is yet another new type. It knows how to write out an IDictionary<string, object> using a particular MIME type.
public class AcceptTypeViewResult : ViewResult
{
public AcceptTypeViewResult(DataWriter writer)
{
Writer = writer;
}
private DataWriter Writer { get; set; }
public override void ExecuteResult(ControllerContext context)
{
Writer.WriteDictionary(ViewData);
context.HttpContext.Response.ContentType = Writer.ContentType;
}
}
When writing out a dictionary, the DataWriter has three concerns:
- What object serializer do I use?
- How do I write out the dictionary tags as enclosing entities for each serialized object?
- What is the MIME type the DataWriter emits?
To handle this, a DataWriter derived type implements the following functions:
- public abstract XmlObjectSerializer CreateSerializer(Type type);
- public abstract void WriteStartElement(string name);
- public abstract void WriteEndElement(string name);
- public abstract string ContentType { get; }
We use XmlObjectSerializer to take advantage of the serialization work done for objects in the System.Runtime.Serialization and System.ServiceModel.Web assemblies. The assemblies contain types that do a great job reading and writing XML (DataContractSerializer) and JSON (DataContractJsonSerializer). DataWriter.WriteDictionary uses these abstractions to get the MIME type written to the HTTP response.
public void WriteDictionary(IDictionary<string, object> dictionary)
{
var needSeparator = false;
// Start the document
WriteStartDocument();
foreach (var key in dictionary.Keys)
{
// If this is not the first entry, emit a separator if the
// format calls for it.
if (needSeparator)
{
WriteSeparator();
}
needSeparator = true;
// Check to see if we already have created the
// right serializer.
var value = dictionary[key];
WriteStartElement(key);
if (value == null)
{
// Write out the null version for the object
WriteNull();
}
else
{
// Write out the instance
var ser = CreateSerializer(value.GetType());
ser.WriteObject(Stream, value) ;
}
WriteEndElement(key);
}
// Close the document
WriteEndDocument();
}
If you are curious about the other details, I recommend that you look at the source code and try it out.
Summary
ASP.NET MVC helps developers build REST architectures for their applications. The infrastructure has enough extensibility in it to allow us to augment its behavior as needed. In this article, we looked at how we could get a current application that uses ViewData to add JSON and XML support simply by changing our custom Controller’s base class. The source code continues the idea to look at how you can also accept JSON and XML data in a request when handling HTTP PUT and POST methods.
When developing REST services for your applications, it may make sense to expose the JSON and XML functionality at the same place that you expose the HTML pages. By separating out the resource from its representation, your applications can gain quite a bit of richness without a lot of extra effort.