Proposal: Don't add a Xml Formatter by default to MvcOptions

[nvivo]

I'd like to propose removing the default Xml formatters from the MvcOptionsSetup and just requiring whoever needs it to add it manually, instead of making everyone else remove it. It just makes sense.

I have read multiple times about the content negotiation features, and that the browser is not the right tool to test web apis, the recomendation for Fiddler, etc. But still, removing the XmlFormatter is the first thing 90% of developers do when creating a new project.

Most web apis are used to talk to javascript clients like angular, jquery, etc. JSON is the standard for that and the only format most people actually need. Also, it doesn't make much sense to require a tool like Fiddler to see how a JSON is returned from a GET nowadays. Content negotiation should be a feature that is there if we need, not a something we are forced to deal with.

Other than reducing boilerplate code in most applications out there, not adding the Xml Formatter matches the idea of not loading unnecessary things in the app by default, but making us build the app with only the required pieces.

So, please consider using this moment to change this default behavior. It is almost 2015, xml is not something we want to deal with.

[Eilon]

I'm not sure I've seen almost anyone remove the XML formatter from their app (though I'm sure some people do). Web APIs are used very often in server-to-server communication, not just browser AJAX scenarios.

Can you explain in what way having the XML formatter registered interferes with the operation of the application?

[nvivo]

I'd say in most scenarios It is not much about interfering with the operation of the application, but it interferes with tests and expectations. People (me included) like to be able to use the browser for development, and be able to do a GET on an URL and see exactly what your framework will get is very useful. The default configuration returns prevents that and returns a format that will never be used in most cases.

Just for reference, I did a quick search for 'web api json', the first result is this stackoverflow question. This is the top voted and most viewed question for web api in stackoverflow!

The astonishing number of people (420+) upvoting the question and the answers shows this is not an issue few people have. Also, looking at the other top questions for web api there, we can see that most people are doing web development, not server to server communication. That's why most people remove the Xml Formatter as part of the "default asp.net setup".

But for the sake of equality, search for 'web api xml', I get a question with 4 votes asking how to force Xml output, and some other results asking how to actually disable xml formatters.

That being said, there are cases where Xml intereferes with the operation of the application. I use Web API for server to server communication and moved to Json for everything. The reason is that supporting more than one output is hard, once you start customizing the serialization settings (things like NullValueHandling), the output and the meaning of the message starts to differ. Unless you need to support a lot of different clients, it is better to have a single way to encode the message to avoid complexity.

I'm not proposing banning XML from Web Api, I'm proposing making the most common scenario the default. It is better having to add support of something you need than removing something you don't.

[Eilon]

Indeed, very fascinating info - thanks for all the research! (BTW the cynic in me says that another possible reason for the landslide skew of JSON over XML is that for those who do want XML, they have nothing to complain about because it already works.)

And for the record, on a personal level I'm totally fine with JSON being the most loved formatter...

I think this is now in the realm of @yishaigalatzer and @danroth27 to consider.

[danroth27]

JSON is the default format used by Web API and MVC 6. The reason you get back XML in Chrome is because Chrome specifically requests XML using the Accept header. Perhaps Chrome should also ask for JSON?

Even if we removed the XML formatter from the default set of formatters as soon as someone added it back they would be back in the same situation with Chrome again. We are adding support for mapping URL extensions (ex .json, .xml) to media types, which should making testing from the browser easier (see aspnet/Mvc#1673).

Most of the public Web APIs support both JSON and XML and supporting multiple formats allows you to reach more clients. While in general I agree with the principle that it is better to have to add something than to remove it I worry that if we removed support for XML by default we would get a new top StackOverflow question with folks trying to figure out how to turn XML back on. Sill its worth considering - I've filed aspnet/Mvc#1765 to track this request.

[nvivo]

Even if we removed the XML formatter from the default set of formatters as soon as someone added it back they would be back in the same situation with Chrome again

I think you are missing the point. The idea is not to prevent xml from ever being used, is just to make the default behavior what most people use. If someone wants to add the XmlFormatter, it is expected to have that returned if the client asks for it. But most people today, json is the only format they need.

It seems this is the point we have different opinions, and I may be wrong but I doubt it. Maybe you guys could make a poll to see what most people are using web api for.

Also, I don't fall for the "this is what the browser requested" argument. Yes, the browser requests application/xml and I totally get content negotiation. But see, first the browser requests text/html. Should web api add a HtmlFormatter and return a bunch of divs by default? My browser also request the content in portuguese and gzipped. Web api does not try to honor those. Should it try to honor every possible header that any client in the world sends by default? Xml isn't even that important anymore to have special treatment.

I worry that if we removed support for XML by default we would get a new top StackOverflow question with folks trying to figure out how to turn XML back on

I think you really overestimate the amount of people that really want to support XML nowadays. =)

And for the record, I also don't have anything personal against xml. I'm just tired of having to add a line to remove it for every project I create.

[danroth27]

We did end up removing the XmlFormatter by default and moving it to it's own package. We also added some content-negotiation logic that will always pick the default formatter if the Accept header uses a full wildcard, which typically means the request is coming from a browser. So you should now get JSON when testing with Chrome.