[almighty] Pagination & jsonapi.org

[Max Rydahl Andersen]

btw. GitHub api[1] just provide the links and the approach to get number 
of pages is this:

```number_of_pages = 
last_response.rels[:last].href.match(/page=(\d+).*$/)```

which aren't that bad imo if the `page` parameter is json spec too.

[1]: https://developer.github.com/guides/traversing-with-pagination/


> On 3 Oct 2016, at 14:42, Thomas Mäder wrote:
>
>> Hi folks,
>>
>> I'm in the middle of solving 
>> https://github.com/almighty/almighty-core/issues/329 . Jsonapi.org 
>> has some recommendations about this: 
>> http://jsonapi.org/format/#fetching-pagination.
>>
>> What they recommend is adding "next", "prev" and "last" links to a 
>> "links" object on the top level of the response document.
>
> This sounds right. Makes it easy to make iteration of json docs until 
> there are no "next" links more.
>
>> The client then must compute how many pages there are and the size of 
>> the pages by parsing the uri's.
>
> Do we have a requirement for knowing the exact number of pages ?
>
>> This seems wrong to me: I expect the front end to always limit the 
>> result set anyway. In this case, returning the total count seems much 
>> simpler to me for both the back end and clients. The count could be 
>> returned as a header or as a filed in the result json object.
>
> I see that on http://jsonapi.org/examples/#pagination they mention 
> using a `total-pages` meta attribute.
> That is not by api but implementation specific - but sounds as good 
> approach. UI just shouldn't rely on it always being there.
>
>> Opinions (especially of our consumers) would be appreciated.
>
> The only place I can think of it being relevant is in the UI to be 
> able to show a "page navigation" bar or something similar.
>
> /max
> http://about.me/maxandersen




/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161003/91843dc1/attachment.htm>