Jump to: navigation, search

Difference between revisions of "Blueprint-os-api-docs"

(BLUEPRINT: OpenStack project API Reference/s (specs) (remove from docs landing page but keep repositories))
(BLUEPRINT: API Reference/s (specs) (remove from docs landing page but keep repositories))
Line 171: Line 171:
 
<br />
 
<br />
  
== BLUEPRINT: API Reference/s (specs) (remove from docs landing page but keep repositories) ==
+
== BLUEPRINT: API Reference/s (specs) (keep repos but remove from docs.o.o) ==
  
 
'''Strategy'''
 
'''Strategy'''

Revision as of 15:29, 25 October 2013

Overview

This blueprint describes a plan to create documentation for OpenStack application developers and contributors in the Icehouse release.

In addition to providing documentation to experienced developers, this documentation will also describe the next step for end users who know how to use the dashboard and client commands to interact with an OpenStack cloud and who want to progress to using the APIs directly or indirectly through cURL commands or open SDKs.

History

Since mid-2012, the OpenStack API docs and dev teams have produced the following API docs:

  • A series of API specifications. Development uses these documents to record design decisions as they develop the OpenStack APIs. These documents reflect work-in-progress APIs rather than fully implemented APIs. These documents are maintained by both dev and doc teams, and are published at: http://docs.openstack.org/api/api-ref-guides.html. However, because we lack API guidance information and because we publish the API specifications on the docs.openstack.org page, OpenStack users mistake these specs for official API references and guides (when they are not). These documents are sourced from XML and WADL files and reside in the following repositories:

Issues

Anne Gentle captured the main issue that this blueprint seeks to address, and proposed some solutions in an email.

To reiterate, this is the main issue:

''However, because we lack API guidance information and because we publish the API specifications on the docs.openstack.org page, OpenStack users mistake these specs for official API references and guides (when they are not). ''

Though we started down Anne's recommended path, this blueprint proposes changes that will address the missing portion of Anne's suggestions:

...we'd start new "developer guides" in the openstack-manuals repository that document reality. We can track the work needed through the openstack-manuals bug and blueprint system.

The proposed changes in this blueprint seek to address these issues:

  1. We lack an OpenStack developer guide. Because the APIs are always new to someone, we need a book that is a companion to the API reference pages that walks new users through API concepts and usage.
  2. Currently two versions of any given project's WADL exist - one in the openstack/api-site repository, and one in the openstack/project-api repository. Generally, these versions are not in sync.
  3. Some API documentation is not sourced from WADLs, even if a WADL (or WADLs) exist.
  4. Due to #2 and #3, any given API method can have up to three versions of its documentation.
  5. Having multiple API versions and doc locations confuses developers, writers, and OpenStack developers, and application developers.
  6. These problems create unnecessary work for writers and developers.


Suggested solutions

In the Icehouse release, we plan to address these issues as follows:

http://api.openstack.org/api-ref.html:

  • Continue to provide one API reference page for each implemented OpenStack API. Audience: application developers.

http://docs.openstack.org/:

  • Add a new API guide that captures and adds to the existing guidance information in the specs. Audience: application developers.
  • Remove the API specs from this page, but keep the source repositories for the API specs in place for development. The docs team will no longer maintain, build, or publish these docs. These documents describe the work-in-progress APIs. Audience: OpenStack API developers. For a list of these documents and their repositories, see Blueprint-os-api-docs#History.

Benefits of proposed changes

The proposed changes will provide the following benefits:

  1. Reduce API documentation redundancy.
  2. Eliminate duplication of effort by writers for API reference and guidance documentation.
  3. Keep the documentation for work-in-progress APIs separate from the documentation for implemented APIs.
  4. Make it clear to end users where the documentation for the implemented OpenStack APIs resides.
  5. Make it clear to OpenStack developers where the documentation for work-in-progress APIs resides.

Docs Summary

Document Change Audience Purpose
OpenStack API Guide New Application developers Introduce developers to API concepts, common tasks, and ways of interacting with the OpenStack APIs. Provide guidance for developers who want to extend the OpenStack APIs or write applications that run on an OpenStack cloud.
OpenStack API Complete Reference web pages Revised Application developers Provide developers with searchable and comprehensive Web pages that list API methods and parameters, with examples for each. Before deleting the API References, pull reference material from them into WADL files. Use the enhanced WADL files to source the API Complete Reference pages. One web page for each OpenStack project. Source code samples from nova code base where possible.
OpenStack API References (specs) Remove from docs landing page but keep repositories OpenStack developers Remove the existing API References from the docs.openstack.org site:
  • Block Storage Service API v2 Reference
  • Compute API v2 and Extensions Reference
  • Identity Service API v2.0 Reference
  • Networking API v2.0 Reference
  • Image Service API v2 Reference
  • Image Service API v1 Reference
  • Object Storage API v1 Reference


BLUEPRINT: API Guide (new)

