Like in JSON Schema, OpenAPI schema objects do not require a type
, and you are correct in that no type
means any type.
"Type-specific" keywords such as properties
, items
, minLength
, etc. do not enforce a type on the schema. It works the other way around – when an instance is validated against a schema, these keywords only apply when the instance is of the corresponding type, otherwise they are ignored. Here's the relevant part of the JSON Schema Validation spec:
4.1. Keywords and instance primitive types
Some validation keywords only apply to one or more primitive types. When the primitive type of the instance cannot be validated by a given keyword, validation for this keyword and instance SHOULD succeed.
For example, consider this schema:
definitions:
Something:
properties:
id:
type: integer
required: [id]
minLength: 8
It's a valid schema, even though it combines object-specific keywords properties
and required
and string-specific keyword minLength
. This schema means:
If the instance is an object, it must have an integer property named id
. For example, {"id": 4}
and {"id": -1, "foo": "bar"}
are valid, but {}
and {"id": "ACB123"}
are not.
If the instance is a string, it must contain at least 8 characters. "Hello, world!"
is valid, but ""
and abc
are not.
Any instances of other types are valid - true
, false
, -1.234
, []
, [1, 2, 3]
, [1, "foo", true]
, etc. In OpenAPI 3.0, untyped schemas also allow null
values.
If there are tools that infer the type
from other keywords (for example, handle schemas with no type
but with properties
as always objects), then these tools are not exactly following the OpenAPI Specification and JSON Schema.
Bottom line: If a schema must always be an object, add `type: object` explicitly. Otherwise you might get unexpected results.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…