Hi there, I'm currently implementing a couple endpoints for acquisitions-related stuff and also QAing existing patches introducing endpoints. One of the things that need to be done (which I did for my own endpoint for vendors / bug 18120) is migrating them to Mojolicious::Plugin::OpenAPI instead of (the deprecated) Mojolicious::Plugin::Swagger2. I noticed there's lack of a generic way to deal with pagination. There are a couple options we could consider, but I would like to hear the opinion of UI people, which are the ones that will take advantage or suffer what we do on the backend :-D a) GET /patrons?page=1&per_page=3 => [ {borrower1}, {borrower2}, {borrower3} ] b) GET /patrons?offset=0&limit=3 => [ {borrower1}, {borrower2}, {borrower3} ] Lari proposed another one, which tackles an issue we could have on the UI (knowing the total, calculating pages, etc): c) GET /patrons?page=1&per_page=3 { total: 50000, results: [ {borrower1}, {borrower2}, {borrower3} ] } (c) has the problem that it would mean we need to change the current resposes for list operations on the already implemented endpoints. I'm not sure at this point we would need to shift api version (v2?), I would vote against, but here we have the chance to hear people using the API. Looking forward to your comments as my current dev work completion depends on it :-D -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F
What about the fourth option of returning all the results and letting the client handle pagination? There are many good javascript / jquery libraries that can be used for sorting / paginating a table. Also, pagination should be an option in the api, to preserve present behavior. I think if the api's present behavior is to return all results, then I would prefer your suggestion a as an added mechanism; from a user standpoint pages make more sense then limits and offsets to me. On Thu, Aug 24, 2017 at 8:50 AM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
Hi there, I'm currently implementing a couple endpoints for acquisitions-related stuff and also QAing existing patches introducing endpoints.
One of the things that need to be done (which I did for my own endpoint for vendors / bug 18120) is migrating them to Mojolicious::Plugin::OpenAPI instead of (the deprecated) Mojolicious::Plugin::Swagger2.
I noticed there's lack of a generic way to deal with pagination. There are a couple options we could consider, but I would like to hear the opinion of UI people, which are the ones that will take advantage or suffer what we do on the backend :-D
a) GET /patrons?page=1&per_page=3 => [ {borrower1}, {borrower2}, {borrower3} ] b) GET /patrons?offset=0&limit=3 => [ {borrower1}, {borrower2}, {borrower3} ]
Lari proposed another one, which tackles an issue we could have on the UI (knowing the total, calculating pages, etc):
c) GET /patrons?page=1&per_page=3 { total: 50000, results: [ {borrower1}, {borrower2}, {borrower3} ] }
(c) has the problem that it would mean we need to change the current resposes for list operations on the already implemented endpoints. I'm not sure at this point we would need to shift api version (v2?), I would vote against, but here we have the chance to hear people using the API.
Looking forward to your comments as my current dev work completion depends on it :-D
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 <+54%209%20351%20351-3384> GPG: B2F3C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Michael Hafen Washington County School District Technology Department Systems Analyst
El jue., 24 ago. 2017 a las 12:14, Michael Hafen (<michael.hafen@washk12.org>) escribió:
What about the fourth option of returning all the results and letting the client handle pagination? There are many good javascript / jquery libraries that can be used for sorting / paginating a table. Also, pagination should be an option in the api, to preserve present behavior. I think if the api's present behavior is to return all results, then I would prefer your suggestion a as an added mechanism; from a user standpoint pages make more sense then limits and offsets to me.
Just to clarify, what I'm proposing is adding an OPTIONAL set of query parameters to allow API consumers to get paginated results. This is by no means a proposal to change the current 'get all' behaviour. Also, if you have (say) 50000 patrons on your library, what's the point of fetching them all at once only to display (say) 20? The user experience would be enhanced if we only fetched what is needed (a page) and probably the next page (or couple next pages) in background while the user is reading the current page. I'd leave that to UI frameworks/tools as you suggest, though. Thanks for you feedback! I count it as +1 for (b) :-D -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F
I'd vote for C with no api versioning change. I think the *addition* of data does not warrant any version change. The alternative would be A + another endpoint to just get the number of results. Kyle <https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB> http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Thu, Aug 24, 2017 at 10:50 AM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
Hi there, I'm currently implementing a couple endpoints for acquisitions-related stuff and also QAing existing patches introducing endpoints.
One of the things that need to be done (which I did for my own endpoint for vendors / bug 18120) is migrating them to Mojolicious::Plugin::OpenAPI instead of (the deprecated) Mojolicious::Plugin::Swagger2.
I noticed there's lack of a generic way to deal with pagination. There are a couple options we could consider, but I would like to hear the opinion of UI people, which are the ones that will take advantage or suffer what we do on the backend :-D
a) GET /patrons?page=1&per_page=3 => [ {borrower1}, {borrower2}, {borrower3} ] b) GET /patrons?offset=0&limit=3 => [ {borrower1}, {borrower2}, {borrower3} ]
Lari proposed another one, which tackles an issue we could have on the UI (knowing the total, calculating pages, etc):
c) GET /patrons?page=1&per_page=3 { total: 50000, results: [ {borrower1}, {borrower2}, {borrower3} ] }
(c) has the problem that it would mean we need to change the current resposes for list operations on the already implemented endpoints. I'm not sure at this point we would need to shift api version (v2?), I would vote against, but here we have the chance to hear people using the API.
Looking forward to your comments as my current dev work completion depends on it :-D
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 <+54%209%20351%20351-3384> GPG: B2F3C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
While I agree that adding data to and endpoint wouldn't require versioning the api; what option C represents is a fundamental change to the data structure that the endpoint returns. Assuming the examples of returned data in options A and B represent the current api that is. I think that really the question is are we going to version the api or not. If we control all the clients that use the api, then versioning may be unnecessary, since we can change the api calls in the client as necessary when the api changes. That probably isn't the case though. I'm in favor of option A, even though it would mean another endpoint(s) to get the total number of results to aid pagination. I've seen an api like that, and while it isn't as efficient to make the extra api call, it is manageable. Though I would also be in favor of option C if we all agree that versioning the api is necessary in this case. On Thu, Aug 24, 2017 at 9:31 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I'd vote for C with no api versioning change. I think the *addition* of data does not warrant any version change.
The alternative would be A + another endpoint to just get the number of results.
Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Aug 24, 2017 at 10:50 AM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
Hi there, I'm currently implementing a couple endpoints for acquisitions-related stuff and also QAing existing patches introducing endpoints.
One of the things that need to be done (which I did for my own endpoint for vendors / bug 18120) is migrating them to Mojolicious::Plugin::OpenAPI instead of (the deprecated) Mojolicious::Plugin::Swagger2.
I noticed there's lack of a generic way to deal with pagination. There are a couple options we could consider, but I would like to hear the opinion of UI people, which are the ones that will take advantage or suffer what we do on the backend :-D
a) GET /patrons?page=1&per_page=3 => [ {borrower1}, {borrower2}, {borrower3} ] b) GET /patrons?offset=0&limit=3 => [ {borrower1}, {borrower2}, {borrower3} ]
Lari proposed another one, which tackles an issue we could have on the UI (knowing the total, calculating pages, etc):
c) GET /patrons?page=1&per_page=3 { total: 50000, results: [ {borrower1}, {borrower2}, {borrower3} ] }
(c) has the problem that it would mean we need to change the current resposes for list operations on the already implemented endpoints. I'm not sure at this point we would need to shift api version (v2?), I would vote against, but here we have the chance to hear people using the API.
Looking forward to your comments as my current dev work completion depends on it :-D
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 <+54%209%20351%20351-3384> GPG: B2F3C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Michael Hafen Washington County School District Technology Department Systems Analyst
This: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#paginat... tends to be my go to advise on paging. So, it suggests (and I agree) that paging should be handled in the headers rather than producing an envelope as per option c. This has the advantage in my opinion that we can add the additional details from c without changing the body of the response at all and thus save an api version jump. I also tend to try and use cursors where I can rather than pages.. just in case the data changes beneath you ;). Example of how I do it in a Mojo app using dbic and openapi: https://gist.github.com/mrenvoize/de0f30716fec8217a15b57d920fbdace Hope that helps. *Martin Renvoize* Development Manager *T:* +44 (0) 1483 378728 *F:* +44 (0) 800 756 6384 *E:* martin.renvoize@ptfs-europe.com www.ptfs-europe.com <https://www.ptfs-europe.com> Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com On 24 August 2017 at 16:38, Michael Hafen <michael.hafen@washk12.org> wrote:
While I agree that adding data to and endpoint wouldn't require versioning the api; what option C represents is a fundamental change to the data structure that the endpoint returns. Assuming the examples of returned data in options A and B represent the current api that is. I think that really the question is are we going to version the api or not. If we control all the clients that use the api, then versioning may be unnecessary, since we can change the api calls in the client as necessary when the api changes. That probably isn't the case though. I'm in favor of option A, even though it would mean another endpoint(s) to get the total number of results to aid pagination. I've seen an api like that, and while it isn't as efficient to make the extra api call, it is manageable. Though I would also be in favor of option C if we all agree that versioning the api is necessary in this case.
On Thu, Aug 24, 2017 at 9:31 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I'd vote for C with no api versioning change. I think the *addition* of data does not warrant any version change.
The alternative would be A + another endpoint to just get the number of results.
Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Aug 24, 2017 at 10:50 AM, Tomas Cohen Arazi <tomascohen@gmail.com
wrote:
Hi there, I'm currently implementing a couple endpoints for acquisitions-related stuff and also QAing existing patches introducing endpoints.
One of the things that need to be done (which I did for my own endpoint for vendors / bug 18120) is migrating them to Mojolicious::Plugin::OpenAPI instead of (the deprecated) Mojolicious::Plugin::Swagger2.
I noticed there's lack of a generic way to deal with pagination. There are a couple options we could consider, but I would like to hear the opinion of UI people, which are the ones that will take advantage or suffer what we do on the backend :-D
a) GET /patrons?page=1&per_page=3 => [ {borrower1}, {borrower2}, {borrower3} ] b) GET /patrons?offset=0&limit=3 => [ {borrower1}, {borrower2}, {borrower3} ]
Lari proposed another one, which tackles an issue we could have on the UI (knowing the total, calculating pages, etc):
c) GET /patrons?page=1&per_page=3 { total: 50000, results: [ {borrower1}, {borrower2}, {borrower3} ] }
(c) has the problem that it would mean we need to change the current resposes for list operations on the already implemented endpoints. I'm not sure at this point we would need to shift api version (v2?), I would vote against, but here we have the chance to hear people using the API.
Looking forward to your comments as my current dev work completion depends on it :-D
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 <+54%209%20351%20351-3384> GPG: B2F3C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Michael Hafen Washington County School District Technology Department Systems Analyst
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I like the rfc5988 idea. How practical will it be to implement this in our current API? <https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB> http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Thu, Aug 24, 2017 at 12:08 PM, Renvoize, Martin < martin.renvoize@ptfs-europe.com> wrote:
This: http://www.vinaysahni.com/best-practices-for-a- pragmatic-restful-api#pagination tends to be my go to advise on paging.
So, it suggests (and I agree) that paging should be handled in the headers rather than producing an envelope as per option c.
This has the advantage in my opinion that we can add the additional details from c without changing the body of the response at all and thus save an api version jump.
I also tend to try and use cursors where I can rather than pages.. just in case the data changes beneath you ;).
Example of how I do it in a Mojo app using dbic and openapi: https://gist.github.com/mrenvoize/de0f30716fec8217a15b57d920fbdace
Hope that helps.
*Martin Renvoize*
Development Manager
*T:* +44 (0) 1483 378728 <+44%201483%20378728>
*F:* +44 (0) 800 756 6384 <+44%20800%20756%206384>
*E:* martin.renvoize@ptfs-europe.com
www.ptfs-europe.com
Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30
The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com
On 24 August 2017 at 16:38, Michael Hafen <michael.hafen@washk12.org> wrote:
While I agree that adding data to and endpoint wouldn't require versioning the api; what option C represents is a fundamental change to the data structure that the endpoint returns. Assuming the examples of returned data in options A and B represent the current api that is. I think that really the question is are we going to version the api or not. If we control all the clients that use the api, then versioning may be unnecessary, since we can change the api calls in the client as necessary when the api changes. That probably isn't the case though. I'm in favor of option A, even though it would mean another endpoint(s) to get the total number of results to aid pagination. I've seen an api like that, and while it isn't as efficient to make the extra api call, it is manageable. Though I would also be in favor of option C if we all agree that versioning the api is necessary in this case.
On Thu, Aug 24, 2017 at 9:31 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I'd vote for C with no api versioning change. I think the *addition* of data does not warrant any version change.
The alternative would be A + another endpoint to just get the number of results.
Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Aug 24, 2017 at 10:50 AM, Tomas Cohen Arazi < tomascohen@gmail.com> wrote:
Hi there, I'm currently implementing a couple endpoints for acquisitions-related stuff and also QAing existing patches introducing endpoints.
One of the things that need to be done (which I did for my own endpoint for vendors / bug 18120) is migrating them to Mojolicious::Plugin::OpenAPI instead of (the deprecated) Mojolicious::Plugin::Swagger2.
I noticed there's lack of a generic way to deal with pagination. There are a couple options we could consider, but I would like to hear the opinion of UI people, which are the ones that will take advantage or suffer what we do on the backend :-D
a) GET /patrons?page=1&per_page=3 => [ {borrower1}, {borrower2}, {borrower3} ] b) GET /patrons?offset=0&limit=3 => [ {borrower1}, {borrower2}, {borrower3} ]
Lari proposed another one, which tackles an issue we could have on the UI (knowing the total, calculating pages, etc):
c) GET /patrons?page=1&per_page=3 { total: 50000, results: [ {borrower1}, {borrower2}, {borrower3} ] }
(c) has the problem that it would mean we need to change the current resposes for list operations on the already implemented endpoints. I'm not sure at this point we would need to shift api version (v2?), I would vote against, but here we have the chance to hear people using the API.
Looking forward to your comments as my current dev work completion depends on it :-D
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 <+54%209%20351%20351-3384> GPG: B2F3C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Michael Hafen Washington County School District Technology Department Systems Analyst
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Yeah, I've been playing with a helper function to implement it generically. We could imitate github's implementation of the 'rel' attributes. El vie., 25 ago. 2017 a las 8:36, Kyle Hall (<kyle.m.hall@gmail.com>) escribió:
I like the rfc5988 idea. How practical will it be to implement this in our current API?
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Aug 24, 2017 at 12:08 PM, Renvoize, Martin < martin.renvoize@ptfs-europe.com> wrote:
This: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#paginat... tends to be my go to advise on paging.
So, it suggests (and I agree) that paging should be handled in the headers rather than producing an envelope as per option c.
This has the advantage in my opinion that we can add the additional details from c without changing the body of the response at all and thus save an api version jump.
I also tend to try and use cursors where I can rather than pages.. just in case the data changes beneath you ;).
Example of how I do it in a Mojo app using dbic and openapi: https://gist.github.com/mrenvoize/de0f30716fec8217a15b57d920fbdace
Hope that helps.
*Martin Renvoize*
Development Manager
*T:* +44 (0) 1483 378728 <+44%201483%20378728>
*F:* +44 (0) 800 756 6384 <+44%20800%20756%206384>
*E:* martin.renvoize@ptfs-europe.com
www.ptfs-europe.com
Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30
The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com
On 24 August 2017 at 16:38, Michael Hafen <michael.hafen@washk12.org> wrote:
While I agree that adding data to and endpoint wouldn't require versioning the api; what option C represents is a fundamental change to the data structure that the endpoint returns. Assuming the examples of returned data in options A and B represent the current api that is. I think that really the question is are we going to version the api or not. If we control all the clients that use the api, then versioning may be unnecessary, since we can change the api calls in the client as necessary when the api changes. That probably isn't the case though. I'm in favor of option A, even though it would mean another endpoint(s) to get the total number of results to aid pagination. I've seen an api like that, and while it isn't as efficient to make the extra api call, it is manageable. Though I would also be in favor of option C if we all agree that versioning the api is necessary in this case.
On Thu, Aug 24, 2017 at 9:31 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I'd vote for C with no api versioning change. I think the *addition* of data does not warrant any version change.
The alternative would be A + another endpoint to just get the number of results.
Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Aug 24, 2017 at 10:50 AM, Tomas Cohen Arazi < tomascohen@gmail.com> wrote:
Hi there, I'm currently implementing a couple endpoints for acquisitions-related stuff and also QAing existing patches introducing endpoints.
One of the things that need to be done (which I did for my own endpoint for vendors / bug 18120) is migrating them to Mojolicious::Plugin::OpenAPI instead of (the deprecated) Mojolicious::Plugin::Swagger2.
I noticed there's lack of a generic way to deal with pagination. There are a couple options we could consider, but I would like to hear the opinion of UI people, which are the ones that will take advantage or suffer what we do on the backend :-D
a) GET /patrons?page=1&per_page=3 => [ {borrower1}, {borrower2}, {borrower3} ] b) GET /patrons?offset=0&limit=3 => [ {borrower1}, {borrower2}, {borrower3} ]
Lari proposed another one, which tackles an issue we could have on the UI (knowing the total, calculating pages, etc):
c) GET /patrons?page=1&per_page=3 { total: 50000, results: [ {borrower1}, {borrower2}, {borrower3} ] }
(c) has the problem that it would mean we need to change the current resposes for list operations on the already implemented endpoints. I'm not sure at this point we would need to shift api version (v2?), I would vote against, but here we have the chance to hear people using the API.
Looking forward to your comments as my current dev work completion depends on it :-D
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 <+54%209%20351%20351-3384> GPG: B2F3C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Michael Hafen Washington County School District Technology Department Systems Analyst
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F
Hi Personally I'd go for b). Specifying an offset and limit is (in my experience) easier than trying to keep track of what "page" you're on and getting the next "page". If result metadata is to be returned, as demonstrated in c), would this not be better passed in the response headers as it's not actually part of the resource being returned? Cheers Andrew -- Andrew Isherwood Senior Architect - rebus:list PTFS Europe Limited Content Management and Library Solutions email: andrew.isherwood@ptfs-europe.com web: http://www.ptfs-europe.com/ On 24 August 2017 at 15:50, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
Hi there, I'm currently implementing a couple endpoints for acquisitions-related stuff and also QAing existing patches introducing endpoints.
One of the things that need to be done (which I did for my own endpoint for vendors / bug 18120) is migrating them to Mojolicious::Plugin::OpenAPI instead of (the deprecated) Mojolicious::Plugin::Swagger2.
I noticed there's lack of a generic way to deal with pagination. There are a couple options we could consider, but I would like to hear the opinion of UI people, which are the ones that will take advantage or suffer what we do on the backend :-D
a) GET /patrons?page=1&per_page=3 => [ {borrower1}, {borrower2}, {borrower3} ] b) GET /patrons?offset=0&limit=3 => [ {borrower1}, {borrower2}, {borrower3} ]
Lari proposed another one, which tackles an issue we could have on the UI (knowing the total, calculating pages, etc):
c) GET /patrons?page=1&per_page=3 { total: 50000, results: [ {borrower1}, {borrower2}, {borrower3} ] }
(c) has the problem that it would mean we need to change the current resposes for list operations on the already implemented endpoints. I'm not sure at this point we would need to shift api version (v2?), I would vote against, but here we have the chance to hear people using the API.
Looking forward to your comments as my current dev work completion depends on it :-D
-- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
participants (5)
-
Isherwood, Andrew -
Kyle Hall -
Michael Hafen -
Renvoize, Martin -
Tomas Cohen Arazi