Invalid IRIs in output DTOs

[bpolaszek]

Discussed in #6473

^{Originally posted by bpolaszek July 17, 2024}
Hello there,

I just noticed that when using DTO output to create a different representation of the resource, the IRI returned by API-Platform is a generated one (as of API-Platform 3.x), instead of the original one (as of API-Platform 2.x).

TL; DR:

When requesting GET /api/books/1, I get

{
  "@type": "BookOutput",
  "@id": "/api/.well-known/genid/b10ecd57cce7b0b65b14"
}

instead of

{
  "@type": "Book",
  "@id": "/api/books/1"
}

---

After further investigation, I think this is a regression from API-Platform 2.x.
Here's a minimal repository to reproduce the issue:

• A Book entity (type='entity')
• A BookOutput representation (type='output')
• A StateProvider
• An integration test and its result

The final API consumer should not know anything about BookOutput, they should just see a Book with a valid IRI.

Thank you,
Ben

[soyuka]

This is not a regression if BookOutput is a Book why not return a Book? It should be the other way around:

• declare your Get on BookOutput(shortName: 'Book')
• in the BookOutput::provider (or use stateOptions: new Options(entityClass: Book:class)) fetch your book and map the data

[bpolaszek]

Hey @soyuka, thanks for your quick answer.
If I understand correctly, the APIResource annotation should be put on top of BookOutput instead of Book, right?

I just did the change here but here's the result:

• POST to /books properly creates a new book in database ✅
• Output of POST operation returns a serialization of Book instead of BookOutput ❌
• GET /books properly returns a collection of BookOutput with correct IRIs ✅
• GET /books/1 returns a serialization of BookOutput like the one I expected in return of the POST operation.

So far everything works as expected, except the returned output from the POST /books operation, which should be the same as doing a GET /books/1.

Here's the result of this test:

array:1 [
  "POST /api/books" => array:6 [
    "@context" => array:4 [
      "@vocab" => "http://localhost/api/docs.jsonld#"
      "hydra" => "http://www.w3.org/ns/hydra/core#"
      "name" => "Book/name"
      "type" => "Book/type"
    ]
    "@type" => "Book"
    "@id" => "/api/.well-known/genid/42d1873232123aa23" // <-- Nope
    "id" => 1
    "name" => "PHP for dummies"
    "type" => "entity" // <-- Nope
  ]
]
array:1 [
  "GET /api/books" => array:5 [
    "@context" => "/api/contexts/Book"
    "@id" => "/api/books"
    "@type" => "hydra:Collection"
    "hydra:totalItems" => 1
    "hydra:member" => array:1 [
      0 => array:5 [
        "@id" => "/api/books/1" // <-- Yep
        "@type" => "Book"
        "id" => 1
        "name" => "PHP for dummies"
        "type" => "output" // <-- Yep
      ]
    ]
  ]
]
array:1 [
  "GET /api/books/1" => array:6 [
    "@context" => "/api/contexts/Book"
    "@id" => "/api/books/1" // <-- Yep
    "@type" => "Book"
    "id" => 1
    "name" => "PHP for dummies"
    "type" => "output" // <-- Yep
  ]
]

Any ideas?

[soyuka]

Output of POST operation returns a serialization of Book instead of BookOutput ❌

Probably that the WriteProcessor of API Platform is returning a Book not a BookOutput, we can probably add the "auto-mapping" to that but I wish we get to experiment symfony/symfony#51741 which will bring a way more enjoyable developer experience.

[bpolaszek]

Yay 🎉

I managed to make the test suite pass by enhancing processor / provider to handle every case here.

I also added an input DTO to complicate things even more, and I succeeded here.

If you confirm this is the correct way to do, maybe I could suggest a deeper explanation / cookbook in the docs in the near future.

By the way, auto-mapping looks really cool 👍

Thank you for your help @soyuka!

[soyuka]

It's not documented yet as experimental see #5275 for more details ideas.

[bpolaszek]

Alright, thank you for your time anyway 🙂