Supporting Graph.RBAC scenario with fragment nextLink

Split out from https://github.com/Azure/autorest/issues/1232 so that it’s easier to track what needs to get done. For more context, you can look through that entire thread. We want to make sure this scenario doesn’t break in all languages, so the request is for each language to implement the

There is a TestServer Swagger operation that verifies the Graph.RBAC paging scenario:

• This is the first call https://github.com/Azure/autorest/blob/master/src/dev/TestServer/swagger/paging.json#L285
• This is for subsequent “next pages”: https://github.com/Azure/autorest/blob/master/src/dev/TestServer/swagger/paging.json#L321

The TestServer implementation of these operations is here:

• First call: https://github.com/Azure/autorest/blob/master/src/dev/TestServer/server/routes/paging.js#L124
• Subsequent calls: https://github.com/Azure/autorest/blob/master/src/dev/TestServer/server/routes/paging.js#L133

Here’s the C# test that verifies this scenario: https://github.com/Azure/autorest/blob/2a25d885a15aa0dfb4a73f00c9b1b8e4ad79e85b/src/generator/AutoRest.CSharp.Azure.Tests/AcceptanceTests.cs#L457

This is the standardized flow for handling x-ms-pageable:

1. If operationName is used, skip creating a Next() page method.
2. The operation specified in operationName should follow the normal method logic
3. Start with the base url
4. Concat the operation path (e.g. {tenantID}/{nextLink} in the case of Graph.RBAC)
5. Perform path replacements
   • This includes replacing {nextLink} with the nextLink method argument
6. Append any query parameters defined for the Next() operation.
   • This needs to take into account that query parameters might already exist in the url, since nextLink could have query parameters.

[amarzavery]

fragmented nextLink always worked in node.js. Infact other sdks were inspired from the node.js solution.

[mcardosos]

Hohohoho, yes, it is supported