https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27113 --- Comment #50 from Ivan Dziuba <ivan.dziuba@inlibro.com> --- (In reply to Tomás Cohen Arazi from comment #49)
(In reply to Blou from comment #46)
Ivan has already recoded it without sessions in our codebase. But before pushing that change, we'll be waiting for Tomas' instructions regarding the svc/
I think this is a subject worth discussing in the open, i.e. in koha-devel.
As I mentioned (not sure where) I believe we could try adding some filtering capabilities to GET /biblios to accomplish this. I proposed something similar on bug 25870. In that case, I proposed a 'q_ccl' query param that could take a CCL query so we could accept complex queries. The route would then extract the ids (biblionumbers) and return Koha::Biblios->to_api objects as required.
I don't think CCL is a cool feature, but it felt like good start: allowing people to query records through the API.
The ES syntax might be a high constraint for the feature (leaving Zebra users out), specially if you are querying things like title, author, etc. But that's another possibility: add a query parameter that only works with ES (q_es?).
Regarding routes, you need to think what the response would look like. And it will help you figure what you want. Is it ok/enough for GET /biblios?<filter> to return JSON representation of the biblio+biblioitems table columns? Unfortunately, the OpenAPI v2.0 schema doesn't provide a way to define different response schemas for different content-type responses, and thus we left GET /biblios/:biblio_id under-documented (it is supported on v3) but you can try
GET /biblios/1
and see the response to get an idea of what we already return [1].
It feels like we need to build a good query language, and reuse this routes.
[1] This is how we build the JSON representation of a biblio https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/ Biblio.pm#L867-L892
I don't understand what is it means `It feels like we need to build a good query language, and reuse these routes.`? Here I use dynamic queries $q, $prefix and a kind of "$token" to understand for which query hints were returned and whether to show or skip them. (depends on the speed of writing). Could you please clarify the structure of URL for that. Thanks! -- You are receiving this mail because: You are watching all bug changes.