https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870
--- Comment #60 from David Cook <[email protected]> --- Ok, so there are many people interested in being able to send a search query to the REST API and get back search results. But I think that different people have different use cases here, and that's why the "one size fits all" approach clearly isn't working. -- I'm interested in providing Koha's OPAC search function to third-party discovery systems. (I imagine that's the same use case as Tomas and Paul?). The SOLUS Library App is very popular in Australia, and currently when they integrate with Koha they end up using opac-search.pl in RSS XML mode to get biblionumbers and then they use the REST API to get information about each record. It's not ideal. inLibro are very keen to get bug 25870 pushed because it's a dependency for "Bug 27113 - Elasticsearch: Autocomplete in search", which requires both Private Authenticated endpoints and Public Unauthenticated endpoints. Let's look at a proposed request: /api/v1/biblios?q=[{"title":"Learning Perl \/"}] Does that look like a search request to you? To me, it looks like a string of JSON being sent to a HTTP REST style biblios endpoint. It just doesn't make sense. What we need is /api/v1/search and /api/v1/public/search. And the inputs needs to be the same as the existing "Advanced search" and faceted/filtered/refined search. Basically, we need to be able to do a Staff interface search or an OPAC search via the API. We do not need to be dogmatic. It doesn't matter that there isn't a "search" table in the MySQL database. A "catalogue search" is still "a thing". Personally, I would recommend POSTing a search to the search endpoint, but I can understand why people would want to do a GET. That's fine. Re-use the same query parameters from the HTML search. That's fine. Think about every other search API you've ever used anywhere else. You've probably used a "/search" endpoint. For example: https://developer.spotify.com/documentation/web-api/reference/search Yes, there is a "/tracks" endpoint where you can look up one or more tracks by ID. But to do a "search", you use the "/search" endpoint. It's OK. -- When we have that /api/v1/public/search and /api/v1/search, it would be trivial to do autocomplete, to provide a search service to third-party apps like mobile apps or discovery layers, or to do all kinds of programmatic interrogation of the Koha catalogue. If we did POSTs instead of GETs, bots would be less likely to abuse the endpoint. It is doable. -- And if that sounds like a lot of work... it probably is because it is. But let's do the work rather than doing a workaround and just adding to the ever growing mountain of technical debt we have in Koha. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
