GSoC 2025: JSON Schema-based API Mocking Tool

[ramishj]

Brief Description:

This project aims to develop a tool that generates mock API endpoints based on JSON Schema definitions, enabling frontend developers and testers to work without needing a live backend. The tool will support both REST and GraphQL APIs, allowing users to customize mock responses, simulate error conditions, and configure dynamic data generation. The tool will feature a CLI and a web UI for easy configuration and real-time testing, with integration options for Postman and OpenAPI.

---

Expected Outcomes:

• A functional mock API generator supporting REST and GraphQL.
• Customization options for mock responses, including random data generation and error handling.
• A user-friendly web UI for managing mock APIs.
• A CLI tool for developers to integrate with their workflows.
• Integration with Postman and OpenAPI for seamless testing and validation.
• A comprehensive test suite and clear documentation.

---

Skills Required:

• Node.js & Express.js for building the mock API server.
• JSON Schema for parsing and validating schema definitions.
• GraphQL for building mock GraphQL APIs.
• TypeScript for maintainability and type safety.
• React (optional) for building the web UI.
• Cypress for test automation.
• Postman and OpenAPI for integration.

---

Mentors:

TBD

---

Expected Difficulty:

Medium-Hard

---

Expected Time Commitment:

300 hours

[ramishj]

Hi there!

I'm Ramish, and I contributed to the JSON Schema community with my first merged PR last year: #758: Added Workflow to Verify ambassador.json Schema. I'm excited to continue contributing and learning through GSoC 2025. If there are any current efforts where I can assist or collaborate, I’d love to help!

Looking forward to connecting!

Best,
Ramish

[jviotti]

Hi @ramishj ,

Great idea! I've been looking at the API mocking space for a while. What would this tool do differently than available competitors such as. https://stoplight.io/open-source/prism or https://www.wiremock.io? Are you aware of any weaknesses on current implementations? If so, can you elaborate on them in the proposal?

[ramishj]

Hi @ramishj ,

Great idea! I've been looking at the API mocking space for a while. What would this tool do differently than available competitors such as. https://stoplight.io/open-source/prism or https://www.wiremock.io? Are you aware of any weaknesses on current implementations? If so, can you elaborate on them in the proposal?

Hey @jviotti ,

Great question! I’ve looked into tools like Prism and WireMock, and while they’re solid, there are a few areas where I think things could be better:

More flexible schema-driven responses – A lot of existing tools require manual setup for mocks. I want this to auto-generate responses based on JSON Schema but still give users control over tweaking responses dynamically.
Better GraphQL support – Prism supports GraphQL, but it’s pretty basic. I want to make query-aware mocking easier, so responses change based on variables and query structure.
Realistic error simulation – Stuff like rate limiting, timeouts, auth failures—these are super important for testing but not always easy to set up in current tools.
CLI + UI combo – Some tools are either CLI-based or UI-based, but not both. I think having a solid CLI for dev workflows and a UI for quick testing would be really useful.
Smoother Postman/OpenAPI integration – Right now, there’s often friction in converting API definitions between tools. I want to make that process as seamless as possible.
Curious to hear your thoughts! Are there any pain points you've run into with other mock API tools?

[jdesrosiers]

A few things about this proposal aren't making sense to me yet.

This project aims to develop a tool that generates mock API endpoints based on JSON Schema definitions

JSON Schema isn't an API definition language. It doesn't define endpoints. So, I'm not sure how you expect to generate mock API endpoints just from schemas. JSON Schema can define resources (requests and responses), but you would need something else (like OpenAPI) to define the endpoints. What do you have in mind here?

The tool will support both REST and GraphQL APIs

JSON Schema and GraphQL aren't really compatible. GraphQL has its own schema language. Would you be converting JSON Schemas to GraphQL schemas? That sounds like a project in itself.

with integration options for Postman and OpenAPI.

What does it mean to integrate with Postman and OpenAPI?

[ramishj]

Hi @jdesrosiers

I see your point about JSON Schema not being an API definition language, and you're right—JSON Schema by itself doesn't define API endpoints. But here's how I think the tool can work, with some examples to clarify:

Generating Mock API Endpoints from JSON Schema

The tool would use OpenAPI to define the endpoints and JSON Schema to define the request and response bodies. Here's an example:

Example of OpenAPI + JSON Schema for a REST API

openapi: 3.0.0
info:
  title: Mock API
  version: 1.0.0
paths:
  /users:
    get:
      summary: Get a list of users
      responses:
        200:
          description: A list of users
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/UserList'

