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>
753 B
753 B
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:
- Add new controllers or paths under
/api/v2with the new contract. - Keep
/api/v1working for a documented deprecation period (e.g. 6–12 months). - Document in OpenAPI and in response headers, e.g.
X-API-Deprecated: true,Sunset: <date>. - Update clients (Android, iOS, Web) to use v2 before sunset; then remove v1.
- Add new controllers or paths under
- Non-breaking changes (new optional fields, new endpoints) do not require a new version; keep them in v1.