+1 The REST API is just a public interface. It should use the same internal APIs as the rest of Koha. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Kyle Hall Sent: Wednesday, 17 August 2016 4:31 AM To: Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] What's on in Koha devel #3 (RESTful API) In my mind, we should be moving all appropriate logic to Koha/Objects with Koha/REST being just an api wrapper around the appropriate object. That will keep us from duplicating code and reduce bugs. Kyle <https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB> http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Mon, Aug 15, 2016 at 3:28 AM, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl <mailto:M.de.Rooy@rijksmuseum.nl> > wrote:
= RESTful API = I also would like to know who is willing to maintain this code? For instance on bug 16330 (REST API: add routes to add, update and delete patrons) the delete route is calling # check if loans, reservations, debarrment, etc. before deletion! my $res = $patron->delete So no check is done from the API. But if bug 16907 (Move DelMember and HandleDelBorrower to Koha::Patron) is pushed, $patron->delete will take care of the holds, etc. My question is simple: are we expecting from devs, signoffers and > QAers to update and maintain these routes? Or a dedicated person will update them before each release?
Just formally, I would say that if the community agreed to push this code, the community should maintain it too. We should keep the code base in a consistent state. Similarly, we should prevent redundant code: the checks for deleting a patron in one place, etc. If we are on a road now creating a lot of redundant code between Koha/REST and Koha/Objects, we should re-evaluate first and not just keep pushing more code. Is this mainly a communication issue? Which goals do we want to achieve? Should our scripts go via REST some day and should all business logic remain in Objects? Etc. etc. Marcel _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@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/