On 05/29/2012 10:56 AM, Geert Jansen wrote:
Hi Michael,
two questions:
Can you elaborate on why you think there's no backwards compatibility issues?
there is no point in using this resource programmatically, as it only contains
enumerations
available in the system for given version and some other metadata,
i.e it used by developers during the coding and it's not real system resource.
In your proposal, are you leaving /api/capabilites in place as it is now?
no, please see new modelling below.
If not how to you enumerate the different versions?
since our resource id is opaque by definition - it doesn't have to be UUID,
the id for version_capabilities resource can be the version itself, i.e 3.0
/ 3.1 / etc.
(worst case if someone likes UUID more we can convert version str. to UUID)
Regards,
Geert
On 05/24/2012 09:53 AM, Michael Pasternak wrote:
> the motivation:
> ===============
>
> 1. current design is not restfull
> 2. is not consistent with the rest of api impl.
>
> impacts:
> ========
>
> as this resource not used programmatically, we do not expect any
> backward compatibility issues
>
> planned change is:
> =================
>
> from:
>
>
http://localhost:8080/api/capabilities
>
> <capabilities>
> <version major="3" minor="1">
> ...
> <version/>
> <version major="3" minor="0">
> ...
> <version/>
> </capabilities>
>
> to:
>
>
http://localhost:8080/api/capabilities/x.y
>
> <capabilities id="x.y">
> <version major="x" minor="y">
> ...
> </capabilities>
>
> or
>
> <capabilities id="x.y" version="x.y">
> ...
> </capabilities>
>
> or
>
>
http://localhost:8080/api/capabilities/UUID
> <capabilities id="UUID" version="x.y">
> ...
> </capabilities>
>
>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D