d-bis/smoa
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5a8c26cf5d541e5d3a315f6859de4874ab300ee5
smoa/backend/docs/API-VERSIONING.md
defiQUG 5a8c26cf5d Backend, sync, infra, docs: ETag, API versioning, k8s, web scaffold, Android 16, domain stubs 
- 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>
2026-02-10 20:37:01 -08:00

753 B
Raw Blame History

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.
Reference in New Issue View Git Blame Copy Permalink