[Engine-devel] planned changes for api capabilities resource

[Michael Pasternak]

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