REST API /patron/patron_id/xxx endpoints
Hey Koha developers! I would like to ask your opinion on endpoint structure for many patron-related api endpoints. We have two options for the path structure, let's say for accountlines: */patron/{patron_id)/account* (currently in use) OR */account* (not implement, (perhaps some other name would be better)) I understand why the first one makes sense and it is pretty straight-forward to use when you are dealing with a specific patron. But, the problem with this choice is that we lose the ability to query other sets of accountlines data. For example, how would you get a list of accountlines from today? There may not currently be need for such exact query, but it should be possible if we want a more complete API. My question is, when creating new endpoints that are closely tied to another object, such as accountlines to patron, do we also want to support the full accountlines object via its own endpoint? It would make sense for listing different sets of accountlines data. -- Lari Taskula Software Developer, Koha-Suomi Oy CEO, Hypernova Oy +358449857337 Kauppakatu 25 C 409 80100 Joensuu, Finland
I think the natural place for accountlines to exist is /account_lines. That said, for external consumers to use the API it is more readable to talk in terms of the patron and it's related resources. I consider the latter was a shortcut or alias and when a resource is created it should return the Location of the 'real' resource. For example POST /patrons/1/account/credits {amount: 100} => Location: /account_lines/30 { type: payment amount: 100 ... } El vie., 8 de noviembre de 2019 08:49, Lari Taskula < lari.taskula@hypernova.fi> escribió:
Hey Koha developers!
I would like to ask your opinion on endpoint structure for many patron-related api endpoints. We have two options for the path structure, let's say for accountlines:
*/patron/{patron_id)/account* (currently in use)
OR
*/account* (not implement, (perhaps some other name would be better))
I understand why the first one makes sense and it is pretty straight-forward to use when you are dealing with a specific patron.
But, the problem with this choice is that we lose the ability to query other sets of accountlines data. For example, how would you get a list of accountlines from today? There may not currently be need for such exact query, but it should be possible if we want a more complete API.
My question is, when creating new endpoints that are closely tied to another object, such as accountlines to patron, do we also want to support the full accountlines object via its own endpoint? It would make sense for listing different sets of accountlines data.
-- Lari Taskula Software Developer, Koha-Suomi Oy CEO, Hypernova Oy +358449857337 Kauppakatu 25 C 409 80100 Joensuu, Finland
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://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/
participants (2)
-
Lari Taskula -
Tomas Cohen Arazi