API Special Interest Group
To improve the developer experience of API users by converging the OpenStack API to a consistent and pragmatic RESTful design. The working group creates guidelines that all OpenStack projects should follow for new development, and promotes convergence of new APIs and future versions of existing APIs.
In general we propose, discuss, review, and advocate for API guidelines for all OpenStack Programs to follow. Any member of the working group is able to propose API guidelines. These proposals will be discussed by the working group. When a spec for an API schema is up for review (e.g. a Nova spec for one of the Nova API schemas), the working group members should review the spec and provide feedback with respect to how well it follows the guidelines. The working group members are also responsible for advocating for following the API guidelines within the OpenStack Programs that they work on.
How to Join
For email, we will use the openstack-dev mailing list and prefix the subject line with [api]. Ideally, any OpenStack developer in any program that is discussing their API will also begin to use the [api] prefix so the working group members can be alerted to relevant discussions.
For IRC, we will use #openstack-api on Freenode.
For the OpenStack Summit, design summit sessions.
For meetings, the API Working Group meetings.
For cross-project liaisons (the liaison is the first line of contact for the API WG team members), see Cross-Project Liaisons
1. Analyze Current Design
This is essentially a way to record and visualize the current design of the APIs. It allows us to bring together many examples of the way APIs are designed so they can be analyzed and act as a discussion point. These are examples of good design to be emulated or bad design to be avoided. It can be examples of where the APIs are consistent or where there are inconsistencies.
Review comments and +1 or -1 votes on code changes and specs that affect any OpenStack Program API.
Identifying code changes and specs that affect APIs will require some vigilance on the part of members. Previously identified changes should carry the APIImpact flag, which allows them to be discovered by searching for the APIImpact flag within gerrit. If they find a review that affects an API, they can email the openstack-dev list (using the [api] prefix) to notify the rest of the members of the review.
We should encourage all OpenStack Programs to adopt the use of an APIImpact flag in their commit messages.
4. Announcement Email
When a new guideline has been accepted, it must be announced to openstack-dev (without the [api] prefix for more visibility). The email must include a link to the guideline and the history (links to the wiki and review) of how it came to be.
5. Bugs (DO NOT start doing this yet)
Let's not run around creating bugs for everyone just yet. How and when we start doing this should be determined in discussions in the meetings and on the list.
When a new guideline has been accepted, bugs can be filed against APIs that do not follow the guideline. If the bug forces a backwards incompatible change, it would have to be fixed in the next version or microversion of the API. The bug must include a link to the guideline.
How to Contribute
Contributions come in the form of the deliverables above. For deliverables 2 and 3, you'll first have to go through the If you're a developer section of How_To_Contribute.
1. To contribute to analyzing current design:
- Start at Current Design.
- Find the category of the API design you want to analyze. If it doesn't exist, create it.
- Edit the wiki page and do the analysis.
For example, you want to analyze the consistency of all of the APIs that do pagination. In the Pagination category, create a table that lists all of the ways APIs do pagination side by side.
2. To contribute to the guidelines:
- Follow the Development Workflow
- When you get to Project Setup, start with a
git clone git://git.openstack.org/openstack/api-wg.git
- Continue with the workflow for your change
- Use the Example Guideline Template when creating a completely new guideline
3. To contribute to reviews:
- Find a review on review.openstack.org that impacts any API (this review report).
- When commenting on the review:
- Add comments to the review according to the guidelines.
- Link to the guidelines so the contributor can better understand your reasoning.
- Feel free to let the contributor know you are a member of the API Working Group.
- If the contributor disagrees with your review comments, invite them to start a thread on the openstack-dev mailing list with the prefix [api]
- Vote +1 or -1 on the review
4. To contribute announcement emails:
If you've proposed a guideline and it has been accepted, send an email to openstack-dev to announce it (read #4 above).
5. To contribute bugs (DO NOT start doing this yet):
- Find the project in Launchpad.
- Go to the bug tracker for that project
- Report the bug and be sure to click on Extra Options and include the tag "api"
6. Participate in the discussions at the weekly API Working Group meetings.
The API Working Group is focused on creating guidelines for the HTTP APIs that expose the features to the application developers/operators using those APIs. It is not concerned with the implementation of those APIs.
These are guidelines for both going forward and for providing input (bugs) into the current version of existing APIs. When reporting bugs to the current version of existing APIs, the intent isn't to actually change the current version but to improve the next version of the API.
Recommending the use of an API definition format (e.g. Swagger, RAML, API Blueprint) to drive both the implementation of the service and the client.
Out of Scope
Third-party apis (e.g. EC2, S3, OCCI, etc.) are out of scope.
There is the related Application_Ecosystem_Working_Group (AE WG). The API Working Group (API WG) is complementary to the End User Working Group. The API WG is focused on creating guidelines for the APIs whereas AE WG is focused on creating applications that consume the APIs. The place where these groups meet in the middle is the API, which forms the contract between the two. Members of the AE WG are encouraged to be members of the API WG and vice versa.
Q. My OpenStack Program doesn't have an API schema or a spec review process (like Nova's). What do I do?
A. Propose that your OpenStack Program adopt an API schema language and spec review process. The best way to give the API Working Group some teeth is by reviewing specs of API schemas. Commenting on reviews and giving a +1 or -1 to APIs that follow or don't follow the API guidelines will give this working group the potential to affect real change in OpenStack.
Please add yourself to this list if you are committed to making the OpenStack APIs better.
- Alex Meade
- Jay Pipes
- Everett Toews
- Dean Troyer
- Salvatore Orlando
- Lance Bragstad
- Anne Gentle
- Ian Cordasco
- Zhipeng Huang
- Ed Leafe
- Maty Grosz
- Eli Qiao
- Alex Xu
- Chris Dent
- Constanze Kratel
- Sam Harwell
- Ghanshyam Mann
- Lisa Clark
- Kevin Mitchell
- Shaunak Kashyap
- Ken'ichi Ohmichi
- David Stanek
- Michael McCune
- Dolph Mathews
- Eric Nielsen
- Brian Rosmaita
- Zack Shoylev
- Miguel Grinberg
- Graham Hayes
- Christopher Lefelhocz
- Lucas Alvares Gomes
- Jason Zhang
- Steve Lewis
- Steven Kaufer
- Ryan Brown
- Adrian Otto
- Maish Saidel-Keesing
- Eoghan Glynn
- Matthew Gilliard
- Eric Chiu
- Park Hei
- Bruno Morel
- Eric Nielsen
- John Stanford
- Mark McClain
- Christopher Armstrong
- Michael Krotscheck
- SHIGEMATSU Mitsuhiro
- Apoorva Deshpande