I'm so glad that you've asked these questions, Petter! 1) I would very much like to see Koha's HTTP APIs expanded.
Locally, I've added some services for check-in and check-out, as we have a desktop app that does some circulation on behalf of Koha. More generally, I would like to see a richer HTTP API, so that we could more loosely couple Koha to other systems, especially in terms of OPAC functionality. We work with a lot of special libraries, so it would be great if they could use an API to integrate search and holds into their own websites. It would also be useful for discovery software (like VuFind) for getting real-time item availability information. I know BibLibre integrate Koha and Drupal (which might be the reason for their koha-restful code?). As for the staff client, I think it would still be useful, as it opens up more third-party involvement with Koha. If there were more services, we could do more with our desktop app. I'm sure that others would find uses for it as well. 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. 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? In either case, I'm starting to think so. I think there is already a growing trend in Koha for using APIs via AJAX. As for using the APIs serverside, I don't know what implications that would have. 3) I agree with your library, Petter. I think that this would be a fruitful direction for Koha to go. I think that I could contribute some time and energy to this as well. I only heard of BibLibre's "koha-restful" recently. I didn't thoroughly review the code, but it appears that it only uses IP-based authentication at the moment. I think it was missing all the functionality that I desired as well, so I decided not to use it. I hope other people express an interest as well, as I really would like to see Koha become more service-oriented. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -----Original Message----- From: Petter Goksøyr Åsen [mailto:[email protected]] Sent: Wednesday, 23 July 2014 12:11 PM To: David Cook Subject: SV: [Koha-devel] RFC: /svc/ API David Cook wrote: > Since there are an indeterminate number of third-party software > systems using the existing API, I'd recommend versioning and using v2 > to handle things more RESTfully. I agree. We should think twice before breaking existing integrations and workflows. I am also interested to hear peoples opinions about Koha's HTTP APIs in general: - do you want them expanded? for what use cases? - and more importantly: should Koha's templates make use of i'ts own APIs? My library certainly think this could be a fruitful direction for Koha to go, and want to help make it happen. But if there is no big interest in the community in this approach, we'll more likely to fork and/or contribute to Biblibre's koha-restful instead of patching the svc and ILS-DI APIs. Regards, Petter Goksøyr Åsen Deichmanske bibliotek / Oslo Public Library _______________________________________________ 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/
