[openstack-dev] [api] Analysis of current API design

Everett Toews everett.toews at RACKSPACE.COM
Fri Dec 19 04:19:41 UTC 2014

Hi All,

At the recent API WG meeting [1] we discussed the need for more analysis of current API design.

We need to get better at doing analysis of current API design as part of our guideline proposals. We are not creating these guidelines in a vacuum. The current design should be analyzed and taken into account.

Naturally the type of analysis will vary from guideline to guideline but backing your proposals with some kind of analysis will only make them better. Let’s take some examples.

1. Anne Gentle and I want to improve the consistency of service catalogs across cloud providers both public and private. This is going to require the analysis of many providers and we’ve got a start on it here [2]. Hopefully a guideline for the service catalog should fall out of the analysis of the many providers.

2. There’s a guideline for metadata up for review [3]. I wasn’t aware of all of the places where the concept of metadata is used in OpenStack so I did some analysis [4]. I found that the representation was pretty consistent but how metadata was CRUDed wasn’t as consistent. I hope that information can help the review along.

3. This Guideline for collection resources' representation structures [5] basically codifies in a guideline what was found in the analysis. Good stuff and it has definitely helped the review along.

For more information about analysis of current API design see #1 of How to Contribute [5]

Any thoughts or feedback on the above?


[1] http://eavesdrop.openstack.org/meetings/api_wg/2014/api_wg.2014-12-18-16.00.log.html
[2] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog
[3] https://review.openstack.org/#/c/141229/
[4] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Metadata
[5] https://review.openstack.org/#/c/133660/
[6] https://wiki.openstack.org/wiki/API_Working_Group#How_to_Contribute

More information about the OpenStack-dev mailing list