Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to match request body against JSON schema #2

Open
x80486 opened this issue Oct 12, 2020 · 6 comments
Open

Provide a way to match request body against JSON schema #2

x80486 opened this issue Oct 12, 2020 · 6 comments
Labels
new feature New feature or request

Comments

@x80486
Copy link

x80486 commented Oct 12, 2020

I've read the Body Matching section. I'm aware something similar can be achieved by using JSONPath, but the outcome won't be the same. Moreover, teams already employ JSON schemas or Open API definitions to check end-point contracts — so that's a time saver.

I think it would be great is API Simulator could validate a given request body against a corresponding JSON schema. For instance, MockServer does something similar:

...
  "body": {
    "type": "JSON_SCHEMA",
    "jsonSchema": "schemas/create-entity.schema.json"
  },
...
@apisim apisim added the enhancement Enhancement to existing feature label Oct 29, 2020
@apisim
Copy link
Member

apisim commented Oct 29, 2020

Hi @x80486

This isn't currently supported. Labeled it as an "enhacement".
Thanks!

@apisim
Copy link
Member

apisim commented Nov 1, 2020

Just to make sure I understand

validate a given request body against a corresponding JSON schema

in the context of simulating an API with API Simulator:
API Simulator validating the body of an HTTP request against a given JSON Schema is as part of matching incoming requests to determine which response to return.

Is this what the feature is about?

@x80486
Copy link
Author

x80486 commented Nov 1, 2020

Yes, basically, when we model a POST operation, we usually want to make sure certain fields are there, if not, we respond accordingly. A JSON schema validates that be body sent is valid according to the schema applied to the simulation.

If you take a look at what MockServer does I think it would be easier — but it's more to match than actually validate.

@apisim
Copy link
Member

apisim commented Nov 1, 2020

Got it, thanks.

In the meantime, if you haven't already, you can check out the support for Multiple Responses in API Simulator and especially the example that demonstrates an approach to returning different responses based on the validity of input elements.

@apisim apisim added new feature New feature or request and removed enhancement Enhancement to existing feature labels Oct 8, 2021
@x80486
Copy link
Author

x80486 commented Jun 11, 2024

Another approach on solving this problem could be by supporting RAML data type definitions. It makes it interesting because one can make sure the input data is actually structured in the expected form.

Something like this:

#%RAML 1.0 DataType

type: object
properties:
  employee_id: 
    type: integer
    required: true
    minimum: 8
  first_name: 
    type: string
    required: true
    minLength: 1
    maxLength: 10
    pattern: ^[A-Za-z]*
  last_name: 
    type: string
    required: true
    minLength: 1
    maxLength: 10
    pattern: ^[A-Za-z]*
  email:
    pattern: ^.+@.+\..+$
  ...

Perhaps a new DSL key to allow a reference to a file with the RAML data type definitions for a given operation. Maybe the DSL is only available for those HTTP operations that can send payloads: POST, PUT, etc.

@apisim
Copy link
Member

apisim commented Jun 13, 2024

Thank you for the suggestion, @x80486!

RAML... That takes me years back. If I recall, there were some good features at the time compared to Swagger but RAML never gained traction outside of the ecosystem of the company behind it. I may be wrong, though...

Frankly, I think supporting JSON schema validation will have larger applicability than RAML.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants