Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

JSON Schema: possible incompatibilities when plugging symfony/json-schema

Abierto
#8,697 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
8/100
Tipo de issue
Refactorización
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
php
Área
api

Línea de trabajo

This is a design survey, not a single fix. Start with ShortNameDefinitionPolicy, DefinitionPolicyInterface, SchemaDocument and DefinitionProcessorInterface, which the issue names as the points where the output would diverge. Done means agreeing which differences API Platform will accept, which it will adapt through an extension point, and which need follow-up issues, with the decision recorded on this thread.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Description

Follow-up of #8696: what changes if api-platform/json-schema uses symfony/json-schema (https://github.com/symfony/symfony/pull/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.
Lenguaje dominante
PHP
Estrellas
2.6k
Forks
989
Merge medio
1 d 23 h
PR fusionados (30 d)
102

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de api-platform/core

Todos los issues de api-platform/core

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.