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

Question

I understand why "REST framework" vendors want to provide the support for returning both Json based representations and XML based representations, but why do people want to return both from the same service?

• Is it because you will have client applications that are built on a platform that has no available Json parser?

• Is it because you are hoping for wider adoption of the interface because you can appeal to more people?

• Is it because you feel that it a standard convention that all RESTful interfaces follow?

If you do deliver both:

Do you avoid namespaces in the XML so that it can be compatible with the Json format? Or do you have just one namespace for all of your data elements?

Do you have some kind of standardized mechanism for mapping attributes and elements into some kind of consistent Json format, or do you just avoid attributes in your XML?

Do you create different endpoints for each representation, or do you use content negotiation to deliver the requested format? Do you have a default format?

If you use caching on editable resources and use different URLs, how do you ensure that when one representation is invalidated that the other representations are also invalidation?

Do you feel the benefit of supporting multiple formats is worth the effort required?

Summary of responses:

So the primary reason seems to be one of preference. Some developers prefer curly braces and some prefer angle brackets.

Some people want to migrate from XML to Json and therefore supporting both is required for backward compatibility.

Some want to use Json, but are concerned that some developers are scared of Json, so they support both so as not to offend anyone.

It is easy to turn the feature on in framework XYZ so why not!

Another interesting suggested reason, is JSON can be used to provide a quick a dirty data summary and XML can be used as a semantically rich complete representation.

question from:https://stackoverflow.com/questions/1649793/why-do-people-want-to-deliver-both-json-and-xml-as-output-to-their-rest-interfac

Answer 1

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.