Enable response data segmentation for UI clients

Registered by Fabio Giannetti

UI clients, like Horizon, needs a way to display data in a segmented (chunks) form. If the client is displaying data in a mobile device this need is even greater.
Currently Keystone returns a cap bound limit of data for an unbound request, e.g. GET v3/users. Whilst this is good practice to avoid very long response times and huge payloads it does not help the client UI in the task of effectively present the data.
We want to build on the existing solution enabling to specifically ask for a data chunk setting a limit.
The limit must be smaller than the limit set in the config file, so for instance if the truncation limit is 100, requests can ask for chinks that are <= than 100, otherwise a error code 400 will be returned and the config file limit will be sent back as guideline.
 In order to allow the client to specify how much data it want to present, if this is missing, or the client specified limit is greater, than the limit set in the configuration will be applied and enforced.

The client can use a last_seen_id attribute to express what is the last piece of data it has seen and request another chunk.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Not
Drafter:
Fabio Giannetti
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Morgan Fainberg

Related branches

Sprints

Whiteboard

This would be for instance:

GET v3/users?last_seen_id=100;limit=20

The response will be something like this:

{
    "user": {
        "default_project_id": "263fd9",
        "domain_id": "1789d1",
        "email": "<email address hidden>",
        "enabled": true,
        "id": "101",
        "links": {
            "self": "http://identity:35357/v3/users/100"
        },
        "name": "Joe"
    },
    {
    "user": {
        "default_project_id": "263fd0",
        "domain_id": "1789d2",
        "email": "<email address hidden>",
        "enabled": true,
        "id": "102",
        "links": {
            "self": "http://identity:35357/v3/users/101"
        },
        "name": "Mark"
    },
    ...
    "user": {
        "default_project_id": "263fd9",
        "domain_id": "1789d1",
        "email": "<email address hidden>",
        "enabled": true,
        "id": "120",
        "links": {
            "self": "http://identity:35357/v3/users/119"
        },
        "name": "Bill"
    }
}

The subsequent call will use the pointer to start the next request, e.g.:

GET v3/users?last_seen_id=234;limit=5

And this will produce the following response:

{
    "user": {
        "default_project_id": "263fd9",
        "domain_id": "1789d1",
        "email": "<email address hidden>",
        "enabled": true,
        "id": "235",
        "links": {
            "self": "http://identity:35357/v3/users/235"
        },
        "name": "Luke"
    },
    ...
    "user": {
        "default_project_id": "263fd9",
        "domain_id": "1789d1",
        "email": "<email address hidden>",
        "enabled": true,
        "id": "240",
        "links": {
            "self": "http://identity:35357/v3/users/240"
        },
        "name": "Frank"
    }
}

If the request is higher than the config file setting than we should throw an error and display what is the config limit.

The response will be a 400. And the content of the response will contain the max-limit=X value to show what has been set in the configuration file.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.