Subresource in swagger didn't have 'page' field.

[ln-e]

Although there is enabled pagination:

{
  "@context": "/api/contexts/Task",
  "@id": "/api/projects/3/tasks",
  "@type": "hydra:Collection",
  "hydra:member": [
    ...
  ],
  "hydra:totalItems": 33,
  "hydra:view": {
    "@id": "/api/projects/3/tasks?page=1",
    "@type": "hydra:PartialCollectionView",
    "hydra:first": "/api/projects/3/tasks?page=1",
    "hydra:last": "/api/projects/3/tasks?page=2",
    "hydra:next": "/api/projects/3/tasks?page=2"
  },
}

api-platform/core: v2.1.4

[Simperfit]

I don't really understand what's the issue here, firstly you are showing us a json-ld return not a swagger one and the page are in the hydra:view.

[ln-e]

There is pagination in response.
But there isn't page field in swagger.

[JumpIfBelow]

I actually have the same issue here: a subresource does not seem to have pagination activated.
I'll check the sources if I could where this issue belongs to. It is kinda weird that it is rendering in such a way. If I find a fix quickly, I'll do a merge request.

EDIT: to provide more informations, it is not just lack of documentation, but the parameter really is not there. If I use a page parameter manually, the response is an empty array, while I have more than 30 items. I'll get 30 of them if I'm not providing the page parameter, however the remaining data is not accessible.
I've dumped some data, and it seems that the documentation generator wants to add a page parameter, but it is not rendered in the end.

Here is the dumped documentation:

And now the result in the doc:

[JumpIfBelow]

Okay, so part of the problem actually is that I've named the subresource operation on my entity api_users_rights_get_subresource while API Platform is generating api_users_rights_get_subresourceRightCollection. I think I've been misled to the first name because I used the route name. But how to know this? I only discovered after dumping data in the core, maybe there is a lack of information somewhere (I'm not blaming here, just trying to understand)

The result of some operations made by the core is clearer now, but the final result seems to be the same for the documentation. Meanwhile, the result seems fixed: I can manually do the request with the page parameter.

Still, what is happening in Swagger\Serializer\DocumentationNormalizer.php:197 seems a bit confusing to me. I've seen the array beeing filled with two new entries in only one iteration. Some data are altered between what the getPathOperation returns and the storage in $paths variable. I'm not able to understand it more by myself.

[dunglas]

We had a discussion about pagination with @sroze recently. We thought it would be nice to implement it has filters instead of this custom logic.

Anyway, it looks like a bug to me. The Swagger Normalizer probably not handle pagination for resources.

[JumpIfBelow]

This issue still hurts my brain to understand it completely.
So, by changing the name as I said above for api_users_rights_get_subresourceRightCollection, what I've done is basically saying goodbye to any custom configuration for this subresource. It means this name has nothing to do to customize the subresource. In the same time, the pagination is now active, the configuration is auto-generated.

If I use the api_users_rights_get_subresource, I am able to add some special things, like authorization. But somewhere in the code, the pagination ability is lost, so no more paginated result for this subresource.

So, the issue is about *ToMany subresources, with the Swagger\Serializer\DocumentationNormalizer missing the generated name route. It adds a <resource name>Collection sufix to the route name that makes the whole thing failing to provide a pagination. I guess this suffix should not be there, as it clearly is a conflict between auto-generated and customized subresources parameters.

[soyuka]

Closing in favor of #2706