components:
  schemas:
    UserList:
      type: array
      items:
        $ref: '#/components/schemas/User'

    User:
      type: object
      properties:
        id:
          type: integer
        name:
          type: string
        email:
          type: string

In this case, OpenAPI defines the /users endpoint, and JSON Schema defines the structure of the User and UserList resources.

Example of Mocking a Response

The tool could mock this API and return a response like:

[
  {
    "id": 1,
    "name": "John Doe",
    "email": "john.doe@example.com"
  },
  {
    "id": 2,
    "name": "Jane Smith",
    "email": "jane.smith@example.com"
  }
]

Supporting Both REST and GraphQL

For REST APIs, the tool would work with OpenAPI specs and JSON Schema for data definitions.

For GraphQL, it would generate a mock GraphQL API using GraphQL's schema language, like this:

Example of a Mock GraphQL Schema

type User {
  id: ID!
  name: String!
  email: String!
}

type Query {
  users: [User!]!
}

schema {
  query: Query
}

The tool would allow you to define mock data for GraphQL queries. For instance, a query like:

query {
  users {
    id
    name
    email
  }
}

Could return the following mock data:

{
  "data": {
    "users": [
      {
        "id": "1",
        "name": "John Doe",
        "email": "john.doe@example.com"
      },
      {
        "id": "2",
        "name": "Jane Smith",
        "email": "jane.smith@example.com"
      }
    ]
  }
}

Integration with Postman and OpenAPI

1. Postman Integration: The tool could generate Postman collections based on the mock API definitions. For example, you could automatically generate a collection with requests for the /users endpoint, which would allow testers to quickly validate the mock responses.

   Example of a Postman collection for the /users endpoint:

   {
     "info": {
       "name": "Mock API",
       "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
     },
     "item": [
       {
         "name": "Get Users",
         "request": {
           "method": "GET",
           "url": "http://mockapi.com/users"
         },
         "response": [
           {
             "code": 200,
             "body": "[{ \"id\": 1, \"name\": \"John Doe\", \"email\": \"john.doe@example.com\" }]"
           }
         ]
       }
     ]
   }

2. OpenAPI Integration: The tool could generate an OpenAPI spec (like the one above) for your mock API, which can then be used in other tools for validation and auto-generating documentation. For example, this OpenAPI spec can be used with Swagger UI to create interactive API documentation.

---

Let me know if this helps! This approach should allow for both REST and GraphQL support, and the integrations with Postman and OpenAPI will ensure the tool is useful for testing and validation.

I would love to know your thoughts and suggestions , and would love if you suggest improvements/corrections for the proposal.

Thanks

[ramishj]

@jviotti

Feature	myTool	WireMock
Data Generation	Dynamically generates random mock data based on JSON Schema.	Uses static predefined responses.
Data Customization	Highly customizable using constraints in JSON Schema (e.g., minimum, maximum values, formats).	No native support for randomization or constraints. Manual data updates required.
API Support	Supports both REST and GraphQL APIs.	Primarily supports REST APIs. No native support for GraphQL.
Schema Validation	Automatically validates mock responses against JSON Schema.	No built-in validation against a schema. Responses must be manually defined.
Response Structure	Responses are automatically generated to match the schema.	Responses are manually defined and static.
Dynamic Data	Generates dynamic values based on schema definitions (e.g., random strings, integers).	Requires manual effort or response templating to simulate dynamic data.
Error Handling	Can easily simulate different error conditions based on schema (e.g., invalid data types).	Error handling can be simulated but requires manual configuration of responses.
GraphQL Support	Fully supports GraphQL with dynamic responses based on GraphQL schema.	No native support for GraphQL. Requires manual response configuration for GraphQL queries.
User Interface	Can provide a web UI for managing mock APIs, with real-time data generation.	Typically managed via configuration files, no integrated UI for response management.
Integration	Supports integration with Postman and OpenAPI for easy testing.	Has basic integration features but focuses mainly on REST API mocking.
Data Consistency	Ensures mock data consistently matches the schema definition.	No data consistency validation, responses are static unless manually adjusted.

Summary:

• myTool provides dynamic and schema-driven mock APIs, supporting both REST and GraphQL, with automatic response generation and validation based on JSON Schema.
• WireMock is more suited for static mock responses for REST APIs, and requires manual configuration for dynamic data or GraphQL support.

The Aim here is to generate mock data , make that generation more configurable wireMock currently doesn't generate it may randomize things , but doesn't exactly generate.

