[Koha-devel] FW: RFC: /svc/ API

[Renvoize, Martin]

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 at 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 at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140729/176bd392/attachment.html>