On 11/11/2010 08:15 PM, David Lutterkort wrote:
This feels a little un-RESTy to me, and also doesn't mesh too well with the features support we already have. Basically, there are a few ways in which a driver might not support something:1. driver does not support a collection (e.g. instances for a storage-only driver) The client learns that by looking at the entry point XML and notices that there is no mention of the instances collection 2. driver does not support some standard REST operation on a collection, say 'create image'. To me, the best way to indicate that is to report the allowed methods (GET/POST/PUT/DELETE) on the collection 3. driver supports some non-standard REST operation (start instance) 4. driver supports a certain operation, but only some of the parameters for it. This case should be covered by features. I'd much prefer if we encode all this information in the entrypoint XML. Since (1) and (4) are already covered by the current impl, what I have in mind is for (2) and (3) to become additions to the XML, e.g. <link rel="images" href="..."> <operations> <!-- I wonder if we should just steal nomenclature etc. from Rails3's routes --> <operation name="index" method="get" scope="collection"/> <operation name="show" method="get" scope="member"/> <operation name="something_random" method="get" scope="member"/> </operation> </link>
David - this makes sense - the client should be able to discover the api in one call. I'll rework the capabilities to be part of the entry point response, and modify the client to properly discover the capabilities. I'll shoot for having something by the end of the week.
Toby
