Skip to main content

OpenAPI Management Guidelines

This document provides conventions and best practices for managing OpenAPI specifications in the ProvLabs documentation system.

Architecture Overview

File Flow

  1. Proto files in git submodules (extsource/provenance/, extsource/cosmossdk/)
  2. Generated OpenAPI files in temporary locations
  3. Unified specifications in config/ directory
  4. Split specifications in openapi/ directory (not committed)
  5. Served by Redocusaurus plugin at /api and /node routes

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.yaml for 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-tagGroups for 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

  1. Missing schemas: Check base schema references and cleanup functions
  2. Build failures: Verify all required tools are installed and accessible
  3. Broken references: Validate file paths and schema locations
  4. Submodule issues: Ensure proper sparse checkout configuration

Debugging Process

  1. Run scripts individually to isolate issues
  2. Check intermediate file generation
  3. Validate OpenAPI specifications with online tools
  4. 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