Feedback on XML and JSON formatting

Topics: Web Api
Oct 13, 2011 at 12:20 PM
Edited Oct 13, 2011 at 1:59 PM

I'm evaluating the Web API for use in implementing our forthcoming REST service.  Other contenders are WCF 4.0 and plain MVC 3.

Working on formatting my model classes for XML and JSON this morning, I found that the default use of the DataContractSerializer for JSON and the XmlSerializer for XML is wonderfully granular, but results in some ugly- and confusing- looking model classes.  You have to apply one attribute for XML and another for JSON (e.g. on properties).  Every class needs a [DataContract] attribute, but not every class needs an [XmlType] attribute.  The differing opt-in behaviours means that [XmlIgnore] has to be applied to a non-serialized member, while a [DataMember] must NOT be applied.  The result is a mess.

Using the DataContractSerializer for XML solves all this; the resulting model classes look nice and consistent.  And at least it's easy to switch to the DCS:-

      var config = new HttpConfiguration ();
      config.Formatters.XmlFormatter.UseDataContractSerializer = true;

However, I would argue that the DCS should be the default for XML, and the more granular but more ugly option of using the XmlSerializer should have to be explicitly turned on by the Web API user.

My two cents...


**UPDATE**  After reading SiggiG's comments in a related post today, I guess the current defaults should remain as-is if most people tend to use different casing for the names of the same JSON properties vs XML elements.  Not something I do, being a lower-case person.

Oct 13, 2011 at 2:21 PM

Here's an idea...

Introduce a new attribute syntax for serialization that caters to the needs of both XML and JSON formatting (maybe other formats too).


[WebDataMember(XmlName="OwnerCode", JsonName="ownerCode")]
public String AccountOwnerCode { get; set; }

This would be like a "facade" syntax that would map internally to the XmlSerializer and DataContractJsonSerializer (and others).  There would be other args of course: some common, some format specific.  The inclusion model should be opt-in; i.e. if [WebDataMember] isn't applied, then the member isn't serialized.  The model class would be decorated with [WebDataType] (or [WebDataContract] maybe).

Oct 13, 2011 at 5:47 PM
Edited Oct 13, 2011 at 5:48 PM

When we designed web api we had a specific design goal NOT to make it use DataContractSerializer for xml by default. The reasoning is because DCS is very limited in terms of what it allows you to do in xml. From what we have seen in the wild, folks want as much control as possible over xml, and they want to support deserializing arbitrary XML representations.

For both reasons we chose XmlSerializer by default. For DCS however we did make it easy in Preview 5 to enable DCS by default through a switch on the XmlMediaTypeFormatter.

Oct 13, 2011 at 8:29 PM

That's fair enough, Glenn.  I've always found the DCS good enough for my needs, but I understand your design goals.  And it's certainly easy enough to switch in the DCS if you want it.  If you decorate a model class for both the DCS and XmlSerializer, the resulting code doesn't look very pretty, but that's the price you pay for complete control - which I guess is what the Web API is all about.