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.
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
Among the headers is one called
Accept containing values like
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
With resulting response:
HTTP/1.1 200 OK
“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
<?xml version=”1.0″ encoding=”UTF-8″?>
<author>Snarky Human Person</author>
<name>Hi, That’s a Nice API You Have There</name>
<name>ASP.NET Web API for Cool Cats</name>