Source order
For every field in a response, the first source that applies wins:- The request. A field the caller sent with the same name is echoed back.
amount: 5000in the request isamount: 5000in the response. - The spec’s
exampleordefaulton that property. - An
enummember declared for the property. - A
format:date-time,email,uuid,uriand the rest produce a value of that shape. - A naming convention, listed below.
- A seeded random value. A dictionary word for strings, a number in range, a coin flip for booleans.
Conventions
Applied only when the spec, the request, an example, an enum or a format has not already decided the value. Names are matched after convertingcamelCase to snake_case, so createdAt and created_at are the same field.
The
id of a created resource is the key the store filed it under, so reading it back by that id works. When the spec types id as an integer, the key is numeric.
Validation
required fields and declared types on the request schema are enforced on create and modify, through $ref. Two fields are never required on input: id, which the sandbox assigns, and any property the spec marks readOnly: true. When the spec declares nothing, nothing is enforced and the sandbox does not invent a requirement; a rule can supply it.
Seeing where a value came from
requests --explain prints one synth line per field the sandbox had to choose:
amount and currency, status came from the spec’s enum, and the store key replaced the synthesised id so the resource can be read back.
The realism line
import and sandbox list print how many response fields would still fall through to a random word: