Here are my notes :

Le 12/10/2016 à 09:17, Tomas Cohen Arazi a écrit :
El mié., 12 oct. 2016 a las 7:26, David Cook (<>)

Really curious to see how this plays out!

I’ve just added parameter validation to a Koha::Object, and while it works
well enough, I’m hoping for a more generalized solution. I haven’t looked
at Koha::Exceptions::* yet, but maybe that will help.

I don't know how that would work, what bug number is it?

Peeking at Koha::Exceptions::MissingParameter, I hope that there’s more
specificity than just “A required parameter is missing”. I’d want to know
which required parameter is missing.

Is there a document somewhere saying how to use Koha::Exceptions?

Well, we are not baking our own exception system, we are just using
Class::Exception so it is pretty documented!

Look at bug 17425, you will notice when we throw an exception we can add a


David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007


Office: 02 9212 0899 <02%2092%2012%2008%2099>

Direct: 02 8005 0595 <02%2080%2005%2005%2095>

*From:* [mailto:] *On Behalf Of *Tomas Cohen
*Sent:* Wednesday, 12 October 2016 2:39 AM
*To:* koha-devel <>
*Subject:* [Koha-devel] Marseille16 / REST api

During the first couple Hackfest days, Jonathan, Benjamin and I worked on
a reference implementation of CRUD code for a REST endpoint, so others can
read it, discuss it and use it as a reference for their own developments.

We worked on Koha::Cit(y|ies) because it was a really simple class. All
our work is now on bug 17428.

The main goals/concepts we tried to apply were:

* Controller class (Koha::REST::V1::Cities) should be as simple as
possible. No business logic on it. All business logic is expected to be put
on the Koha::Cit(ies|y) classes. And fully tested.

* All verbs/use cases should be covered by tests
(t/db_dependent/api/v1/cities.t). We did it, and this file could be used
(with little adjustments) as the basis for new endpoint tests.

* Heavy use of exceptions. I wouldn't say we heavily use them, but the
point is that we pass everything to the business object, and catch
exceptions it might raise. Martin pointed out that he would help us further
simplify it, making heavier use of the Swagger plugin's facilities.
Specially on parameters sanity check. More on this tomorrow!

* Koha::Exceptions got per-class files so the exceptions file is more
manageable. Bug 17425 introduced Koha/Exceptions/, and we propose
that's the way to go (Koha/ still has Virtualshelves-related
exceptions that should be moved).

* Make use of Try::Tiny for try/catch blocks. On the process we wrote
bug 17425, which introduces new exceptions, we added the dependency for
Try::Tiny (no worries, it is packaged for Jessie/Ubuntu) and Mirko was here
to validate.

* Moving business-logic to Koha:: namespace and write REST endpoints on
top of that business objects. We picked a simple object, Koha::Patron(s)
will be a more complex one of course. This is what Jonathan has been doing,
and people willing to write REST endpoints should check with him, and
probably help moving business logic into Koha:: namespace.

There are several patches on bugzilla introducing endpoints. We will try
to contact patch authors to help them make their work match this proposed

We are sticking to the 'patches speak' approach, so feel free to criticize
this implementation, to improve it or even provide a counter-proposal. We
are otherwise moving on, trying to get a functional complete REST api ASAP.


Tomas, Jonathan, Benjamin


Tomás Cohen Arazi

Theke Solutions ( <>)
✆ +54 9351 3513384 <+54%209%20351%20351-3384>

Koha-devel mailing list
website :
git :
bugs :

Fridolin SOMERS
Biblibre - Pôles support et système
Koha-devel mailing list
website :
git :
bugs :

Reply via email to