OpenAPI Migration Plan for VibeTunnel
Overview
This document outlines the plan to adopt OpenAPI 3.1 for VibeTunnel’s REST API to achieve type safety and consistency between the TypeScript server and Swift clients.Goals
- Single source of truth - Define API contracts once in OpenAPI spec
- Type safety - Generate TypeScript and Swift types from the spec
- Eliminate inconsistencies - Fix type mismatches between platforms
- API documentation - Auto-generate API docs from the spec
- Gradual adoption - Migrate endpoint by endpoint without breaking changes
Current Issues
- Session types differ completely between Mac app and server
- Git repository types have different field names and optional/required mismatches
- No standardized error response format
- Manual type definitions duplicated across platforms
- Runtime parsing errors due to type mismatches
Implementation Plan
Phase 1: Setup and Infrastructure (Week 1)
1.1 Install Dependencies
1.2 Create Initial OpenAPI Spec
Createweb/openapi/openapi.yaml
:
1.3 Setup Code Generation
TypeScript Generation (web/package.json
):
- Add
swift-openapi-generator
to Package.swift - Add build phase to run before compilation:
1.4 Create Shared Components
Define reusable schemas inweb/openapi/components/
:
Phase 2: Migrate Git Endpoints (Week 2)
Start with Git endpoints as they’re well-defined and isolated.2.1 Define Git Schemas
2.2 Update Server Implementation
2.3 Update Mac Client
Phase 3: Migrate Session Endpoints (Week 3)
Session endpoints are more complex due to WebSocket integration.3.1 Standardize Session Types
3.2 Create Session Operations
Phase 4: Runtime Validation (Week 4)
4.1 Add Request Validation Middleware
4.2 Add Response Validation in Development
Phase 5: Documentation and Testing (Week 5)
5.1 Generate API Documentation
5.2 Add Contract Tests
Migration Checklist
Endpoints to Migrate
-
Git APIs (Phase 2)
- GET /api/git/repo-info
- GET /api/git/repository-info
- GET /api/git/remote
- GET /api/git/status
- POST /api/git/event
- GET /api/git/follow
-
Session APIs (Phase 3)
- GET /api/sessions
- POST /api/sessions
- GET /api/sessions/:id
- DELETE /api/sessions/:id
- POST /api/sessions/:id/resize
- POST /api/sessions/:id/input
- GET /api/sessions/:id/stream (SSE)
-
Repository APIs (Phase 4)
- GET /api/repositories/discover
- GET /api/repositories/branches
-
Worktree APIs (Phase 4)
- GET /api/worktrees
- POST /api/worktrees
- DELETE /api/worktrees/:branch
- POST /api/worktrees/switch
Success Metrics
- Zero runtime type errors between Mac app and server
- 100% API documentation coverage
- Contract tests for all endpoints
- Reduced code - Remove manual type definitions
- Developer velocity - Faster API development with code generation
Long-term Considerations
Future Enhancements
- GraphQL Gateway - Add GraphQL layer on top of REST for complex queries
- API Versioning - Use OpenAPI to manage v1/v2 migrations
- Client SDKs - Generate SDKs for other platforms (iOS, CLI tools)
- Mock Server - Use OpenAPI spec to run mock server for testing
Breaking Changes
When making breaking changes:- Version the API (e.g., /api/v2/)
- Deprecate old endpoints with sunset dates
- Generate migration guides from schema differences