Missing descriptions for some holdings columns

[minusdavid]

Some columns in the response from /api/v1/contrib/kohasuomi/availability/biblios/{biblio_id}/search have descriptions (like collection_code_description, location_description), but holding_library_id, home_library_id, effective_item_type_id. and item_type_id don't have description equivalents.

I suppose one could argue that you can fetch this information from other API endpoints and then provide your own mappings as necessary, but it would be very convenient to have those passed back in the response.

[EreMaijala]

@minusdavid I've been thinking about this and flip-flopping a bit about what would be the best course of action here. In a way I agree that having the descriptions for all authorized values is convenient. However, including them for every response increases the response size and requires additional work on the server even if the values are cached. That's why I'm leaning towards not adding the new fields, and that caching and mapping authorized values locally makes sense, even if it's a bit more work.

I know the current responses are not consistent regarding this, and I think that deprecating the description fields might be one way forward.

Another option would be to add a request parameter to indicate that you want descriptions for all authorized values. This would allow those that don't need them to leave them out while including them if requested.

What do you think?

[minusdavid]

I'm flip-flopping on this one as well.

In terms of the Koha API, I suppose we typically leave out the descriptions, although in some cases there's the x-koha-embed header of "+strings" which provides the descriptions in a "_strings" field. For example: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34211

I do wonder about having an API endpoint that could provide all item descriptions (e.g. collection codes, shelving locations, libraries, item types), so that you could make just 1 API call instead of 4+ API calls to get descriptions... although I suppose that could always end up being overly bloated as well.

I was just thinking about http://localhost:8081/cgi-bin/koha/members/member.pl and I notice it calls http://localhost:8081/api/v1/patrons and the mappings for categories and libraries are done in the Javascript, although the data is provided by the server via Template Toolkit.

Maybe the x-koha-embed of "+strings" is the way to go?

[EreMaijala]

Right, makes sense to follow the upstream convention! I'll work on adding support for the +strings embed.

[jonathanfield]

Just wondering if there is any news on this? We have a customer moving from the old Vufind connector to the KohaRest connector and they have noticed the missing descriptions on the holding_library_id! We won't work on it if there is already work in progress.

[EreMaijala]

To be honest I've completely dropped the ball on this one. I tried to fix the definitions but ran into trouble trying to get all the references to work properly. Looks like the API description will need a more substantial overhaul so that the definitions don't conflict with Koha's built-in ones. I think the definitions added by this plugin should be prefixed with something like rest_di_ or something. If you are able to contribute to fixing the definitions, I'd welcome the assistance!