Design archive — not shipped
This page describes a future or historical network, API, P2P, or deployment surface. The current product is a local alpha; there is no working network transfer, hosted server, public API/SDK, or deployable service.
Design Archive
REST API Design Boundary
Questions a future hosted API would need to answer before an endpoint reference can exist.
Design, not a shipped service
The current product is a local alpha CLI and library. There is no hosted Dits service, complete repository remote, public API or SDK, managed webhook system, official server image, or supported production deployment. The items below are conditional design targets, not setup instructions or commitments.
Status
There is no Dits REST API, api.dits.io service, hosted repository service, bearer-token issuer, user directory, billing surface, or API availability commitment. Old endpoint examples were speculative and have been removed.
Possible design targets
- Versioned resources derived from the canonical repository object and ref semantics.
- Explicit authentication, authorization, tenant isolation, idempotency, pagination, and error contracts.
- Observable and rate-limited operations with documented consistency and failure behavior.
Prerequisites before implementation claims
- A real service operator, threat model, data-flow inventory, and reviewed security boundary.
- A complete remote CAS/ref protocol with safe transactions and recovery behavior.
- OpenAPI evidence generated from an implemented server and exercised by retained conformance tests.
What can be evaluated today
- Use the local CLI and library for offline repository evaluation.
- Treat dits serve as an unauthenticated object utility on trusted networks only, not as a REST API.
- Use local-filesystem clone for the current repository-copy workflow.