[GraphQL] Ability to define item get operation without any arguments

[SCIF]

These days it's impossible to define an item operation for resource without argument. At least id will be added automatically.

The code:

/**
 * @ApiResource()
 */
class User

A query generated in the schema:

user(id: ID): User

Proposal

To achieve generation of user: User query we can add next notation:

 * @ApiResource(
 *     graphql={
 *      "query"={"withoutId", "controller"=ViewerController::class}

SchemaBuilder will prevent using withoutId annotation without custom controller specified.

Motivation

GraphQL can serves not only «batch»/relation requests but provide a way to implement very high level of semantic of API designed. It allows developer to design API in the most correct form and prevent creation of useless operations/endpoints.
Api-platform is desinged to simplify creation of API as much as it possible, so implementing custom operations using #2445 looks really overkill.

Any other ideas? Thanks!

[alanpoulain]

What's the use case?

[SCIF]

Hi @alanpoulain , it will allow to create a query/resource like viewer: User. Any endpoints working/requesting information of currently logged in user for instance. Github's api has 3 such queries/resources.

[SCIF]

Moreover, API's requiring authentication can expose user belonged resources in such manner («watchlist», «favourites», etc).

[SCIF]

The same result could be achieved by accepting #2445 and creating a way more code. Although #2445 is more flexible, it requires to develop low-level code in cases when it's not actually necessary.

[alanpoulain]

I don't think it's a good solution to allow this. There is an id because the related data needs to be retrieved by the DataProvider. If you want to do something else, you are "off" the API Platform way of doing things, and you need to create a custom query with a custom resolver.

[SCIF]

@alanpoulain , could you advise the proper way to achieve a schema I've mentioned? Thanks!
My motivation of using graphql is not only «batch»/relation requests but very high semantic provided by GraphQl. It allows developer to design API in the most correct form and prevent creation of useless functions.

[SCIF]

I have updated the first post: added motivation and requirement of having custom controller specified in case of using withoutId.

[lukasluecke]

I believe that using the approach in #2445 solves this problem in an easy enough, and also more flexible manner. The only difference I can tell right now would be the following:
"viewer"={"item_query"=ViewerController::class}
instead of
"query"={"withoutId", "controller"=ViewerController::class}

Of course the viewer controller would differ slightly, but that might be solvable by further improvements later on.