sample spec for testing openapi functionality, built from json schema tests for draft6
This Java package is automatically generated by the OpenAPI JSON Schema Generator project:
- API version: 0.0.1
- Package version:
- Build package: JavaClientGenerator
Java 17
If the python package is hosted on a repository, you can install directly using:
pip install git+https://github.com/GIT_USER_ID/GIT_REPO_ID.git(you may need to run pip with root permission: sudo pip install git+https://github.com/GIT_USER_ID/GIT_REPO_ID.git)
Then import the package:
import org.openapijsonschematoolsInstall via Setuptools.
python -m pip install . --user(or python -m pip install . to install the package for all users)
Then import the package:
import org.openapijsonschematoolsThis python code validates data to schema classes and return back an immutable instance containing the data which subclasses all validated schema classes. This ensure that
- valid data cannot be mutated and become invalid to a set of schemas
- the one exception is that files are not immutable, so schema instances storing/sending/receiving files are not immutable
Here is the mapping from json schema types to python subclassed types:
| Json Schema Type | Java Base Class |
|---|---|
| object | FrozenMap (HashMap) |
| array | FrozenList (ArrayList) |
| string | String |
| number | Number, float, double, int, long |
| integer | int, long |
| boolean | boolean |
| null | Void (null) |
| AnyType (unset) | Object |
In openapi v3.0.3 there are ~ 28 json schema keywords. Almost all of them can apply if type is unset. I have chosen to separate the storage of json schema definition info and output validated classes for payload instantiation.
Reason
This json schema data is stored in each class that is written for a schema, in a component or other openapi document location. This class is only responsible for storing schema info. Output classes like those that store dict payloads are written separately and are returned by the Schema.validate method when that method is passed in dict input. This prevents payload property access methods from colliding with json schema definition.
Most component schemas (models) are probably of type object. Which is a map data structure. Json schema allows string keys in this map, which means schema properties can have key names that are invalid python variable names. Names like:
- "hi-there"
- "1variable"
- "@now"
- " "
- "from"
To allow these use cases to work, schemas.immutabledict is used as the base class of type object schemas. This means that one can use normal dict methods on instances of these classes.
Other Details
- optional properties which were not set will not exist in the instance
- None is only allowed in as a value if type: "null" was included or nullable: true was set
- preserving the original key names is required to properly validate a payload to multiple json schemas
N schemas can be validated on the same payload. To allow multiple schemas to validate, the data must be stored using one base class whether or not a json schema format constraint exists in the schema. See the below accessors for string data:
- type string + format: See schemas.as_date, schemas.as_datetime, schemas.as_decimal, schemas.as_uuid
In json schema, type: number with no format validates both integers and floats, so int and float values are stored for type number.
String + Date Example
For example the string payload '2023-12-20' is validates to both of these schemas:
- string only
- type: string
- string and date format
- type: string
format: date
Because of use cases like this, a datetime.date is allowed as an input to this schema, but the data is stored as a string.
Please follow the installation procedure and then run the following:
| server_index | Class | Description |
|---|---|---|
| 0 | Model0 |
All URIs are relative to the selected server
- The server is selected by passing in server_info and server_index into api_configuration.ApiConfiguration
- Code samples in endpoints documents show how to do this
- server_index can also be passed in to endpoint calls, see endpoint documentation
| HTTP request | Method | Description |
|---|
If the OpenAPI document is large, imports in org.openapijsonschematools.apis.tags.tag_to_api and org.openapijsonschematools.components.schemass may fail with a RecursionError indicating the maximum recursion limit has been exceeded. In that case, there are a couple of solutions:
Solution 1: Use specific imports for apis and models like:
- tagged api:
from org.openapijsonschematools.apis.tags.default_api import DefaultApi - api for one path:
from org.openapijsonschematools.apis.paths.some_path import SomePath - api for one operation (path + verb):
from org.openapijsonschematools.paths.some_path.get import ApiForget - single model import:
from org.openapijsonschematools.components.schemas.pet import Pet
Solution 2: Before importing the package, adjust the maximum recursion limit as shown below:
import sys
sys.setrecursionlimit(1500)
import org.openapijsonschematools
from org.openapijsonschematools.apis.tags.tag_to_api import *
from org.openapijsonschematools.components.schemass import *