Pagination #10

Open
kinlane opened this Issue Apr 14, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@kinlane
Contributor

kinlane commented Apr 14, 2017

How we are going to handle pagination in the requests and responses for the APIs. This overlaps with the hypermedia discussion. Currently we are using a page, and per_page parameters for GET requests. Now is the time to change or evolve.

@NeilMcKechnie

This comment has been minimized.

Show comment
Hide comment
@NeilMcKechnie

NeilMcKechnie Aug 10, 2017

Works for me....the Response should also include a "Total Count" so that if you are displaying paging in a UI, you know how far to go; you also often want to display the total count to users. is anything more subtle needed?

Works for me....the Response should also include a "Total Count" so that if you are displaying paging in a UI, you know how far to go; you also often want to display the total count to users. is anything more subtle needed?

@timgdavies

This comment has been minimized.

Show comment
Hide comment
@timgdavies

timgdavies Aug 22, 2017

Contributor

In cases of data synchronisation I've seen APIs make good use of a next, prev (and sometimes first and last) relations as part of response meta-data, instead of numbered pagination.

This may be worth considering.

Contributor

timgdavies commented Aug 22, 2017

In cases of data synchronisation I've seen APIs make good use of a next, prev (and sometimes first and last) relations as part of response meta-data, instead of numbered pagination.

This may be worth considering.

@kinlane

This comment has been minimized.

Show comment
Hide comment
@kinlane

kinlane Aug 31, 2017

Contributor

Well I didn't get any bites on hypermedia, which normally is how you'd do all of this. My concern at this point is shifting the schema too heavily in minor releases. So adding JSON envelope, and adding pagination, link relations, etc. would break things -- ideally this is a v2 thing.

Which is why I suggested media types w/ hypermedia.

My second option here is adding as custom headers. Github does this. So with each response you'd get custom headers you could get any next/prev, first/last, and counts without disrupting the response schema, but didn't see many bites on header usage which always worries me.

I really want these things in here....so, I'm thinking header is only non-breaking route.

Contributor

kinlane commented Aug 31, 2017

Well I didn't get any bites on hypermedia, which normally is how you'd do all of this. My concern at this point is shifting the schema too heavily in minor releases. So adding JSON envelope, and adding pagination, link relations, etc. would break things -- ideally this is a v2 thing.

Which is why I suggested media types w/ hypermedia.

My second option here is adding as custom headers. Github does this. So with each response you'd get custom headers you could get any next/prev, first/last, and counts without disrupting the response schema, but didn't see many bites on header usage which always worries me.

I really want these things in here....so, I'm thinking header is only non-breaking route.

@kinlane kinlane added hsda v1.2 labels Sep 1, 2017

@kinlane

This comment has been minimized.

Show comment
Hide comment
@spilio

This comment has been minimized.

Show comment
Hide comment
@spilio

spilio Sep 2, 2017

Contributor

A classic reference for all bootstrapers afaiac is Apigee's REST style guide presentation.

https://www.slideshare.net/apigee/rest-design-webinar/37

They pretty much favor the limit/offset pattern.

Contributor

spilio commented Sep 2, 2017

A classic reference for all bootstrapers afaiac is Apigee's REST style guide presentation.

https://www.slideshare.net/apigee/rest-design-webinar/37

They pretty much favor the limit/offset pattern.

@kinlane

This comment has been minimized.

Show comment
Hide comment
@kinlane

kinlane Sep 3, 2017

Contributor

Appreciate the reference...

One challenge I have is introducing non-breaking. I was handed page & page_name.

Other challenge is trying to keep from breaking JSON response as well, and not push simple API response beyond 1 dimension so we can still accommodate CSV responses.

Contributor

kinlane commented Sep 3, 2017

Appreciate the reference...

One challenge I have is introducing non-breaking. I was handed page & page_name.

Other challenge is trying to keep from breaking JSON response as well, and not push simple API response beyond 1 dimension so we can still accommodate CSV responses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment