Consider only adding the JSON formatter by default

[danroth27]

Not everyone wants XML support for their Web APIs. In general it is better to add something than to have to remove it. Should we only have the JSON formatter by default? Should we factor out the XML support into its own package?

As an example of when having XML enabled by default causes problems consider this StackOverflow thread where a bunch of folks would prefer to see JSON by default when using Chrome to test their Web API:
http://stackoverflow.com/questions/9847564/how-do-i-get-asp-net-web-api-to-return-json-instead-of-xml-using-chrome.

See further discussion here: dotnet/aspnetcore#245.

[MMrR0b0TT]

I'd say that is a good idea. I have been changing this everytime I start a new project and sometimes I receive some questions about this "issue". Change it, please!

[emrys-dev]

Its really a good idea. Json is a kind of standard now... Just put some configuration for those who needs XML.

[stanislavromanov]

It would be nice if we could just use JSON as default and leave XML as secondary. Right now it's opposite.

[ctolkien]

+1 on having JSON formatter by default.

[JamesNK]

The first thing I do with a blank Web API project is add:

config.Formatters.Remove(config.Formatters.XmlFormatter);

I have no opinion on putting the XML formatter in its own assembly but +1 to remove it from the configured formatters by default.

[spboyer]

JSON should be the default and having the option to add the XML formatter would be the preferred via nuget package.

XML by default was there probably due to the fact that WebAPI came from WCF with SOAP + XML being the primary transport.

[cmatskas]

JSON default +1, XML optional

[khalidabuhakmeh]

👍

[LucasMoffitt]

Json should be the default with XML being very optional.

[paulirwin]

+1 for JSON being default.

[davymac23]

+1 for JSON by default - XML as an option

[nvivo]

Just for some clarification on the issue: JSON is currently the default. If you create a request without any "Accept" headers, web api seems to return json (probably because it is registered first?)

The issue is that all major browsers except IE request specifically for "application/xml" by default if you do a request from the url bar. Asp.net has content negotiation, so it will try to honor the request and selects the Xml formatter (because it is registered). So, ASP.NET is technically doing the right thing.

The discussion is just if these lines should be there by default (and the InputFormatter counterpart).

Now, I also have some serious opinions on whether content negotiation between xml and json by default is a good idea. Simple examples will always work, but in practice it is ridiculously easy to make things break with valid code. Consider this code:

public object Get()
{
    return new
    {
        count = 3,
        records = new[] { 1, 2, 3 }
    };
}

This is a very common pattern for a web api + javascript, and the xml serializer will just blow up here complaining there is no DataContractAttribute in the anonymous object, while Json just works.

There are also differences in how both serializers handle things that cause different behavior in applications using json vs xml. Look at this, using a empty web project with latest web api, default settings:

public class SomeClass
{
    public SomeClass()
    {
        A = new List<int> { 1, 2 };
        B = new List<int> { 1, 2 };
    }

    public List<int> A { get; set; }
    public List<int> B { get; private set; }
}

public class ValuesController : ApiController
{
    public SomeClass Get()
    {
        return new SomeClass();
    }

    public SomeClass Post([FromBody] SomeClass x)
    {
        return x;
    }
}

Now, just get the values with different headers:

GET /api/values
Accept: application/json

{ "A": [1, 2], "B": [1, 2] }

Same request with XML:

GET /api/values
Accept: application/xml

<SomeClass>
  <A>
   <d2p1:int>1</d2p1:int>
   <d2p1:int>2</d2p1:int>
  </A>
</SomeClass>

The default xml serializer ignores read only properties, so there is no "B" there, causing different client behavior.

Now for some issues in the input serialization:

POST /api/values
Accept: application/json
Content-type: application/json
{ "A": [3, 4] }

Response:

{ "A": [1, 2, 3, 4], "B": [1, 2] }

And with XML:

POST /api/values
Accept: application/xml
Content-type: application/xml
<SomeClass xmlns="http://schemas.datacontract.org/2004/07/WebApplication1.Controllers">
 <A xmlns:d2p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
  <d2p1:int>3</d2p1:int>
  <d2p1:int>4</d2p1:int>
 </A>
</SomeClass>

<SomeClass>
 <A>
   <d2p1:int>3</d2p1:int>
   <d2p1:int>4</d2p1:int>
 </A>
</SomeClass>

Here, JSON.NET by default merges lists while the xml serializer replaces it. Those are just some things I found very quickly in real world apps.

Some of these settings could even be tuned by default to have similar results (causing a lot of breaking changes), but is it worth the hassle?

By having both serializers by default we guarantee there is a huge number of ASP.NET websites out there that have never been properly tested and have broken APIs, as a poor showcase for the platform.

I believe that having content negotiation in an application is not that trivial, and is just as internationalization: to make it work, you need to develop and test your application for that.

The simple solution is just have a single protocol (json) by default and if you need two formats, you enable it and deal with the consequences just like supporting two languages.

[stanislavromanov]

but it is worth the hassle?

I agree that it's not worth it.

have broken APIs, as a poor showcase for the platform

Also agree with this.