On Jan 25, 2011, at 9:01 PM, David Lutterkort wrote: > On Fri, 2011-01-21 at 13:29 -0500, [email protected] wrote: >> From: Tobias Crawley <[email protected]> >> >> Changes to the server: >> >> This provides capability reporting to the /api and the client. The /api xml >> format >> now looks like: >> >> <link href='http://localhost:3001/api/instances' rel='instances'> >> <feature name='hardware_profiles'></feature> >> <feature name='user_name'></feature> >> <feature name='authentication_key'></feature> >> <operation method='post' name='reboot' scope='member'> >> </operation> >> <operation method='get' name='show' scope='member'> >> <param feature='authentication_key' /> >> </operation> >> <operation method='post' name='start' scope='member'> >> </operation> >> <operation method='delete' name='destroy' scope='member'> >> </operation> >> <operation method='post' name='stop' scope='member'> >> </operation> >> <operation method='post' name='create' scope='collection'> >> <param feature='hardware_profiles' /> >> <param feature='user_name' /> >> <param feature='authentication_key' /> >> </operation> >> <operation method='get' name='index' scope='collection'> >> </operation> >> </link> > > After thinking about this some more, it seems to me we are describing > too much standard RESTishness here; especially when you look at the > description of collections like realms. > > I do see the need to express better what operations are supported for a > certain collection; in particular, more details about how features > modify specific operations. > > OTOH, the bits of the api XML that document standard REST operations > look too much like an ad-hoc variant of WADL/WSDL. So I am going to hold > off on committing this patch. > > I'd be curious to see what others think of this issue, and what needs > they have in this area.
I personally like to use HTTP protocol instead of additional XML. I recently found this: "The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the *capabilities* of a server, without implying a resource action or initiating a resource retrieval." [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html So maybe we could re-think idea of capabilities and use this HTTP method to get all supported operations on top of collection/member. Something like: OPTIONS /api/instances <capabilities> <operation method='post' name='create'> ... ... </capabilities> OPTIONS /api/instances/i-123456 <capabilities> <operation method='post' name='reboot'> ... ... </capabilities> What do you think ? -- Michal Michal Fojtik Software Engineer, Deltacloud API project http://www.deltacloud.org [email protected]
