- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Fri, 19 Sep 2014 09:13:45 +0200
- To: László Lajos Jánszky <laszlo.janszky@gmail.com>
- Cc: "public-hydra@w3.org" <public-hydra@w3.org>
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. > > 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]. Best, Ruben [1] http://mementoweb.org/
Received on Friday, 19 September 2014 07:14:19 UTC