[occi-wg] Fwd: Versioning?

[Sam Johnston]

Oops... including list.

---------- Forwarded message ----------
From: Sam Johnston <samj at samj.net>
Date: Sun, 31 May 2009 19:20:50 +0100
Subject: Re: [occi-wg] Versioning?
To: Mark Masterson <mmasterson at csc.com>

Mark,

Are you implying we might not get it right the first time? ;)

I thought I'd mentioned this point before but apparently not... I too
had read those references and thus far was planning to leave version
cruft out of the purl.org URLs, content types, etc. knowing that it
can be easily added later should there be revisions.

That said our extension mechanisms should cater for most change (eg
new verbs, attributes and perhaps even nouns) without having to break
existing systems. Also refer to my earlier rants about the core
protocol providing only extensibility.

HTTP will likely always be 1.1 but that's not to say the spec is
immutable - just look at the Link: headers which will allow us to
avoid Atom for individual resources.

Sam on iPhone

On 5/31/09, Mark Masterson <mmasterson at csc.com> wrote:
> What about versioning the API?  This is surprisingly hard to get right, but
> (for many, just as surprisingly) awfully important -- I have seen numerous
> enterprisey distributed system efforts fail for just (and entirely) this
> reason.  There is no mention in any of the three APIs being talked about
> here (GoGrid, EH, or Sun) of versioning that I can find?  Nor do I recal it
> being discussed as a first class design goal on this list yet?  On the wiki
> there is no mention of it in the API Design section.
>
> Although I confess that I have never used it in anger, there is a
> fascinating proposal for attacking versioning in a RESTful way here:
> http://barelyenough.org/blog/2008/05/versioning-rest-web-services/  (with
> some caveats here:
> http://barelyenough.org/blog/2008/05/versioning-rest-web-services-tricks-and-tips/
> ).  The REST gurus in this group may well know an even better way to solve
> the problem.
>
> I'd be interested in hearing others' views on this.
>
>
> Mark Masterson
> Enterprise architect, troublemaker
> CSC
>
> Financial Services EMEA | m: +49.172.6163412 | Internal blog: Schloss
> Masterson | Public blog: Process Perfection
> (http://jroller.com/MasterMark/) | mmasterson at csc.com | www.csc.com.
>
>
> CSC • This is a PRIVATE message. If you are not the intended recipient,
> please delete without copying and kindly advise us by e-mail of the mistake
> in delivery.  NOTE: Regardless of content, this e-mail shall not operate to
> bind CSC to any order or other contract unless pursuant to explicit written
> agreement or government initiative expressly permitting the use of e-mail
> for such purpose ï CSC Computer Sciences Limited • Registered Office: Royal
> Pavilion, Wellesley Road, Aldershot, Hampshire, GU11 1PZ, UK • Registered
> in England No: 0963578
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>