On Tue, 2010-11-09 at 08:25 -0500, Tobias Crawley wrote:
> This patch adds /api/capabilities, which currently lists the operations
> available in the collection. The next step would be for the client to parse
> and use this info.
>
> This is the second version of this patch, and nests <capabilitues>
> under the <api> in the xml output based on mfojtik's feedback.
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
