metabrainz / web-service-v3-design

A collaborative specification for the third version of the MusicBrainz web service
2 stars 1 forks source link

No support for Xml #14

Open ijabz opened 12 years ago

ijabz commented 12 years ago

The documentation says in the access session 'All request and response bodies are encoded as UTF-8 JSON, to be served with the application/json mime-type.' . When I questioned the absence of Xml support ocharles told me that this could be added at a later date, but expected it would not be.

I disagree.

  1. Our existing customer base use Xml, whilst many users may wish for support for Json, I expect many do not and would prefer to continue to use Xml, myself being one such customer. Of course json is useful for webbased/javascripta applications because the way it can be implicity mapped directly into javascript objects. But for non-javascript applications this offers no advantage, and a number of disadvantages over Xml: Json not properly defined by a schema Data cannot be unmarshalled/marsahlled from a schema Cannot define datatypes

all making things more difficult for the user of the api.

Discogs dropped Xml support from their latest api (even though they still only provide data dumps in Xml) and this caused problems for alot of devlopers, and their api is alot simpler and less encompassing then Musicbrainz.

  1. Ouputting in XML conforming to a schema helps Musicbrainz development. Its much easier to ensure data output is valid because we can at least say whether it confoms to schema and write tests for this, a number of problems have been resolved this way . beter coordination between searchserver and musicbrainz as the schema usually makes it clear how the data should be transferred between the two.
  2. It would be straight forward to output data in Xml and Json from a shared model as the search server currently does, and because this model is based on the schema we can say xml conforms to schema, and json is based on schema but is a transformation of the schema (i.e release-list -> releases for json). So i dont think the amount of work required to support Xml and Json should be much much more than just one format.
mayhem commented 12 years ago

I personally would love to not maintain a schema and XML bindings. People are really frowning on using XML based APIs these days. But ijabz's comments are quite valid and we need to support an XML interface.

How about we deprecate that interface on the day that we release it? ;)

ocharles commented 12 years ago

I do not think we should release with something deprecated. We either release with full support for it, or we say that /ws/2 is the last web service with XML support. Also, just like to note that @adhawkins has expressed a want for XML.

mayhem commented 12 years ago

My comment about releasing deprecated was a joke. Sadly, we need to have XML support.