Purpose

  • Introduce developers to API concepts, common tasks, and ways of interacting with the OpenStack APIs.
  • Provide guidance for developers who want to extend the OpenStack APIs or write applications that run on an OpenStack cloud.
  • From Anne Gentle: "We need what the Google Developer Support Handbook calls the Developers Guide: A conversational written guide to using the API. A developer’s guide is a walkthrough of how to use the API - it’s like how a teacher would explain the API to their students, but it’s penned down in digital ink (and there’s no talking back!). Some of those students will be new to the API, some will be new to web development entirely, and some will be old pros - the guide should work for all of them."
  • From Sam Harwell: A good rule of thumb is the OpenStack API Guide (item 4 of the blueprint) should not include any new information that cannot be derived from the API complete reference. In other words, you should be able to explain and justify every piece of information presented in the API Guide through a combination of specific information presented at various places throughout the API Complete Reference. Note that this does not detract from the importance of the API Guide; just because the information is available in the complete reference doesn’t mean users will be able to understand the detailed relations between the API calls at first read.


Source material

  • Python Developer Documentation
  • Language Bindings Documentation
  • Continuous Integration (CI) Developer Documentation
  • Programming OpenStack Compute API with Shell and Python
  • API Reference/s


CHAPTER: API Concepts

Cull material from existing API Reference/s. Also talk about how to access the APIs.

CHAPTER: How to Access the APIs

Note: The guide will provide guidance information for the API Complete Reference for a project. The API Complete Reference for a project will include access information in the form of listing the service type that should be used to locate the service endpoint(s) in the service catalog returned by Authenticate. It will also include information about text encodings, content types, and so on.

CHAPTER: Authentication

Cull material from existing API Reference/s. Provide working examples.

Note: In the API Complete Reference, the Identity Service Authenticate method will describe the authentication process. The summary/overview section of the API reference for a specific project can then mention that all calls for that project require the inclusion of an X-Auth-Token header, with a value obtained from the Authenticate method (linking back to the API complete reference for the identity project). Additional information in the API Guide, which is not directly expressed in the API Complete Reference, would be recommended client practices regarding re-authentication of expired tokens.

CHAPTER: Request/Response Types

Cull material from existing API Reference/s. Provide working examples.

CHAPTER: Links and References

Cull material from existing API Reference/s. Provide working examples.

CHAPTER: Paginated Collections

Cull material from existing API Reference/s. Provide working examples.

CHAPTER: Efficient Polling with the Changes-Since Parameter

Cull material from existing API Reference/s. Provide working examples.

CHAPTER: Limits

Cull material from existing API Reference/s. Provide working examples.

Note: The API Complete Reference will include information about return values indicating that an API call failed due to an artificial limit (e.g. quota or rate limit). Based on this information, clients can be written to perform well regardless of the actual limits that are in place. Additional information in the API Guide might include details about the limits in place for a specific vendor’s implementation of the product.

CHAPTER: Versions

Cull material from existing API Reference/s. Provide working examples.

CHAPTER: Extensions

Cull material from existing API Reference/s. Provide working examples.

CHAPTER 10: Faults

Cull material from existing API Reference/s. Provide working examples.

Note: All available information about faults for an API call should appear in the API Complete Reference for that call. This is covered in more detail under the Responses section of The JSON Checklist.

COMMON Glossary

BLUEPRINT: OpenStack API Complete Reference pages (revised)

Purpose

  • Provide developers with searchable and comprehensive Web pages that list API methods and parameters, with examples for each.
  • Provide one reference page for each project: Compute, Image Service, Identity Service, Object Storage, Networking, Orchestration, and Block Storage Service (already implemented). From Sam Harwell: My big concern is the size of the resulting complete reference page. If the entire API for a product is presented on a single page, it will not be friendly for mobile devices, or for hyper-linking users to information about specific calls as part of a community answer. In addition to the URI information and the examples, all of the information from the JSON/REST checklist is critical to the lasting value of the complete API reference.
  • Before deleting the API References, pull reference material from them into WADL files.
  • Source reference information for the API Reference pages from WADL files (already implemented, but WADL files will be updated with more information).
  • Review and improve the existing content so that it includes complete descriptions, request and response parameters, and tested code samples.
  • Use Sam Harwell's JSON/REST checklist to improve the documentation. In a separate effort, Sam Harwell and David Cramer plan to identify where each piece of information in the JSON/REST checklist fits in a WADL file. Then, David plans to enhance clouddocs-mvn-plugin so that it validates WADL files for comprehensiveness and pulls more information from WADL files for display.
  • Note: The API Guide will provide guidance information for the API Complete Reference for a project. The API Complete Reference for a project will include access information in the form of listing the service type that should be used to locate the service endpoint(s) in the service catalog returned by Authenticate. It will also include information about text encodings, content types, and so on.


Source materials

  • API Reference - sourced from WADL files
  • API Reference/s - Pull material from existing API Reference/s into WADL files so everything is single-sourced from WADL files.


BLUEPRINT: API Reference/s (specs) (keep repos but remove from docs.o.o)

Strategy

Remove these books from the docs.openstack.org site:

  • Block Storage Service API v2 Reference
  • Compute API v2 and Extensions Reference
  • Identity Service API v2.0 Reference
  • Networking API v2.0 Reference
  • Image Service API v2 Reference
  • Image Service API v1 Reference
  • Object Storage API v1 Reference
  • Programming Compute API with Shell and Python, 1st ed.


Move material from these books into the WADL files that source the API Complete Reference web pages.

Note

The existing source files would remain in place. The docs team would no longer be responsible for maintenance, builds, and publication of these docs. Development would determine where to publish this material.

Docs would ensure that application developers have usable API information on the API Reference page and in the (single) API Guide.

Also, any existing bookmarks to these books will redirect to http://api.openstack.org/api-ref.html.