OpenAPITools / OpenAPITools/openapi-generator
[REQ][Kotlin] Fake mock library on OpenAPI examples
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
Many Kotlin/mobile developers need to work with APIs without depending on a running backend. Currently, offline development or mock flavors require either:
- Maintaining large amounts of hand-written or recorded JSON mock data
- Writing custom fake clients by hand
This is time-consuming, error-prone, and difficult to maintain when the API changes.
Describe the solution you'd like
I propose adding a new Kotlin client library type:
--library=fake
This would generate:
- Standard models (unchanged)
- Standard API interfaces (unchanged)
- Fake API implementations (
FakeApi) for each API interface
Each fake API method would return data derived from the OpenAPI specification:
- Example fields, if present
- Default values, if present
- Schema-derived fake data as fallback (strings, numbers, enums, nested objects, arrays)
This approach produces a fully on-device mock client, with no server, Docker, or Node process required.
Describe alternatives you've considered
-
WireMock / MockWebServer / Prism / Mockoon
- Requires running an embedded server or Node process
- Not practical for Android mock flavors
- Harder to keep in sync with API changes
-
Manually creating fake clients per API
- High maintenance burden
- Error-prone and repetitive
- Difficult to scale for large APIs
Additional context
Contributor guide
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.
Research direction
Start by tracing Kotlin client generation and the existing --library options, then compare how API interfaces and models are produced. Define the fake library's behavior for examples, defaults, and schema-derived values, and verify that each API gets a usable FakeApi implementation without a server or external process.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- api, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100