The JsonSchema attribute describes the type of a normalized value. Validation constraints on the data definition never reach the schema. See the change record for the JSON Schema support added to the serializer.
A consumer that validates against the schema accepts values Drupal rejects. A currency code limited to USD and CAD is published as any string.
Several core constraints map directly onto JSON Schema validation keywords:
| Constraint | Keywords |
|---|---|
AllowedValues |
enum |
Length |
minLength, maxLength |
Range |
minimum, maximum |
Regex |
pattern |
Count |
minItems, maxItems |
Email |
format: email |
$definition = DataDefinition::create('string')
->setRequired(TRUE)
->addConstraint('AllowedValues', ['USD', 'CAD'])
->addConstraint('Length', ['max' => 3]);
$data = \Drupal::typedDataManager()->create($definition);
\Drupal::service('serializer')->getJsonSchema($data, []);
// ['type' => 'string']
Expected:
['type' => 'string', 'enum' => ['USD', 'CAD'], 'maxLength' => 3]
Add an interface that constraints implement to describe themselves as JSON Schema keywords. Each constraint in the table above already has a core subclass (AllowedValuesConstraint, LengthConstraint, and so on), so core can implement it without touching Symfony's classes. Contrib constraints opt in the same way.
interface JsonSchemaConstraintInterface {
/**
* Gets the JSON Schema keywords that express this constraint.
*
* @return array<string, mixed>
* JSON Schema validation keywords.
*/
public function getJsonSchemaKeywords(): array;
}
class LengthConstraint extends Length implements JsonSchemaConstraintInterface {
public function getJsonSchemaKeywords(): array {
return array_filter([
'minLength' => $this->min,
'maxLength' => $this->max,
], is_int(...));
}
}
SchematicNormalizerHelperTrait merges the keywords into the schema. Constraints come from TypedDataInterface::getConstraints(), which includes the ones the data type adds. When the value is optional, the schema is a oneOf with a null branch, and the keywords only belong on the non-null branch.
protected function addConstraintKeywords(array $schema, TypedDataInterface $data): array {
$keywords = [];
foreach ($data->getConstraints() as $constraint) {
if ($constraint instanceof JsonSchemaConstraintInterface) {
$keywords += $constraint->getJsonSchemaKeywords();
}
}
if (isset($schema['oneOf'])) {
$schema['oneOf'][0] += $keywords;
return $schema;
}
return $schema + $keywords;
}
Open questions:
Range supports minPropertyPath and maxPropertyPath. Regex supports match: FALSE, which needs not. Should these return no keywords, or a partial schema?Regex stores a PCRE pattern with delimiters and flags. JSON Schema pattern uses ECMA-262 syntax without delimiters. Symfony's Regex::getHtmlPattern() already converts to ECMA-262, but anchors the pattern the way HTML does. Is it close enough to reuse?Choice is registered as Symfony's class directly, so it cannot implement the interface. Is AllowedValues enough?Count applies to lists, so the keywords also need to reach ListNormalizer. See #3627328: ListNormalizer does not provide a JSON Schema for lists.None.
None.
New JsonSchemaConstraintInterface. JSON Schema output for constrained data gains validation keywords. Normalization output does not change.
None.
Comments
Comment #2
mglaman