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.
Regards,
Geert