An interesting conversation all in all. I'm most certainly in favour of a well implemented restful api and dogfooding <http://en.wikipedia.org/wiki/Eating_your_own_dog_food> it for the opac so we keep it useful and up to date. I found this article very useful when crafting some api's for another product I work on regularly: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api 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. 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. Martin Martin Renvoize Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Landline: 0203 286 8685 Mobile: 07725985636 http://www.ptfs-europe.com On 25 July 2014 01:15, David Cook <dcook@prosentient.com.au> wrote:
You're very welcome, Petter. I'm happy to be having this discussion!
I've included some inline comments below as well.
I also think it can be used for more static data, which rarely change. Say for example the list of branches (we have around 30) which populates dropdown several places the staff interface. If this was fetched after page load, by an AJAX request to, say, GET koha/rest/v2/branches, we could set the Cache expiration headers, (to a day, or a month, I dunno) then the browser would cache this particular request, and thus not touch the database at all except when cache expires. For frequently used pages this could lead to a lot of less traffic to the database. Then there is the problem of when you actually DO change this "mostly" static data, like branches... Well, either you can wait until cache expires, you can force to reload (Cltr +R, or Cltr + F5 in most browser), or we must implement some logic on updates which modifies the cache expiration headers.
I don't have much experience with caching, but that sounds interesting.
One worry I have about using AJAX in the OPAC is the second or so that it can take to load an element on a page sometimes. The page loads and then elements can "jump". For instance, I added a drop-down menu for "Collection" next to the masthead search box. It didn't load very smoothly. I wonder if it would if it were cached as it doesn't need to do that database query.
Of course, loading search result facets would take longer, but we could add a "Loading..." or "Calculating facets..." message in that case, so that users would know what the system is doing.
Some more benefits of Koha using its own APIs: - They are kept up to date since they are used by Kohas core - More thought is being put into layout, organization and implementation of the API, as it not just for "someone else", some third-party integration, but for Koha itself.
Agreed. Since Koha would be both client and server, I think more care would be put into architecture. Since it would depend on its own API, it would have to be up-to-date.
David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
_______________________________________________ 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/