[Koha-devel] RFC: /svc/ API

Petter Goksøyr Åsen petter.goksoyr.asen at kul.oslo.kommune.no
Thu Jul 24 11:04:04 CEST 2014


Great comments, David!
Thanks for taking the discussion further:)

Some comments in line below:

Fra: David Cook [dcook at prosentient.com.au]

> I think that this also has the potential to increase separation of business
> and presentation layers. Of course, I think presentation is important, but
> if we focus on making sure that useful data is coming out, we're less likely
> to cheat and combine them when we probably shouldn't.

I agree - this would perhaps be the best takeaway, IMO.

> 2) I'm not sure that I understand what you mean when you ask "should Koha's
> templates make use of its own APIs?".
> 
> Do you mean using the API via Javascript on the template, or using the API
> via LWP in the Perl script?

Yes, I was thinking about such cases, as in recent enhancements using ajax+datatables
for fetching data  asynchronously. 

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.

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.

Regards,
Petter Goksøyr Åsen
Deichmanske bibliotek / Oslo Public Library





More information about the Koha-devel mailing list