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