On 05/29/2012 04:14 PM, Geert Jansen wrote:
On 05/29/2012 12:12 PM, Michael Pasternak wrote:
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.
I'm not convinced that that is true. For example, applications can use the "power_managers" and "cpus" elements to prepopulate lists in a user interface for example.
this is good example indeed, then what about leaving /capabilities as is [1] only adding single resource retrieval capability [2] to comply with collection/resource pattern? [1] <capabilities> <version major="3" minor="1"> ... </version> <version major="3" minor="1"> ... </version> ... </capabilities> [2] /api/capabilities/UUID <version major="3" minor="1" id=UUID> ... </version>
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)
How do you get a list of which IDs / versions are available?
by listing all <version>s as today only adding id/href to it, /api/capabilities <capabilities> <version major="3" minor="1" id=xxx href=/api/capabilities/xxx> ... </version> <version major="3" minor="1" id=yyy href=/api/capabilities/yyy> ... </version> ... </capabilities> i.e same as for any resource in api.
Regards, Geert
-- Michael Pasternak RedHat, ENG-Virtualization R&D