inaka / rest_guidelines

REST API Design Guidelines
Apache License 2.0
11 stars 1 forks source link

Pagination #7

Open thiagogabriel opened 7 years ago

thiagogabriel commented 7 years ago

Since we should return a plain array with the items, where would we include the pagination metadata ?

The practice I know is do something like this:

{ "items" :
    [
        {
            "like_count": 0,
            "id": "string",
            "media_type": "comment",
            "owner": "string"
        },
        {
            "like_count": 0,
            "id": "string",
            "media_type": "comment",
            "owner": "string"
        },
        {
            "like_count": 0,
            "id": "string",
            "media_type": "comment",
            "owner": "string"
        }
    ],
  "meta":
    {
        "current_page": 1,
        "next_page": null,
        "total_pages": 1,
        "prev_page": null
    }
}
agerace commented 7 years ago

I'll have to check with @elbrujohalcon how we usually do this, but I think it depends on the project. Sometimes we use page numbers, sometimes we use a cursor. As far as I know, the paginated resources are the only ones that should get enveloped items, as you wrote above @thiagogabriel . I'm gonna check if there's no item on the momentary index for this and, if there isn't, add it .

elbrujohalcon commented 7 years ago

Pagination can be in the headers, right @volbap ?

elbrujohalcon commented 7 years ago

In any case, we can totally add pagination as an exception to that rule, if needed.

volbap commented 7 years ago

Yeah, I would use the link headers as explained here. It seems to be a fair solution.

Also, let's try to avoid envelopes as well.

volbap commented 7 years ago

What Jayme currently supports is a non-cursor based pagination, using these headers: X-Total, X-Per-Page, X-Page

This kind of pagination, however, may not be quite useful for certain common scenarios, like a scroll feed. So, I would not make it a standard.