https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27113 --- Comment #49 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (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/Bi... -- You are receiving this mail because: You are watching all bug changes.