OpenAPI Management Guidelines
This document provides conventions and best practices for managing OpenAPI specifications in the ProvLabs documentation system.
Architecture Overview
File Flow
- Proto files in git submodules (
extsource/provenance/,extsource/cosmossdk/) - Generated OpenAPI files in temporary locations
- Unified specifications in
config/directory - Split specifications in
openapi/directory (not committed) - Served by Redocusaurus plugin at
/apiand/noderoutes
Directory Structure
config/
├── provenance.openapi.yaml # Unified API spec
├── noderpc.openapi.yaml # Node RPC spec
├── base.schema.json # Shared schemas
└── bv-apis.json # BlockVault APIs
openapi/ # Generated, not committed
├── openapi.yaml # Split main spec
├── noderpc.openapi.yaml # Node RPC copy
└── [various split files] # Individual API specs
Protocol Buffer Integration
Submodule Management
- Use sparse checkouts for proto directories only
- Pin to specific release branches (e.g.,
release/v1.23.x) - Keep submodules updated with supported API versions
- Document version compatibility in submodule README files
Code Generation
# Standard pattern for proto processing
proto_dirs=$(find ./cosmos -path -prune -o -name '*.proto' -print0 | xargs -0 -n1 dirname | sort | uniq)
for dir in $proto_dirs; do
query_file=$(find "${dir}" -maxdepth 1 \( -name 'query.proto' -o -name 'service.proto' \))
if [[ ! -z "$query_file" ]]; then
buf generate --template ../../openapiv3-template.yaml -o ../ "$query_file"
fi
done
Template Configuration
- Use
extsource/openapiv3-template.yamlfor consistent generation - Configure buf to generate only query and service definitions
- Exclude internal and deprecated APIs from generation
Schema Management
Base Schema Handling
- Centralize common schemas in
config/base.schema.json - Remove duplicate schemas to prevent conflicts during joins
- Update references to point to centralized location
Schema Cleanup Process
function removeBaseQuerySchemas() {
SVC_FILE=$1
# Remove duplicate schemas
jq "del( \
.components.schemas.\"cosmos.base.query.v1beta1.PageRequest\", \
.components.schemas.\"cosmos.base.query.v1beta1.PageResponse\", \
.components.schemas.\"cosmos.bank.v1beta1.Metadata\" \
)" "$SVC_FILE" > "$SVC_FILE.tmp"
mv "$SVC_FILE.tmp" "$SVC_FILE"
# Update references to point to base schema
sed -i '' -e "s|#/components/schemas/cosmos\.base\.query|../config/base.schema.json#/components/schemas/cosmos.base.query|g" "$SVC_FILE"
}
OpenAPI Specification Standards
Specification Structure
- Follow OpenAPI 3.0+ specification
- Include comprehensive operation descriptions
- Provide example request/response bodies
- Tag operations for logical grouping
Documentation Quality
- Write clear, concise operation summaries
- Include parameter descriptions and constraints
- Provide realistic example values
- Document error responses and status codes
Tagging Strategy
- Use consistent tag naming across services
- Group related operations under logical tags
- Apply tags for proper navigation in documentation
- Use
x-tagGroupsfor organizing tag display
Redocly Integration
Linting Standards
# Lint all specifications before joining
redocly lint $openapi_specs
- Configure Redocly rules in
redocly.yaml - Enforce consistent naming conventions
- Validate schema references and examples
- Check for breaking changes in API updates
Joining Specifications
# Join multiple specs into unified document
redocly join $openapi_specs --without-x-tag-groups -o config/provenance.openapi.yaml
Splitting for Documentation
# Split unified spec for granular documentation
npx @redocly/cli@latest split config/provenance.openapi.yaml --outDir "$OPENAPI_DIR"
Version Management
API Versioning
- Include version information in OpenAPI info block
- Use semantic versioning for API specifications
- Maintain backward compatibility when possible
- Document breaking changes clearly
Release Process
- Generate specifications from tagged submodule versions
- Test documentation generation with new specifications
- Validate all examples and references
- Update dependent documentation
Build Integration
Automated Generation
- Run generation scripts as part of
npm run prepare - Ensure idempotent script execution
- Clean up intermediate files after processing
- Fail builds on specification validation errors
Development Workflow
# Local development cycle
npm run prepare # Generate latest specs
npm start # Start dev server with hot reload
npm run build # Test production build
Quality Assurance
Testing Standards
- Validate generated specifications with Redocly
- Test documentation rendering in Redocusaurus
- Verify all internal references resolve correctly
- Check external API compatibility
Performance Considerations
- Monitor specification file sizes
- Optimize for fast documentation loading
- Consider splitting large specifications
- Use efficient reference patterns
Troubleshooting
Common Issues
- Missing schemas: Check base schema references and cleanup functions
- Build failures: Verify all required tools are installed and accessible
- Broken references: Validate file paths and schema locations
- Submodule issues: Ensure proper sparse checkout configuration
Debugging Process
- Run scripts individually to isolate issues
- Check intermediate file generation
- Validate OpenAPI specifications with online tools
- Test documentation rendering locally
Best Practices
Specification Design
- Keep operations focused and atomic
- Use consistent parameter naming
- Provide comprehensive error documentation
- Include security considerations
Maintenance
- Regular updates to submodule versions
- Periodic review of generated documentation
- Monitor for deprecated API features
- Update examples with current data patterns