Why do people want to deliver both Json and XML as output to their REST interfaces?

Question

A completely different reason than what's been said so far --

REST interfaces are about Resources, and each Resource has an identifier, which are URLs. Just because you want the Resource in a different serialization, be it XML, JSON, HTML, or something else, we're still describing the same Resource.

So, instead of giving a different path to the XML vs. the JSON one, we use the 'Accept' header to determine what the client is interested in. In some cases, services use the 'Accept-Language' header to determine what language they should use for their metadata.

If we assign different identifiers to different serializations of the records, for the semantic web, we then have to embed extra information to link to all of the records that describe the 'same' object.

You can find more information about these efforts under the term Linked Data, although that typically refers to using RDF at the serialization.

update : with the discussion of linking to specific formats, I'd also recommend people consider reading up on the Functional Requirements for Bibliographic Records (aka FRBR), which has a conceptual model for the relationships between 'Book' as an abstract 'Work', vs. the physical 'Item', and the levels in between. There has been a bit of discussion in the library, information and semantic web communities on FRBR, including how it relates to digital objects.

Basically, the issue is that you can assign identifiers at a number of levels (eg, the Resource, and the text of the metadata about the Resource, or the serialization of the text of the metadata about the Resource), and each have their own use.

You might also see OAI-ORE for a specification for reporting relationships between objects, including alternate formats or languages.

Json is often suitable for client side scripts. It is a super-lightweight response and the most part of JavaScript frameworks come with a parser built-in. On the other side, many server side applications and languages still rely heavily on XML. Just to name one: Java.

Of course, XML can be parsed with JavaScript and Java (and the most part of other programming languages) has at least one Json parser. But at the moment this seems to be the most common practice.

Talking about the "implementation vs benefit" topic, I mostly work with Ruby and I can tell you Ruby on Rails provides the ability to create a Json or XML response in less than a couple of seconds from the same source. In this case it's not a problem and I usually add that feature if I think it could be useful.

With other technologies, for example PHP, it would require more effort and the implementation would have a different cost. Unless this would be a fundamental feature, I would probably stick with one response until I don't find the need to provide to different versions.

I have written a pretty verbose article myself on the History of REST, SOAP, POX and JSON Web Services. Basically goes into detail about the existence and benefits of the different options, unfortunately its too long to list all the contents here.

Basically XML is more verbose, stricter and verifiable which makes it a good candidate for interoperability but not that great of a programmatic fit for most programming languages. It also supports the concept of a schema (i.e. metadata about the data) which can be found in XSD/DTD documents. A WSDL is an extension of an XSD and also supports describing web services in infinite details (i.e. SOAP Web Services).

JSON is more lightweight, loosely-typed text format which as is effectively 'Serialized JSON' to provide the best programmatic fit for JavaScript since it a JSON string can be natively eval()'ed into a JavaScript object. It's lack of namespaces and concepts attributes/elements make it a better fit for most other programming languages as well. Unfortunately it only has support for the basic types: Number, String, Boolean, Object and Arrays. Which does not make it the best choice for interoperability.

I have some Northwind database benchmarks comparing the two and it looks like XML is on average 2x the size of JSON for the equivalent dataset. Although if your XML document contains many different namespaces the payload can blow out to much more than that.

I have not direct insight into this as I only produce REST interfaces. for "internal" consumption.

I'm guessing providers of public APIs are merely "hedging their bet", in this ever- evolving, fast paced and competitive environment.

Furthermore, for hanlding relatively simple object models (which most of these probably are), the extra effort to handle both format is probably minimal and hence worthwhile.