5a8c26cf5d
- Backend: ShallowEtagHeaderFilter for /api/v1/*, API-VERSIONING.md, README (tenant, CORS, Flyway, ETag) - k8s: backend-deployment.yaml (Deployment, Service, Secret/ConfigMap) - Web: scaffold with directory pull, 304 handling, touch-friendly UI - Android 16: ANDROID-16-TARGET.md; BuildConfig STUN/signaling, SMOAApplication configures InfrastructureManager - Domain: CertificateManager revocation stub, ReportService signReports, ZeroTrust/ThreatDetection minimal docs - TODO.md and IMPLEMENTATION_STATUS.md updated; communications README for endpoint config Co-authored-by: Cursor <cursoragent@cursor.com>
11 lines
753 B
Markdown
11 lines
753 B
Markdown
# API versioning
|
||
|
||
- **Current:** All REST APIs are under **`/api/v1`** (sync, pull, delete, health, info).
|
||
- **When to introduce v2:** When you make **breaking changes** (e.g. remove or rename request/response fields, change semantics, or drop support for old clients).
|
||
- **How to add v2:**
|
||
1. Add new controllers or paths under **`/api/v2`** with the new contract.
|
||
2. Keep `/api/v1` working for a documented **deprecation period** (e.g. 6–12 months).
|
||
3. Document in OpenAPI and in response headers, e.g. `X-API-Deprecated: true`, `Sunset: <date>`.
|
||
4. Update clients (Android, iOS, Web) to use v2 before sunset; then remove v1.
|
||
- **Non-breaking changes** (new optional fields, new endpoints) do **not** require a new version; keep them in v1.
|