https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35797
Tomás Cohen Arazi <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #4 from Tomás Cohen Arazi <[email protected]> --- Some important remarks: - For retrieving the image, you need to know the `patron_id` on the consumer code (i.e. the path is /patrons/{patron_id}/image), so why returning the patron_id attribute at all? - Why not return the raw/binary image so this is usable on a browser without extra processing on the client side? Look at the biblios endpoint for examples [1] - The MIME type should be returned as a header [2] - The code is not tidy [3] Not a real blocker: - Most of the endpoints we have follow a pattern: GET /objects POST /objects GET /objects/:object_id PUT /objects/:object_id DELETE /objects/:object_id In this particular case, there's no object_id because the patronimage table doesn't even have an auto-increment value. I would like you to think if there could be a use case for which having more than one image per patron could be desirable (in the future). If such was the case, we could do something like GET /patrons/:patron_id/default_image instead of the current route, envisioning a future addition of a patron_image_id and being able to add many images per patron. I'm not asking you to go implement such thing, but to think of a future-proof RESTful API design. [1] Here you can see we return raw binary MARC data https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/REST/V1/Biblios.pm#L94 [2] https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/REST/V1.pm#L71 [3] There's a coding guideline for this, but basically follow this instructions to set your dev environment: https://wiki.koha-community.org/wiki/Perltidy -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
