That's exactly what I'm poking at (and what Nati has started doing as well). I was trying to see if there was a consistent way to describe all the API endpoints that could be used to document the combined set.
The raw description is clearly insufficient, so how best to create a final product that has that information. My original question was towards can we embed that additional information in the API description and render it into final form, or do we just "bag it" and manage all of that detail by hand (in restructuredtext, docbook, etc) -joe On Oct 25, 2011, at 3:34 PM, Caitlin Bestler <caitlin.best...@nexenta.com> wrote: > WADL sounds like a wonderful validation tool. > > But shouldn’t our primary goal be finding a consistent way to describe the > APIs > for *application developers*. > > Syntax tools, whether ancient notations like BNF or the latest XML concoction > only tell you the syntax of the operation. > There also has to be consistent information that provides information to the > reader as to when and why they would use > this specific operation, not just how to format it. > > There is also a tendency of syntax oriented tools to omit vital state > information, particularly the expected sequence of operations. > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
