The "itemsPerPage" number might be incorrect for partial paginated results

[nick-behrens]

Description

RFC7644 describes the itemsPerPage value like this:

itemsPerPage The number of resources returned in a list response page. REQUIRED when partial results are returned due to pagination.

Currently, the itemsPerPage amount is set to params.Count, and when a partial page is retrieved the itemsPerPage doesn't equal the number of resources returned in a list response page.

Examples

GET http://localhost:8080/api/v1/scim/v2/Users
{
    "Resources": [
        {
            <Redacted, but a single resource>
        }
    ],
    "itemsPerPage": 100,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "startIndex": 0,
    "totalResults": 1
}

I recognize that consumers of the API could do the math (totalResults - startIndex) to figure out how many items are in the current page, but if I'm reading the spec correctly, itemsPerPage should be the number of resources retrieved and not the Count parameter.

It looks like there is a split on this depending on the SCIM implementer. Okta, AWS, and Salesforce all seem to follow itemsPerPage equaling the number of resources but Azure keeps with what is implemented here, setting the itemsPerPage to the count parameter.

I'm more than happy to contribute a PR if we want to change the itemsPerPage to equal the number of resources in the page! I have a branch for that here.

[q-uint]

Hi @nick-behrens.

We always interpreted this as "The number of resources returned in a list response page.", not necessarily this list response page. An example of this can be found on page 74 of RFC7644 where the following example is given:

{
    "totalResults":2,
    "itemsPerPage":10,
    "startIndex":1,
    ... etc
}