spike/feat: minimal low-ceremony JSON frontend for integrators without a spec
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
First confirm specific integrator feedback showing that users without an OpenAPI spec are blocked; this issue is explicitly demand-gated. Then inspect MockConfigRepository and the existing ApiSpec, Operation, and MockResponse seam. Done means the new minimal parser feeds those same objects, documents its deliberate limits, and introduces no new types downstream.
Written by the indexing model from the issue text.
Description
Part of #72
Depends on #73 (the pure-seam design constraint is what makes this cheap to add). Explicitly demand-gated — do not pick this up speculatively.
Summary
A second, deliberately tiny, low-ceremony JSON input format for integrators who don't have (and don't want to hand-author) an OpenAPI spec, feeding the exact same internal model (ApiSpec, Operation, MockResponse) that the OpenAPI parser produces. This issue should only be picked up if real 0.2.0 adoption feedback shows integrators without an existing spec are actually blocked or frustrated by needing to write OpenAPI for a handful of endpoints — it is tracked here so the option is deliberately visible, not because it's scheduled.
Why this is safe to leave open rather than decide now
This came out of a design discussion (see epic #72's linked review) about whether 0.2.0 should ship two input formats from day one. The conclusion was no — nobody is currently blocked, and every config-expressible feature (delay via #A, failure-rate via #B, sequences via #C) would otherwise need to be designed against two schemas from day one, regardless of whether they compile to the same objects. But the objection had a real point worth preserving: DevView's architecture already makes a second frontend cheap to add later, because #73 requires MockConfigRepository to be a pure RawBytes -> ApiSpec function with no OpenAPI-specific type leaking downstream. Adding a second implementation of that same function signature is additive, not a rearchitecture — so there's no cost to deciding against building it now, only to building it prematurely.
What this explicitly is not
Not the old mocks.json restored as-is — that format carried the environment axis (EnvironmentConfig, endpointOverrides, additionalEndpoints) and the probe-based response discovery, both of which this migration removes for good reasons unrelated to the format question (see #74, #76). Reviving that shape would reintroduce exactly the complexity this epic exists to remove.
What to build, if and when this is picked up
- A fresh, deliberately minimal schema: just enough to describe a handful of operations without any formal API-spec ceremony — id/path/method/name per operation, inline example response bodies (no separate response-file tree required, though one could still be supported for larger inline bodies).
- No groups-as-environments, no override/merge mechanism — if an integrator's needs grow past what this minimal format comfortably expresses, the answer is "write OpenAPI," not "extend this format to match OpenAPI's feature set." Keeping this format deliberately less capable than OpenAPI is what keeps it cheap to maintain.
- The parser for this format produces the exact same
ApiSpec/Operation/MockResponseobjects the OpenAPI parser does — reuseMockConfigRepository's existing seam, don't build a parallel engine. - If #D's build-time codegen spike has landed and been adopted by the time this is picked up, this frontend should feed the same build-time pipeline rather than becoming a second on-device runtime parser — but that's an implementation detail to settle at pickup time, not now.
Acceptance criteria (to refine when actually scoped)
- Before starting implementation: confirm the demand signal that justifies building this (cite specific integrator feedback, not a hypothetical).
- The new format's parser produces
ApiSpec/Operation/MockResponse— no new types leak intodevview-networkmockordevview-networkmock-ktor. - The new format is deliberately incapable of things OpenAPI can express that it chooses not to support (documented explicitly, not accidentally missing).
Files likely touched
TBD — deferred until picked up.
- Dominant language
- Kotlin
- Stars
- 10
- Forks
- 2
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 13
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from worldline/devview
-
enhancement good first issue stale
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 45/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
All issues in worldline/devview
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
index-request triaged
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Anthonyy232/Paperize#614 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
bitcoindevkit/bdk-ffi#1125 ·
-
🌑 nextgen
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
CCBlueX/LiquidBounce#9214 · 1 comment ·