Re: [Engine-devel] planned changes for api capabilities resource
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