Response schemas of actions and functions that return a collection do not contain the nextLink property.

[andrueastman]

Related to #116

Assemblies affected

1.0.10

Steps to reproduce

#116 involved fixing the response shape for the collections returned in actions/functions.

However, these collections may be pageable and may contain the @odata.nextLink property which are not catered for at the moment. Ideally, this should be part of response schema as is the case for other collection properties if possible.

[peombwa]

In addition to @odata.nextLink, delta functions and other functions can also support OData query parameters such as $select. See https://docs.microsoft.com/en-us/graph/delta-query-messages#use-query-parameters-in-a-delta-query-for-messages.

[baywet]

related #196

[baywet]

Additionally, the ms pageable extension is missing for delta functions

x-ms-pageable:
nextLinkName: '@odata.nextLink'
operationName: listMore

[baywet]

So to recap

• Actions/functions that return collections should be relying on the entityCollectionResponse schema component (like collection endpoints), which will bring the next link
• They should declare the pageable extension

[andrueastman]

In addition to @odata.nextLink, delta functions and other functions can also support OData query parameters such as $select. See https://docs.microsoft.com/en-us/graph/delta-query-messages#use-query-parameters-in-a-delta-query-for-messages.

Just to confirm, will we include this in this issue as well or should we create a separate issue? We have query parameters missing like $skiptoken, and $select in the description which would be really great to have.

[baywet]

ah, thanks for bringing those back, I forgot about them.
select I have no problem with.
skiptoken actually depends on the endpoint, some use skiptoken, some use skip/top. And I don't think there's a standard annotation to know which is which.
the delta functions in Microsoft Graph are weird in the sense they are not the standard OData delta capability (I believe they predate it), so this is not something we could assume by convention (in fact delta identity uses skip token but delta ODSP uses skip top).

orderby/expand/filter support varies on an endpoint by endpoint base, maybe we could rely on regular collections (entity sets/navigation properties collections) annotations to know when to add them?
The more I think about it, the more I believe the query parameters for functions/actions is a big topic by itself and may be worth its own issue, thoughts?

[andrueastman]

I agree.
As you pointed out, the query parameters may need some more investigation and more thought around it to handle these scenarios. I'm happy with separating this out into its own issues so that at least we can get the changes with the nextLink property in.