https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27947 --- Comment #22 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Marcel de Rooy from comment #9)
[5] Why do you add cancel_article_request to Koha/REST/V1/Patrons.pm ? Apart from checking existence of the patron id, what is its use ?
As I was making API endpoints for cancelling article requests from staff interface (we should move away from svc in any chance we've got), I thought it would be good to add the same for opac.. the endpoint that opac uses is DELETE /api/v1/public/patrons/{patron_id}/article_requests/{ar_id}, so It seemed natural to place it in Koha/REST/V1/Patrons.pm
I dont really mind. Maybe ask Tomas? But it seemed more logical (or consistent) to me that deleting an article request from OPAC or staff have similar end points.
I generally prefer context-specific routes, so: /patrons/:patron_id/article_requests/1 over /article_requests/1 in the particular case of the public routes, this allows us to use the 'allow-owner' permission feature from our API framework. What I don't like, is having the controller methods so sparse. I will submit a follow-up reorganizing that. -- You are receiving this mail because: You are watching all bug changes.