Azure-rest-api-specs: Pageable next link

[mcardosos]

In the Graph swagger, lets take this operation as example...

"/{tenantID}/{nextLink}?Applications_ListNext": {
      "get": {
        "tags": [
          "Applications"
        ],
        "operationId": "Applications_ListNext",
        "description": "Gets a list of applications from the current tenant.",
        "parameters": [
          {
            "name": "nextLink",
            "in": "path",
            "required": true,
            "type": "string",
            "description": "Next link for the list operation.",
            "x-ms-skip-url-encoding": true
          },
          {
            "$ref": "#/parameters/ApiVersionParameter"
          },
          {
            "$ref": "#/parameters/tenantIDInPath"
          }
        ],
        "responses": {
          "200": {
            "description": "OK. The operation was successful.",
            "schema": {
              "$ref": "#/definitions/ApplicationListResult"
            }
          },
          "default": {
            "description": "Error response describing why the operation failed.",
            "schema": {
              "$ref": "#/definitions/GraphError"
            }
          }
        },
        "x-ms-pageable": {
          "nextLinkName": "odata.nextLink",
          "operationName": "Applications_ListNext"
        }
      }
    },

Something cool to see here would be a relation between the nextLink parameter, and odata.nextLink from x-ms-pageable. Right now, to use this pageable operations, you have to guess that whatever comes in odata.nextLink goes into nextLink. Linking this two things (and making AutoRest cooperate) could produce easier to use SDKs. Thoughts?
@marstr @jhendrixMSFT

[lmazuel]

That's a good point. Note to add points in the discussion that currently in Python we assume that if the initial operation has "operationName", then the parameter is called "nextLink" (https://github.com/Azure/autorest/pull/1420). This allowed us to generate correctly this specific client. Would be better to have an explicit relation, more than an assumption
@fearthecowboy @olydis

[olydis]

maybe that's actually something OpenAPI 3.0 can model (like, without x-ms- stuff or funny assumptions). 🙂