In summary, WireMock's templating requires you to manually define each mock response, including dynamic values like random numbers or strings, which can become tedious for large projects. For example, you would explicitly code a response like:

{
  "id": "{{randomValue type='int' min='1' max='100'}}",
  "name": "John Doe"
}

In contrast, myTool uses JSON Schema to automatically generate mock responses based on predefined structures, making it more scalable and less error-prone. With myTool, you'd define a schema once like this:

{
  "type": "object",
  "properties": {
    "id": { "type": "integer", "minimum": 1, "maximum": 100 },
    "name": { "type": "string" }
  },
  "required": ["id", "name"]
}

And myTool would automatically generate a mock response such as:

{
  "id": 42,
  "name": "Jane Doe"
}

This makes myTool faster to set up and easier to scale, especially with complex data structures.

🔥 Why This Hasn’t Been Fully Done Before

1. Most tools require manual response configuration – myTool automates this using JSON Schema.
2. Most mock tools don’t support both REST & GraphQL seamlessly – myTool does.
3. Prism validates OpenAPI but doesn’t dynamically generate data – myTool combines both.
4. WireMock uses templates, which require effort to define – myTool auto-generates data based on structure.

💡 Real-World Example

Let’s say you define a simple JSON Schema:

{
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "name": { "type": "string" },
    "email": { "type": "string", "format": "email" }
  }
}

• WireMock/Mockoon: You must manually define response JSON or use a template.
• Prism: It validates this against OpenAPI but doesn’t auto-generate varied data.
• myTool: Automatically generates structured mock data:

{
  "id": 42,
  "name": "John Doe",
  "email": "johndoe@example.com"
}

It can randomize values or keep them deterministic based on schema constraints.

---

⚡ Summary

Existing tools either focus on static mocking or validation but don’t fully automate dynamic API mocking with schema-driven validation. myTool fills this gap, making API development and testing faster, smarter, and more scalable.

[ramishj]

JSON Schema and GraphQL aren't really compatible. GraphQL has its own schema language. Would you be converting JSON Schemas to GraphQL schemas? That sounds like a project in itself.

Yeah Its ,just a plan ,we can explore and try.

[ramishj]

JSON Schema isn't an API definition language. It doesn't define endpoints. So, I'm not sure how you expect to generate mock API endpoints just from schemas. JSON Schema can define resources (requests and responses), but you would need something else (like OpenAPI) to define the endpoints. What do you have in mind here?

JSON Schema over here is being used to define and validate mock being generated.

[jdesrosiers]

The tool would use OpenAPI to define the endpoints and JSON Schema to define the request and response bodies.

Ok, that makes sense now, but there are already several tools out there that generate mock API servers from Open API definitions. As @jviotti has pointed out, it's not clear to me how this would be different.

Prism validates OpenAPI but doesn’t dynamically generate data

Although it's not its default mode, Prism does generate random data based on schemas in the Open API description. https://docs.stoplight.io/docs/prism/9528b5a8272c0-dynamic-response-generation-with-faker

The tool could generate Postman collections based on the mock API definitions.

Postman already has support for converting an OpenAPI definition into a Postman collection. If you're starting with an OpenAPI definition already, I don't think there's anything this tool needs to do.

The tool could generate an OpenAPI spec (like the one above) for your mock API

You said that the input would be an OpenAPI description. No need to generate an Open API description if we already had one to start with.

For GraphQL, it would generate a mock GraphQL API using GraphQL's schema language

So, it wouldn't have anything to do with JSON Schema. I don't know the GraphQL ecosystem, but a quick search seem to indicate that there are already that have this mock server feature based on GraphQL schemas.

Most mock tools don’t support both REST & GraphQL seamlessly

It seems to me that the mock server case is handled pretty well for both OpenAPI and GraphQL, so the only thing (that might be) unique from this proposal is that it does both. I don't think that's useful unless there's something that ties the two together such as being able to define an API once and then generate both a mock HTTP API and a mock GraphQL API from that definition. For example, your tool could take an Open API description and convert it into a GraphQL schema thus being able to support HTTP APIs and GraphQL APIs using one definition.

Personally, I think the domain of mock server generation is already well served. I'm not sure this is needed. What might be more interesting is to look at some of the components related to this and see if there are opportunities for improvements. For example, Prism uses json-schema-faker. It would be interesting to understand what that tool does well and what it doesn't do well and work on either a replacement or enhancement to that tooling to improve its weaknesses. There was an academic paper published a couple years ago that could inform writing a better implementation. Or, you could write a JSON Schema Faker in a language were there isn't one already.