alwaysIdentifier annotation option implementation

[adelplace]

Documentation for the feature api-platform/core#1528

[dunglas]

Can you rebase against master @adelplace?

[dunglas]

Btw, in trees an object will be always serialized only 1 time. The second time, the IRI will always be used because of the circular reference handler. It may worth mentioning this behavior.

[adelplace]

@dunglas note added

[adelplace]

@dunglas The branch is now on master and up to date

[dunglas]

Thank @adelplace.

I made a few changes, but there is something I don't understand in this example, without this option the result will be the same right? I think it should be an explicit example.

[adelplace]

Thanks for your feedback.
No without the option, the children attribute would be an array of objects (with at least an iri and a context for each object). Here you just have an array of iri

[toby-griffiths]

I've just been pointed here from api-platform/api-platform#560 as I was asking for how to do this, but I'm a little confused by this new feature/documentation.

If you use alwaysIdentifier=true on a property, does it always return an array with a single entry that is itself a URL for the collection of related resources? If so, is there a reason that this is returned as an array, rather than as a string, as this seems confusing, data structure-wise?

[soyuka]

@toby-griffiths I think I directed you by error to this issue. All it does is to force the serialization to IRI's.

If you use alwaysIdentifier=true on a property, does it always return an array with a single entry that is itself a URL for the collection of related resources?

It can be a string if the relation is a toOne IIRC

[toby-griffiths]

@soyuka I understand. But I'm now interested in this conversation… am I right in thinking that this new functionality allows you to include a link to a collection of related resources, if there's an ApiSubResource defined for them.

Example

If I have routes /questions/{id} and /questions/{id}/answers, would it be possible to get this output for the questions resource…

{
    "@id": "/questions/123",
    "@type": "Question",
    "id": "123",
    "answers": "/questions/123/answers"
}

… or perhaps…

{
    "@id": "/questions/123",
    "@type": "Question",
    "id": "123",
    "answers": {
        "@id": "/questions/123/answers"
    }
}

… ???

[soyuka]

Nope, I'm not found of this new option because it's kinda misleading.

Take a look at the behat tests on the original PR https://github.com/api-platform/core/pull/1528/files all it does is returning the relation IRI's:

{
    "@id": "/questions/123",
    "@type": "Question",
    "id": "123",
    "answers": ["/answer/1", "/answer/2"]
}

It's mainly useful when you have recursive entities which is not your case. I'm sorry for misleading you on this.

About your request we have still work to do on subresource and I'm waiting for https://github.com/api-platform/core/pull/#1478 before I can continue improving stuff.

[toby-griffiths]

@soyuka perhaps it's misleading in this example.

It would work if you added more context thought, wouldn't it?…

{
    "@id": "/questions/123",
    "@type": "Question",
    "id": "123",
    "answers": {
        "@id": "/questions/123/answers",
        "@type": "hydra:Link"
    }
}

… or am I mis-understanding the hydra vocab here?

[soyuka]

nope this "feature" is only giving strings

[adelplace]

This feature will be soon available with the maxDepth annotation, see api-platform/core#1696