[Engine-devel] planned changes for api capabilities resource
Michael Pasternak
mpastern at redhat.com
Wed May 30 06:45:48 UTC 2012
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
More information about the Devel
mailing list