incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toby Crawley <>
Subject New /api format with exposed capabilities
Date Fri, 03 Dec 2010 18:26:58 GMT
Based on rabbit being able to now inspect the operations provided by a
driver (using capabilities), we have the ability to inform the client
of the available operations. Based on feedback from David [1], I've
modified the top level /api response to advertise the available

<api driver='ec2' version='0.2'>
   <link href='http://localhost:3001/api/instances' rel='instances'>
     <operation method='get' name='show' scope='member'>
       <feature name='authentication_key'></feature>
     <operation method='delete' name='destroy' scope='member'/>
     <operation method='post' name='stop' scope='member'/>
     <operation method='post' name='reboot' scope='member'/>
     <operation method='post' name='create' scope='collection'>
       <feature name='user_data'></feature>
       <feature name='authentication_key'></feature>
       <feature name='security_group'></feature>
       <feature name='register_to_load_balancer'></feature>
     <operation method='get' name='index' scope='collection'/>



Since features are declared on a per operation basis, I nested them
under each operation.

With this change, I believe it may give a client enough information to
fully configure itself dynamically, and not have to make too many
assumptions about operations and operation methods.

I wanted to get some feedback on this before continuing with the work
on the client to parse and use this new entry point format. How does
this new format look?

Would you prefer that the operation/feature collections be nested
under operations/features tags?

   <operation ...>
       <feature .../>

To me, it's just noise, but if it makes it easier for some libraries/
langs to parse, I'm fine with adding it.



View raw message