It's about time to make Holds APIs first-class citizens
Idea Description
It would be far nicer to have the ability to work with hold data directly--in contrast to having to retrieve hold data via the patron APIs. For example: currently, in order to (reasonably) find the "pickupByDate" values for holds with status "(Bib, Volume, Item) hold ready for pickup" you would have to use a combination of the Sierra SQL feature (to first find all the patron record numbers possessing such a hold) and then filter all the holds for the list of patrons (from the previous step) having the "pickupByDate" key in the response object. Once you have the holds, you still have to then make another set of API calls to retrieve the rest of the hold info (the endpoint returns the hold URL), or combine it back with your SQL data.
Idea Value
It would be far more simple and effective to be able to work with holds if they were granted more of a "first-class citizen" status as a suite of API endpoints. It would be amazing to have more direct CRUD access to holds in general!
AdminMike Dicus
(Product Manager, Innovative)
shared this idea
-
Jeremy Goldstein
commented
This is still quite important to me as being able to directly search for a hold as opposed to having to come at it sideways via an item or patron record focused search would make the API far more user friendly.
That said, personally I can knock it back down a bit because of the additional data that has been added to the SierraDNA hold view since this was first written. The pickupByDate field is now available there so the particular use case cited in the idea can now be accomplished more easily. But I still want a way to search for a hold id more easily so they can then be used with the other hold endpoints.