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 <[email protected]> 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 > [email protected] > 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 [email protected] 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/
