api-platform / api-platform/core

Resource IRI and `@id` using the wrong operation

Abierto
#5,782 8 comentarios 1 reacción 0 asignados Ver en GitHub
Lenguaje dominante
PHP
Estrellas
2.6k
Forks
980
Merge medio
2 d 4 h
PR fusionados (30 d)
49

Descripción

**API Platform version(s) affected**: 2.7 up to 3.1

**Description**
Hello,

I am not fully sure if that's a bug, a breaking change we have to deal with, or something we're doing wrong, so I'm sorry if this was already answered.

I am hitting a situation where the IRI returned for a PATCH route in the `@id` jsonld context field is not referencing the correct IRI, but the operation route. It was working fine before turning BC flag OFF, and I am able to consistantly reproduce on v3.1 as well, which is why I am not fully sure of the expected behaviour at the end.

As far as my debug went, it happens when the resource has several item operations, using `uriTemplate`, and the new IriConverter is used. The old IriConverter seemed to always use the first item operation, while the new is using the current operation.

**How to reproduce**
Here is a small and fresh symfony app reproducing the issue: https://github.com/n-valverde/apip-bad-jsonld-id

There is one simple test: https://github.com/n-valverde/apip-bad-jsonld-id/blob/master/tests/FooTest.php

This test is green with BC flag ON, and turns red showing the `@id` issue when BC flag is OFF.
The resource is using two GET operations in this case for the sake of simplicity, but I initially hit the issue on a PATCH route, and can reproduce with a PATCH on the reproducer as well, so that seem really related to item operations.

**Possible Solution**
I don't know if that's an expected behaviour, and if it's not, I'm not sure where the issue is. On the patch route, the IRI is initially correct in the `$request` attribute `_api_write_item_iri` set from the `WriteListener`, but when coming back from a controller which is returning a resource, or from a processor doing the same, the resource is then serialized from another listener, and the current operation is passed to the IriConverter, which is ultimately causing the issue.

**Additional context**
My real resource definition looks like this (simplified with relevant things only)

```
new Get(),
new Patch(uriTemplate: '/colorways/{id}/transition', processor: SomeProcessor::class),
```

With such a definition, `@id` was previously `/colorways/{id}` on the PATCH route, and becomes `/colorways/{id}/transition` (with {id} placeholder resolved of course)

Thanks!

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.