Possible solution for nullable support

[jb0o]

Hi all,

Great package, definitely the best out there for the structure and data type validation I've needed, however theres one issue I currently have which I hope you could provide some guidance one. Its not your actual issue, but one I hope that I could be pointed in the right direction as to the possible solutions.

I'm currently using Redoc for my static documentation generator, which is great. However this uses the Open API spec, which as much may be similar to JSON Schema, does actually diverge, and I'm facing the exact same issue that is documented in this blog post: https://philsturgeon.uk/api/2018/03/30/openapi-and-json-schema-divergence/

Essentially, I have a number of nullable parameters and I need to be able to have them properly validated against and documented on.

Abiding by JSON Schema
When I have the following set;

"contact_email": {
      "type":["string","null"],
      "format": ""
}

this pleases the JSON schema fine, but spoils the rendering within the API docs. (its prints the datatype as stringnull and all example request fields show as a null value).

Abiding by Open API
When I have the following set;

"contact_email": {
      "type":"string",
      "nullable":true,
      "format": ""
}

this pleases the API docs, but rightfully breaks the JSON Schema validation when some of my responses go through, as the null value isn't adhered too, which is correct as per the JSON schema.

So I'm left with a number of options;

1. Move validator to Open API spec
   I've had a play about with some, and none of them seem to be any good.

2. Move docs
   Same as above but with the documentation rendering. If you know of any decent JSON Schema automated documentation, please let me know.

3. Fork JSON Schema project
   I could fork this project and add in support for an OpenAPI adapter to convert any of the given data into Open API spec

4. Pre-process the schema
   I could pre-process the schema to ensure all nullable entries are included as part of the type prop and not its own nullable prop.

I've probably answered my own question about with a number of answers so I'm keen to understand if anyone has experienced this and how they got around it.

Thanks all,

[erayd]

@jb0o I'm not overly familiar with OpenAPI, so this may not be applicable - but would moving the null type into an anyOf container be a suitable solution?

"contact_email": {
      "anyOf": [
            { "type": "string", "format": "" },
            { "type": "null" }
      ]
}

This ensures that the type declaration is a string, rather than an array, but preserves the behavior you are wanting. I'm not sure whether this is enough to satisfy OpenAPI's desire for a single type, but it's worth a shot.

If it is useful for documentation generation, you could also add nullable, as per the following:

"contact_email": {
      "nullable": true,
      "anyOf": [
            { "type": "string", "format": "" },
            { "type": "null" }
      ]
}

JSON Schema will simply ignore unknown keywords, so nullable will have no impact on validation behavior, but I assume that OpenAPI will still make use of it.

[erayd]

Further to the above - if you don't want to make manual changes to your schema, the transformation I suggested is trivial to carry out in a preprocessor, as it's just a simple rearrangement.

[DannyvdSluijs]

@jb0o in an attempt to cleanup this repo we are trying to filter the issues and see which ones might be closed. Is it safe to assume this is a rather old issue, which sadly was left unanswered, and can be closed? Feel free to close it yourself with some comments if helpful.