<div dir="ltr"><div><div>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.<br></div>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.<br>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.<br></div>Though I would also be in favor of option C if we all agree that versioning the api is necessary in this case.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 24, 2017 at 9:31 AM, Kyle Hall <span dir="ltr"><<a href="mailto:kyle.m.hall@gmail.com" target="_blank">kyle.m.hall@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'd vote for C with no api versioning change. I think the *addition* of data does not warrant any version change.<div><br></div><div>The alternative would be A + another endpoint to just get the number of results.</div><div><br></div><div>Kyle</div></div><div class="gmail_extra"><br clear="all"><div><div class="m_-8818425550634377853gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><a href="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" target="_blank"><img></a><br></div><div><br></div><div><a href="http://www.kylehall.info" target="_blank">http://www.kylehall.info</a><br>ByWater Solutions ( <a href="http://bywatersolutions.com" target="_blank">http://bywatersolutions.com</a> )<br>Meadville Public Library ( <a href="http://www.meadvillelibrary.org" target="_blank">http://www.meadvillelibrary.<wbr>org</a> )<br>Crawford County Federated Library System ( <a href="http://www.ccfls.org" target="_blank">http://www.ccfls.org</a> )<br></div></div></div></div></div></div>
<br><div class="gmail_quote"><div><div class="h5">On Thu, Aug 24, 2017 at 10:50 AM, Tomas Cohen Arazi <span dir="ltr"><<a href="mailto:tomascohen@gmail.com" target="_blank">tomascohen@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi there, I'm currently implementing a couple endpoints for acquisitions-related stuff and also QAing existing patches introducing endpoints.<div><br></div><div>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.<div><br></div><div>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</div></div><div><br></div><div>a) GET /patrons?page=1&per_page=3 => [ {borrower1}, {borrower2}, {borrower3} ]</div><div>b) GET /patrons?offset=0&limit=3 => [ {borrower1}, {borrower2}, {borrower3} ]<br></div><div><br></div><div>Lari proposed another one, which tackles an issue we could have on the UI (knowing the total, calculating pages, etc):</div><div><br></div><div>c) GET /patrons?page=1&per_page=3 { total: 50000, results: [ {borrower1}, {borrower2}, {borrower3} ] }</div><div><br></div><div>(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.</div><div><br></div><div>Looking forward to your comments as my current dev work completion depends on it :-D</div><span class="m_-8818425550634377853HOEnZb"><font color="#888888"><div><br></div></font></span></div><span class="m_-8818425550634377853HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div class="m_-8818425550634377853m_-2601600857325092350gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(117,117,117);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:12.8px">Tomás Cohen Arazi</div><div style="color:rgb(117,117,117);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:12.8px">Theke Solutions (<a href="http://theke.io/" target="_blank">https://theke.io</a>)<br>✆ <a href="tel:+54%209%20351%20351-3384" value="+5493513513384" target="_blank">+54 9351 3513384</a><br>GPG: B2F3C15F</div></div></div>
</font></span><br></div></div><span class="">______________________________<wbr>_________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org" target="_blank">Koha-devel@lists.koha-communit<wbr>y.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" rel="noreferrer" target="_blank">http://lists.koha-community.or<wbr>g/cgi-bin/mailman/listinfo/koh<wbr>a-devel</a><br>
website : <a href="http://www.koha-community.org/" rel="noreferrer" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" rel="noreferrer" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" rel="noreferrer" target="_blank">http://bugs.koha-community.org<wbr>/</a><br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-<wbr>community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" rel="noreferrer" target="_blank">http://lists.koha-community.<wbr>org/cgi-bin/mailman/listinfo/<wbr>koha-devel</a><br>
website : <a href="http://www.koha-community.org/" rel="noreferrer" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" rel="noreferrer" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" rel="noreferrer" target="_blank">http://bugs.koha-community.<wbr>org/</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>Michael Hafen<br></div>Washington County School District Technology Department<br></div>Systems Analyst<br><br></div></div></div></div>
</div>