api-platform / api-platform/core

Resource IRI and `@id` using the wrong operation

オープン
#5,782 コメント 8 件 リアクション 1 件 担当者 0 名 GitHub で見る
主要言語
PHP
スター
2.6k
フォーク
980
平均マージ
2日 4時間
マージ済み PR(30日)
49

説明

**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!

コントリビューションガイド

コントリビューションガイドを開く

評価

この issue はまだ評価されていません。

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。