OpenAPI Schema Evolution - Backward-Compatible
The compatible member of a complete OpenAPI 3.1 ticket endpoint contract. Backward compatible: an optional priority response property is added and existing operations stay unchanged.
{
"openapi": "3.1.0",
"info": {
"title": "P6 Ticket API",
"version": "1.1.0"
},
"paths": {
"/tickets/{id}": {
"get": {
"operationId": "getTicket",
"parameters": [
{
"name": "id",
"in": "path",
"required": true,
"schema": {
"type": "string"
}
}
],
"responses": {
"200": {
"description": "Ticket",
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/Ticket"
}
}
}
}
}
}
}
},
"components": {
"schemas": {
"Ticket": {
"type": "object",
"required": [
"id",
"summary"
],
"properties": {
"id": {
"type": "string"
},
"summary": {
"type": "string"
},Specifications
- Schema Family
- OpenAPI
- Version Role
- compatible
- Expected Compatibility
- valid
- Openapi
- 3.1.0
- Paths
- 1
- Properties
- 3
- Required
- 2
Testing contract
Expected to pass- Scenario
- Compare the compatible OpenAPI contract against the baseline member using a compatibility checker.
- Expected result
- Backward compatible: an optional priority response property is added and existing operations stay unchanged.
What is a .json file?
JSON (JavaScript Object Notation) is a lightweight, text-based data-interchange format representing objects, arrays, strings, numbers, booleans, and null. It is language-independent, human-readable, and the dominant format for web APIs and configuration. It requires a single well-formed root value.
How to use this file
Use an example JSON file to test parsers and serializers, schema validation, Unicode and number-precision handling, and API request or response processing.
How to use this file for testing
“OpenAPI Schema Evolution - Backward-Compatible” is a deterministic Novus Examples fixture for Schema / OpenAPI testing, Schema validation, API testing, Conversion testing. Valid and intentionally invalid OpenAPI/JSON Schema documents plus request/response examples for schema validators and API tooling.
Documented properties for this file: JSON · 1,199 bytes. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Data fixtures document their exact quirks — delimiters, encodings, null handling, schema, and row counts — in the spec table. Point your parser or importer at the file and assert it handles the documented edge cases; clean and deliberately-messy siblings make before/after diffs straightforward.
Valid and intentionally invalid siblings are labelled in title and description. Assert parsers accept the valid twin and fail loudly on the invalid one; for time series, check DST gaps and duplicate keys against the spec table.
Code examples
import json
with open("openapi-compatible.json") as f:
data = json.load(f)
print(type(data), len(data))Related files
- jsonAvro Schema Evolution - Backward-CompatibleThe compatible Avro record schema for reader/writer compatibility tests. Backward compatible for old records: nullable email is added with a null default.

- jsonAvro Schema Evolution - BaselineThe baseline Avro record schema for reader/writer compatibility tests. Reference writer schema: id and name are strings.

- jsonAvro Schema Evolution - BreakingThe breaking Avro record schema for reader/writer compatibility tests. Breaking relative to baseline: id changes to long and tenantId has no default.

- jsonJSON Schema Schema Evolution - Backward-CompatibleThe compatible member of a JSON Schema 2020-12 customer contract. Backward compatible: existing instances remain valid because email is optional.

- jsonJSON Schema Schema Evolution - BaselineThe baseline member of a JSON Schema 2020-12 customer contract. Reference contract: id and name are required strings.

- jsonJSON Schema Schema Evolution - BreakingThe breaking member of a JSON Schema 2020-12 customer contract. Breaking relative to baseline: id changes from string to integer and tenantId becomes required.

Generated by generation/p6_core.py. Free for any use, no attribution required — license.