This directory is the single source of truth for all API specifications in the AI Event Concepter project.
We follow an API-first approach to development:
- Design: All API changes start with updating the OpenAPI specification
- Review: API changes are reviewed by the team before implementation
- Generate: Code is generated from the OpenAPI specs
- Implement: Business logic is implemented using the generated code
/api
├── gateway.yaml # API Gateway specification
├── user-service.yaml # User Service specification
├── concept-service.yaml # Concept Service specification
├── genai-service.yaml # GenAI Service specification
├── scripts/ # Code generation scripts
└── README.md # This file
Install the required tools for linting and code generation:
# Install Redocly CLI for linting OpenAPI specs
npm install -g @redocly/cli@latest
# Install OpenAPI Generator tools
npm install -g @openapitools/openapi-generator-clinpm run lint:openapi./api/scripts/gen-all.shThis will generate:
- Java controllers and models for Spring Boot services
- Python client for the GenAI service
- TypeScript SDK for the web client
The code generation script places files in the following locations:
-
Java (Spring Boot):
- Gateway:
gateway/src/main/java/de/tum/aet/devops25/api/generated/ - User Service:
user-svc/src/main/java/de/tum/aet/devops25/api/generated/ - Concept Service:
concept-svc/src/main/java/de/tum/aet/devops25/api/generated/
- Gateway:
-
Python Client:
- GenAI Service:
genai-svc/client/
- GenAI Service:
-
TypeScript SDK:
- Web Client:
client/src/api/generated.ts
- Web Client:
The script supports generating code for specific languages:
# Generate only Java code
./api/scripts/gen-all.sh java
# Generate only Python client
./api/scripts/gen-all.sh python
# Generate only TypeScript SDK
./api/scripts/gen-all.sh typescriptRunning the script without arguments generates code for all languages.
All APIs are versioned in the URL path (e.g., /api/v1/resource). When making breaking changes:
- Create a new version in the URL path
- Update the OpenAPI spec to reflect the new version
- Generate new code for the new version
- Maintain backward compatibility for a reasonable period
- Always run the linter before committing changes
- Keep the OpenAPI specs DRY by using components and references
- Document all endpoints, parameters, and responses
- Include examples for request and response bodies
- Use consistent naming conventions across all APIs