Allow API clients to include/exclude fields in the response data
It would be great if API clients could include/exclude fields of the response data of API calls.
The rational behind this stems from a use case of our own:
When making calls to the Alma and also Primo APIs we get a huge chunk of data back from which we only need a small portion. If we were able to make an API request in which we could specify upfront which fields we would and/or wouldn't need would: (1) prevent all that overhead data, (1) reduce the network traffic and (3) increase the response speed.
The functionality that is necessary to filter the response could be implemented once on the API endpoint server. After that every possible client (also those developed by ExLibris) could then customize the response format of the APIs according to its needs.

Hello All,
This idea has been closed as part of a cleanup process for ideas older than two years with fewer than 20 votes.
This cleanup process is necessary to streamline our idea management process and ensure that the most relevant and impactful ideas receive the attention they deserve. If you still feel strongly about this idea, you may submit it via the NERS process.
We value your feedback and encourage you to continue submitting and voting for ideas that you believe will enhance Alma.
Alma Product Team
-
Lukas Koster commented
Personally I would like to be able to hide specific fields from the API output on the server side, for instance in the case of internal/local fields/values etc. With Alma export/OAI publishing profiles this can be done using normalization rules, but with API's it is not possible. I don't understand why not.
-
Dan Michael O. Heggø commented
GraphQL is becoming more and more popular as an alternative to REST. That would be a great way to solve this!
-
Matthias Einbrodt commented
Hi Dan,
I would argue yes since reasonable fast networks are not (yet) everywhere.
-
Dan Michael O. Heggø commented
Is transfer time really an issue? On a reasonable fast network, the main issue is not the transfer time, but the time it takes the servers to generate the response.
I think it's more important to improve server side caching to reduce the Time To First Byte. Adding more options make caching harder on the other hand.
-
Matthias Einbrodt commented
Hi Asaf,
thanks for the comment. My idea goes actually in both directions. While it is important to expand the number of result fields obtained by a single request using the parameters you just mentioned it is in my opinion also important to filter or restrict them beforehand in order to prevent overhead data and to reduce the amount of client side code.
In my development work I've done so far with the Alma and Primo APIs, I repeatably made the experience that I only use a maximum of 50% of all the fields from the responses of requests to the Alma and Primo APIs.
A filtering mechanism on the server side which would work in exactly the opposite way as the "addfields" parameter of Primo's PNX REST API might therefore be very handy.
-
While the Alma APIs do not currently allow full response customization for all APIs, in several cases we have added support parameters which allow clients to alter the response. For example, the Retrieve User API has a view parameter in which a brief response can be requested. The Retrieve BIB API has an expand parameter by which clients can request that additional information be added to the response.
We plan to continue the above approach and add view or expand parameters to individual APIs where we anticipate they will have the greatest impact.