...
Also see: Developing ONAP API Documentation
Executive Summary - Improve ONAP API Documentation:
Developer Friendly
Non-Developer Friendly
Easy to Find & Easy to Navigate
Common and Uniform Documentation Structure and Approach
Provides Information on Using the API (e.g., quick start)
Try It For Yourself (TIFY) Examples
Proposed non-functional requirements for Guilin release:
All components should place externally facing (i.e. interfaces exposed by the ONAP component to either other ONAP components or components external to ONAP) API definitions (e.g. Swagger) in a common path within their Gerrit/Git
Suggested Path: <Component>/docs/api/swagger/
Apply ReDoc to Swagger and place HTML in Readthedocs for the release
Apply Minimum (Phase 1+) swagger guidelines
Use the common insert for the info section (e.g., license info, contact info, etc): Swagger Insert Sample for Info Section
Related JIRAs under the Documentation project for the API Documentation non-functional requirements:
...