Skip to content

fix(jsonapi): do not require id in input schema for post operations#8252

Merged
soyuka merged 1 commit into
api-platform:4.3from
soyuka:fix/jsonapi-post-id-not-required-6738
Jun 5, 2026
Merged

fix(jsonapi): do not require id in input schema for post operations#8252
soyuka merged 1 commit into
api-platform:4.3from
soyuka:fix/jsonapi-post-id-not-required-6738

Conversation

@soyuka
Copy link
Copy Markdown
Member

@soyuka soyuka commented Jun 5, 2026

Summary

The JSON:API input schema marked id as required for every operation, but the spec (https://jsonapi.org/format/#crud-creating) lets a client supply a client-generated id when creating a resource — it is not required. POST schemas now require only type; PATCH/PUT/GET still require id.

Reproduction

Calling POST against a JSON:API resource with a body lacking data.id was rejected because the generated input schema marked id as required.

Test plan

  • Added failing test asserting POST schema does not require id.
  • Added regression test asserting PATCH still requires id.
  • JsonApi suite passes locally.

Fixes #6738

Per the JSON:API spec (https://jsonapi.org/format/#crud-creating), a
client MAY supply a client-generated id when creating a resource. The
schema factory unconditionally marked id as required for any input
schema, which forced clients to invent ids on POST. Mark id as required
only for non-POST HTTP operations.

Fixes api-platform#6738
@soyuka soyuka merged commit 5c62c1b into api-platform:4.3 Jun 5, 2026
110 of 112 checks passed
@soyuka soyuka deleted the fix/jsonapi-post-id-not-required-6738 branch June 5, 2026 11:43
soyuka added a commit to abderrahimghazali/core that referenced this pull request Jun 5, 2026
Per https://jsonapi.org/format/#crud-creating-client-ids a client MAY
supply an id when creating a resource. The JSON:API ItemNormalizer
previously treated any incoming `data.id` on POST as a hint to load an
existing resource, throwing "Update is not allowed for this operation"
or failing the IRI lookup, even when the application is designed for
client-generated identifiers.

A new opt-in `ALLOW_CLIENT_GENERATED_ID` denormalization context flag
lets the client id flow through to the entity setter without querying
the IriConverter. Off by default to avoid an id-spoofing footgun on
public endpoints. Configurable globally via the Symfony bundle
(`api_platform.jsonapi.allow_client_generated_id`) and Laravel
(`api-platform.jsonapi.allow_client_generated_id`), per-operation via
`denormalizationContext`.

Also tightens the input-schema guard added in api-platform#8252 with a
`Schema::TYPE_INPUT === $type` check so POST response schemas keep
requiring `id`.

Refs api-platform#6738
soyuka added a commit to abderrahimghazali/core that referenced this pull request Jun 5, 2026
Per https://jsonapi.org/format/#crud-creating-client-ids a client MAY
supply an id when creating a resource. The JSON:API ItemNormalizer
previously treated any incoming `data.id` on POST as a hint to load an
existing resource, throwing "Update is not allowed for this operation"
or failing the IRI lookup, even when the application is designed for
client-generated identifiers.

A new opt-in `ALLOW_CLIENT_GENERATED_ID` denormalization context flag
lets the client id flow through to the entity setter without querying
the IriConverter. Off by default to avoid an id-spoofing footgun on
public endpoints. Configurable globally via the Symfony bundle
(`api_platform.jsonapi.allow_client_generated_id`) and Laravel
(`api-platform.jsonapi.allow_client_generated_id`), per-operation via
`denormalizationContext`.

Also tightens the input-schema guard added in api-platform#8252 with a
`Schema::TYPE_INPUT === $type` check so POST response schemas keep
requiring `id`.

Refs api-platform#6738
soyuka added a commit to abderrahimghazali/core that referenced this pull request Jun 5, 2026
Per https://jsonapi.org/format/#crud-creating-client-ids a client MAY
supply an id when creating a resource. The JSON:API ItemNormalizer
previously treated any incoming `data.id` on POST as a hint to load an
existing resource, throwing "Update is not allowed for this operation"
or failing the IRI lookup, even when the application is designed for
client-generated identifiers.

A new opt-in `ALLOW_CLIENT_GENERATED_ID` denormalization context flag
lets the client id flow through to the entity setter without querying
the IriConverter. Off by default to avoid an id-spoofing footgun on
public endpoints. Configurable globally via the Symfony bundle
(`api_platform.jsonapi.allow_client_generated_id`) and Laravel
(`api-platform.jsonapi.allow_client_generated_id`), per-operation via
`denormalizationContext`.

Also tightens the input-schema guard added in api-platform#8252: adds a
`Schema::TYPE_INPUT === $type` check so POST response schemas keep
requiring `id`, and captures the resource operation before the
relationship loop reassigns `$operation` so the requirement check
targets the correct operation when the resource has relationships.

Refs api-platform#6738

Co-authored-by: soyuka <soyuka@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant