On 05/29/2012 06:26 PM, Geert Jansen wrote:
On 05/29/2012 03:44 PM, Michael Pasternak wrote:
> 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>
It would work from a compatibility point of view. However - to be honest - i would leave
it as it is now. You also have non-version specific capabilities there, that do not
fit any model. In my view there is no way to get to a clean design here.
The way i look at /api/capabilities is that is is a single global singleton resource. It
isn't a collection, and neither a resource in a collection.
it should have be collection of version_capabilities cause otherwise it not RESTful
resource and inconsistent
with other resources in api,
as about /currently/ non-version specific capabilities: <permits> should be version
specific as in new version
will be added new permits and same for the <scheduling_policies>, can you remind me
what was the reasons for
making them such.
Regards,
Geert
--
Michael Pasternak
RedHat, ENG-Virtualization R&D