W3C home > Mailing lists > Public > www-tag@w3.org > December 2012

RE: Question to the www-tag candidates: hypermedia JSON

From: Larry Masinter <masinter@adobe.com>
Date: Fri, 7 Dec 2012 10:49:12 -0800
To: Karl Dubost <karld@opera.com>, "www-tag@w3.org List" <www-tag@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D1E372B7CC7@nambxv01a.corp.adobe.com>
Let me try to give a serious answer to Robin's questions
http://lists.w3.org/Archives/Public/www-tag/2012Dec/0029.html

> What would be your recommendations on versioning an HTTP interface with  JSON payloads?
> Subsidiary: what is your take on GitHub's use of a media type parameter  for API versioning?

Versioning of interfaces, and the "how to do versioning" question in general, is a question I've tried to bring up and keep alive in the TAG since I started. It's a hard question to come up with generally applicable principles, and the TAG has gotten caught in its complexities without good results many times in the past.

This work hasn't made it out of the TAG but I'd welcome some additional discussion and support for taking on versioning issues, since it is a central architectural question.

See from 2009    http://www.w3.org/2001/tag/doc/versioning-html/versioning-html-20090601 and more recently  http://www.w3.org/wiki/Evolution (although a wiki, there haven't been any other contributions, please take a look!).

I didn't specifically address versioning of JSON-based interfaces (whether or not layered on HTTP), although I've written on XML-based HTTP interfaces and the issues around them (http://tools.ietf.org/html/rfc3470) and at the last IETF applications area meeting suggested extending the advice for JSON-based interfaces. One of the major differences between XML and JSON are the XML extensibility features left behind (namespaces, mainly, xml:base, xml:lang, schemas) that now people are busy trying to reinvent.

I'd welcome a TAG approach to extensibility methods which was principled, and I'd love to have a good discussion about extensibility methods, so I hope other TAG candidates are interested in engaging. 

To be more concrete:  HTTP-based interfaces are not as fragile as most, since HTTP-based interfaces have a primary extensibility method: if it's not backward compatible, then offer the new service at a new URL.   I've read of, but haven't followed, proposals for JSON Schemas,  but I'd research the current discussions before trying to come to a conclusion about the "right" way to do extensibility.

As far as GitHub's use of media type parameters: I don't know anything about it, except I do know that most attempts to use media types as an enumerated set of values used for negotiation, most of them are wrong. Media types are impoverished without parameters, and don't form an enumerated or complete space. People want some kind of enumerated values, but MIME wasn't designed for it. See http://tools.ietf.org/html/draft-masinter-mime-web-info-02 for example of some of the issues (some extracted to the Evolution wiki previously mentioned).
Received on Friday, 7 December 2012 18:49:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 December 2012 18:49:51 GMT