Return XML vs JSON

 Return XML vs JSON

Return XML vs JSON

There are two primary web service return formats: XML and JSON. Extensible Markup Language (XML) has long been a popular way to structure data using familiar markup language. It is both human and machine readable and is very similar in appearance to HTML. It follows a set of standards for data communication over networks between devices and is iteratively parseable. One advantage of consuming data in this format is its structure. Data can be added or removed from the result set, but it will often exist in a predictable format so you don’t have to worry about your parsing routine breaking when the data changes over time. Despite its advantages, one drawback of XML is its size, because it contains many characters strictly related to formatting. When downloading data to a mobile device, it would be ideal to just obtain the relevant content instead of data related to content formatting. This is where JSON comes in.

JavaScript Object Notation (JSON) is a text-based data interchange format derived from theJavaScript scripting language. It is formatted as key-value pairs and is often lauded as being a lower-overhead to XML because it focuses more on content and less on formatting. This works to our advantage when we want to keep data interchange packets as compact as we viably can. Now to be fair to XML, it is possible to format it in specific ways or use compression to make it comparable in size to JSON, but generally I find JSON to be much smaller in size and therefore preferable to XML.

One final observation (geared toward iOS ) focuses on how we process the two formats on the device once information has been returned from the web service. Parsing XML in iOS can be a bit tedious as it involves implementing a handful of NSXMLParserDelegate methods to iterate through the XML code. This can require a significant amount of coding. On the other hand, if a JSON object is returned from a web service we can convert it directly into native objects such as NSDictionary or NSArray. These objects can be archived and we can access data elements as key-value pairs without having to implement any delegate methods or iterate through the result data. This equates to a measurable increase in speed and efficiency. So, JSON is absolutely the way to go for mobile device data consumption.

Decide JSON/XML as return type

For every HTTP request/response, there is a process called Content Negotiation (sometimes mistakenly called Content-Type Negotiation). In this process, the client (e.g. your web browser) tells the server how it wants the response formatted. The parameters that determine what the Content Negotiation process looks like are defined in HTTP headers like Accept, Referer, Cookie, Host, etc.

Among the headers is one called Accept containing values like text/html, application/json, multipart/form-data, or various other values. These are known as Media Types. There are a lot of different Media Types, but generally you’ll only ever need to know about a handful. As an example of how media types work in the Content Negotiation process, a client basically tells the server “Hey, if you can send data back in JSON format, please do that. If not, I can also read XML.”

The server should reply in one of those formats if possible. The list is also ordered by priority; the server is expected to send data back in the first requested format if possible. If it can’t, it should send in the next requested format, and so on. If the server cannot match any of the Accept headers sent by the client, generally it will return its own default format.

By default in ASP.NET Web API, you can send various types of Accept headers and automatically receive a serialized response in that format.

Here’s a simplified example request:
GET /api/books/ HTTP/1.1
Accept: application/json,application/xml
[blank line]
With resulting response:
HTTP/1.1 200 OK
Content-Type: application/json

“id” : “978-0641873245”,
“name” : “Hi, That’s a Nice API You Have There”,
“author” : “Snarky Human Person”,
“id” : “978-1411923349”,
“name” : “ASP.NET Web API for Cool Cats”,
“author” : “Captain Stacktrace”,
Now, if  we decided to remove the JSON serializer from our ASP.NET Web API serializer collection, but still had the XML serializer, we would automatically get an XML response, like the one below. Note that we would also get the same response if we had defined application/xmlfirst in our Accept request header above.
HTTP/1.1 200 OK
Content-Type: application/xml

<?xml version=”1.0″ encoding=”UTF-8″?>
<author>Snarky Human Person</author>
<name>Hi, That’s a Nice API You Have There</name>
<author>Captain Stacktrace</author>
<name>ASP.NET Web API for Cool Cats</name>

Leave a Reply

Your email address will not be published. Required fields are marked *