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.renvo...@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.renvo...@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 i...@ptfs-europe.com > > > On 24 August 2017 at 16:38, Michael Hafen <michael.ha...@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.h...@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 >>> >>> >>> <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 < >>> tomasco...@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/
