Description

Follow-up of #8696: what changes if api-platform/json-schema uses symfony/json-schema (symfony/symfony#66685).

1. Dependency constraints

• The component first ships in Symfony 8.2 (its CHANGELOG.md).
• It requires PHP >=8.4.1, API Platform requires PHP >=8.2.
• It requires symfony/type-info ^7.4.6|^8.0.6, API Platform requires ^7.4 || ^8.0.

2. Output changes with the default configuration

• JSON Schema output uses $defs and #/$defs/ instead of definitions and #/definitions/ (Dialect::jsonSchema202012()). OpenAPI output keeps #/components/schemas/.
• $schema is https://json-schema.org/draft/2020-12/schema instead of http://json-schema.org/draft-07/schema#.
• There is no Swagger 2.0 dialect. API Platform still has the deprecated --spec-version=2 export.
• Definition names (ShortNameDefinitionPolicy) put the format in a format.<format> part instead of a .jsonld suffix, append the direction (input/output), and have no .partial, .jsonMergePatch or _noid suffix. Example: Dummy-read_format.jsonld_output instead of Dummy.jsonld-read. A custom DefinitionPolicyInterface can produce other names.
• With a direction, write-only properties are removed from output schemas and read-only properties from input schemas. API Platform keeps them, flagged readOnly/writeOnly. The component only emits these flags without a direction.
• Output schemas require properties that are always initialized (default value, promoted or constructor-set). Otherwise, mandatory constructor arguments are required. API Platform uses ApiProperty::isRequired() (validation metadata or explicit required), with no required for partial updates.
• callable and resource properties are removed. API Platform describes them as type: string.
• Examples are examples: [value] on JSON Schema 2020-12 and OpenAPI 3.1, and example only on OpenAPI 3.0 (Dialect::example()). API Platform emits example.
• Descriptions come from the PHPDoc. Values API Platform takes from metadata (ApiProperty description, deprecated, externalDocs from types, operation description) are not produced.
• Ramsey UuidInterface is not handled. API Platform describes it as format: uuid.

3. Extension points

• The extension signatures have no operation or ApiProperty. API Platform data has to go through Configuration::$context, which is neither part of the definition fingerprint nor of the default name. Any shape that depends on it (operation, partial update, gen_id) must be encoded in the name by a custom policy, or two shapes share one definition.
• SchemaDocument::reserve() and define() are @internal, and a DefinitionProcessorInterface can only change the definition it receives. Shared definitions such as HydraItemBaseSchema cannot be registered from an extension.
• The root collection schema is not passed to any extension, so hydra:member, JSON:API data/links/meta and HAL _embedded stay in an outer decorator.
• A PropertySchemaProviderInterface can return user-defined schemas (ApiProperty schema, jsonSchemaContext, openapiContext), but enrichers still run on top. API Platform leaves user-defined schemas untouched.
• A definition is built for the first occurrence of a name, so shapes depending on the parent property (e.g. gen_id on an embedded relation) collide: "a difference coming only from the parent cannot be detected and the first occurrence wins" (DefinitionPolicyInterface).
• A SchemaDocument throws when used with another refPath, so JSON Schema (#/$defs/) and OpenAPI (#/components/schemas/) output cannot share one document.

Fits the existing extension points

• IRI references for non-embedded relations: ClassSchemaResolverInterface with DefinitionParent.
• Definition names: DefinitionPolicyInterface.
• Input/output DTOs: caller side.
• Validator constraints: built-in ValidatorPropertySchemaEnricher.
• Definitions shared across OpenAPI operations: SchemaDocument, Dialect::openApi30()/openApi31().
• Eloquent models: the generator takes a PropertyInfoExtractorInterface.