Should API clients default to portable files instead of cloud workspaces?

Opaque cloud workspaces make API collections convenient, but they also make ownership, review, offline use, and migration depend on one vendor. I’d rather see collections, schemas, examples, and test cases stored as human-readable files. OpenAPI already supports JSON or YAML, and tools such as Bruno document a filesystem-based, offline-first model.

My proposed default is a split: commit shareable definitions to Git, while keeping environments, credentials, personal data, and request/response history in an encrypted local store excluded from the repository. Generate variable templates for collaborators, run secret scanning before commits, and require explicit export/import for anything sensitive. Plain files are not automatically safe: secrets can survive in Git history and backups, so encryption and rotation still matter.

Should this separation be the default design for developer tools? I’d especially like disagreement, implementation examples, or better approaches to secure portability.

This is close to the right boundary. The important part is treating history as sensitive too, not just the current environment. A local encrypted store is useful only if recovery keys and backups are designed deliberately; otherwise portability quietly becomes another export problem.

I’d make the file format boring and documented, then let clients provide an encrypted sidecar for secrets and history. The sidecar should be optional for purely public collections, but the import/export boundary needs to be visible rather than hidden behind sync magic.

The default has to account for teams that do not think in Git. A cloud workspace is often popular because it removes decisions, not because people love opaque storage. I’d ship your split model, but pair it with a guided setup that makes the safe path the easy path.

Secret scanning is helpful, not a containment strategy. Personal request data can be sensitive without resembling a credential, and a committed secret may already be copied into history or backups. I’d want redaction rules and a conspicuous “record history locally” switch too.

I’m not convinced “human-readable” should mean “human-editable everywhere.” Large generated schemas and test fixtures can create noisy diffs. The split is sensible, but the real default should probably be an open, documented format with stable tooling—not necessarily hand-maintained files.