Core: Bug or feature? Weird resource identificator in GraphQL

[insekticid]

I am playing with graphQL and only way how to query some resource is via fqn id in GraphQL query. But i thing, it should be changed and simplified

Look at this query

{
  greeting(id: "greetings/1") {
    name
  }
}

Better sollution is via this standard query. Is this bug or feature?

{
  greeting(id: "1") {
    name
  }
}

You can watch this GraphQL tutorial https://youtu.be/UBGzsb2UkeY?t=1424

[alanpoulain]

This is a feature. We want the GraphQL part of API Platform to be compatible with the REST part. Therefore, id attribute is always referring to the IRI.

[dunglas]

Your proposal isn't valid according to the Relay spec: https://facebook.github.io/relay/docs/en/graphql-server-specification.html#object-identification
Using an IRI allows the API Platform's GraphQL endpoint to be compatible with the REST subsystem, it's a big win when using both together. See the end of https://dunglas.fr/2018/03/symfonylive-paris-slides-rest-vs-graphql-illustrated-examples-with-the-api-platform-framework/ for instance.

Closing.

[kiler129]

@dunglas I understand the reasoning, but maybe REST compatibility should be an option (enabled by default)? When you only utilize GraphQL it's kind of strange to handle such ids.
Also, I don't see where making ids plain conflicts with the Realy specification you linked?

[tigitz]

I tend to agree that if you chose to only use GraphQL from API Platform, other ways of exposing data in the framework shouldn't "leak" into the one you've chosen.

I get this is for applications wanting to manage both GraphQL and REST but my feeling is that they're the minority compared to "REST only" or "GraphQL only". You might have data that indicates the contrary though.

At work I seriously considered working on my own IRI converter too. I dont wan't to document a FAQ section explaining why the ids are formatted this way to our clients that only see a GraphQL api from their perspective. Cause I guarantee they'll ask.

@dunglas Is a mechanism to opt-in or opt-out of this seems reasonable to you ? The default would be opt-in.

I'm willing to contribute to this if it has any chance to be merged.

[dunglas]

maybe REST compatibility should be an option

The concept of IRIs is broader than REST. It's the standard for resource identifiers, and it's used for everything related to the web and Linked Data (including XML namespaces for instance).
There are other proposals using IRIs in GraphQL, the most popular is https://www.hypergraphql.org/.

Also, I don't see where making ids plain conflicts with the Realy specification you linked?

Relay’s support for object identification relies on the GraphQL server exposing object identifiers in a standardized way. [...]
Refetching the object is done with the node field on the root query object. [...]

The server must provide an interface called Node. That interface must include exactly one field, called id that returns a non‐null ID.

This id should be a globally unique identifier for this object, and given just this id, the server should be able to refetch the object.

https://facebook.github.io/relay/graphql/objectidentification.htm

This part of the Relay spec requires the ID to be global, and independent of the type of the object. It could be a UUID or a IRI (UUIDs can be represented as IRIs by the way, https://tools.ietf.org/html/rfc4122), but it need to be a global identifier. As API Platform already has all the tooling to retrieve any object from it's IRI (and generate the IRI from any object), we made the choice to reuse it.
We may introduce an option to base64-encode this ID, but I don't really get what would be the benefit except extra complexity.

[milosa]

What bothers me is that this results in URLS looking like:
localhost/todolist/%2Fapi%2Ftodo_lists%2F123
instead of just
localhost/todolist/123

Also, a graphql query like this:
query { TodoLists(id: "/api/todo_lists/123") { name }}

seems a bit verbose to me.
I'm using a TodoList query, yet I also have to use an id specifying the type again.

UUID support would be better. At least it doesn't feel as repetitive.

Maybe the ApiPlatform\Core\GraphQl\Resolver\ItemResolver can be made non final? So people can decide for themselves?

[dunglas]

@milosa making classes non-final make them very hard to maintain, we prefer to provide the appropriate extension points and favor composition. You can already change this behavior (for instance to use a UUID, or to base64 encode the IRI, that would be easier to implement and better IMHO) by decorating the api_platform.iri_converter service.