RE: versioning

> -----Original Message-----
> From: Ruben Verborgh [mailto:ruben.verborgh@ugent.be]
> Sent: Friday, September 19, 2014 8:14 AM
> To: László Lajos Jánszky
> Cc: public-hydra@w3.org
> Subject: Re: versioning
> 
> Hi László,
> 
> > 1.) API versioning
> >
> > Afaik by non backward compatible changes it is better to add a new API
> > root with the major version number. What about the minor, revision and
> > build numbers?
> 
> I'm not sure whether we need this.
> The use of hypermedia as the engine of application state should actually
> avoid the need for versioning in the majority of cases, just like you as a
> human can also navigate new versions of a site.
> 

Very interesting point Ruben. It's this very 'dynamic-ness' of Hydra that sets it apart I think, but it also tends to confuse newcomers (since it's so unfamiliar to developers used to code-generating directly from static API descriptions like IDL or WSDL).

So should the spec somehow allude to the point that the concept of versioning needs to be reconsidered when using hypermedia (since developers (or at least the good ones!) will naturally ask 'how does API versioning work with Hydra?')...? 

For example, look at [1] and [2] to see how important 'API versioning' is to Apigee (quotes: 'Versioning - one of the most important considerations when designing your pragmatic API', and 'Never release an API without a version and make the version mandatory'!)

[1] https://blog.apigee.com/detail/restful_api_design_how_many_versions
[2] https://blog.apigee.com/detail/restful_api_design_tips_for_versioning/

> >
> > 2.) resource versioning
> >
> > By resource versioning there are data storage solutions (e.g. event
> > storage aggregate version) which generate a version number after
> > updating a resource. This version number should be part of the write
> > requests to prevent concurrency related issues, like overriding
> > previous updates with stale data by using PUT, etc... (It is pretty
> > simple, the server checks the resource version sent with the request
> > and if it does not equal with the current version of the resource,
> > then the server returns a proper error code, possibly 409.) Should
> > this version number be part of the hydra vocab?
> 
> While I see the need for this,
> I personally don't think it should be part of Hydra Core.
> Check out other solutions such as Memento [1].
> 

+1

> Best,
> 
> Ruben
> 
> [1] http://mementoweb.org/

Received on Friday, 19 September 2014 08:40:01 UTC