<div dir="ltr">An interesting conversation all in all.<div><br></div><div>I'm most certainly in favour of a well implemented restful api and <a href="http://en.wikipedia.org/wiki/Eating_your_own_dog_food">dogfooding</a> it for the opac so we keep it useful and up to date. </div>
<div><br></div><div>I found this article very useful when crafting some api's for another product I work on regularly: <a href="http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api">http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api</a></div>
<div><br></div><div>As for the caching scenario, that's interesting indeed, and I can see huge advantages to gain here. I would suggest adding an optional hash/token to such requests and setting the cache time to 'forever'. That way we could link a change of the data to a change of the token, and hence manage the cache ourselves at the template level. If you want an idea of what I'm getting at, take a look at the docs for googles mod_pagespeed, as that's where I got my inspiration), or drop me a line for a chat.</div>
<div><br></div><div>All exciting thoughts. I'll certainly be working on the API's at some point as part of our work using api's for the vufind connectors so I'm be happy to input a bit of time into this once the ball is rolling.</div>
<div><br></div><div>Martin</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><br></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">Martin Renvoize<div>Software Engineer, PTFS Europe Ltd</div>
<div>Content Management and Library Solutions</div><div>Skype: <img src="http://mystatus.skype.com/bigclassic/ashimema" width="96" height="23"></div><div>Landline: 0203 286 8685</div><div>Mobile: 07725985636</div><div><br>
</div><div><a href="http://www.ptfs-europe.com" target="_blank">http://www.ptfs-europe.com</a></div></div></div>
<br><br><div class="gmail_quote">On 25 July 2014 01:15, David Cook <span dir="ltr"><<a href="mailto:dcook@prosentient.com.au" target="_blank">dcook@prosentient.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You're very welcome, Petter. I'm happy to be having this discussion!<br>
<br>
I've included some inline comments below as well.<br>
<div class=""><br>
> I also think it can be used for more static data, which rarely change.<br>
> Say for example the list of branches (we have around 30) which<br>
> populates dropdown several places the staff interface. If this was<br>
> fetched after page load, by an AJAX request to, say, GET<br>
> koha/rest/v2/branches, we could set the Cache expiration headers, (to<br>
> a day, or a month, I dunno) then the browser would cache this<br>
> particular request, and thus not touch the database at all except when<br>
> cache expires. For frequently used pages this could lead to a lot of<br>
> less traffic to the database. Then there is the problem of when you<br>
> actually DO change this "mostly" static data, like branches... Well,<br>
> either you can wait until cache expires, you can force to reload (Cltr<br>
> +R, or Cltr + F5 in most browser), or we must implement some logic on<br>
updates which modifies the cache expiration headers.<br>
<br>
</div>I don't have much experience with caching, but that sounds interesting.<br>
<br>
One worry I have about using AJAX in the OPAC is the second or so that it<br>
can take to load an element on a page sometimes. The page loads and then<br>
elements can "jump". For instance, I added a drop-down menu for "Collection"<br>
next to the masthead search box. It didn't load very smoothly. I wonder if<br>
it would if it were cached as it doesn't need to do that database query.<br>
<br>
Of course, loading search result facets would take longer, but we could add<br>
a "Loading..." or "Calculating facets..." message in that case, so that<br>
users would know what the system is doing.<br>
<div class=""><br>
> Some more benefits of Koha using its own APIs:<br>
> - They are kept up to date since they are used by Kohas core<br>
> - More thought is being put into layout, organization and<br>
> implementation of the API, as it<br>
> not just for "someone else", some third-party integration, but for<br>
> Koha itself.<br>
<br>
</div>Agreed. Since Koha would be both client and server, I think more care would<br>
be put into architecture. Since it would depend on its own API, it would<br>
have to be up-to-date.<br>
<div class="im HOEnZb"><br>
<br>
David Cook<br>
Systems Librarian<br>
Prosentient Systems<br>
72/330 Wattle St, Ultimo, NSW 2007<br>
<br>
<br>
<br>
<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.org/</a><br>
</div></div></blockquote></div><br></div>