Ability to specify which attributes of entity and its sub-entities to retrieve

[mdovey]

There are two aspects to this:

i) ability to return an embedded entity rather than a reference to an entity in a response (including in entity lists), potentially to some arbitrary level of sub-entity
ii) ability to specify which attributes of the entity and subentity are included in the response.

This could be achieved by including the following as request parameters

expansion depth (0 being the default and the current behaviour)
list of entity\attributes required

This would be a generic solution to issues: #204, #191, #115

[mdovey]

At the technical panel on 11/6/2019 is was agreed that a generic solution to #115, #191, #204 should be considered. However futher information would be required, particularly from client developers whether this is an important requirement or just a "nice to have" given the potential implications on the LCF model and server performance.

[franciscave]

Issue #280 also provides a possible use case for this, as discussed at the Technical Panel meeting on 11 October 2022.

[mdovey]

Agreed to close this, on the basis that web services which had taken this approach had often reverted. This can be re-opened if necessary.

[andrewdaye]

Scenario: As a client application that supports creating reservations, I want to show the user a list of pickup locations so that they may choose their preferred pickup location.

To display a list of valid pickup locations, it requires a number of LCF calls, that scales with the overall number of locations in the system.

Request 1: /lcf/1.0/locations?os:count=2000 (or a suitably high enough number to get all locations).

This will return all of the locations in the system, potentially including a large number of non-pickup locations. We have a customer where this is a list of around 1200 location-refs.

Request 2-1201: (each entity id from the previous request)

This will return the details of each location, allow us to determine if that location is a valid pickup location. Without making this call for every returned enetity ID in the first call, we dont know if the location is a valid pickup location, so this needs to be called for every location.

Two options:

1. Make the location requests sequentially - this could take 100 ms per call, meaning a wait time of two minutes for the location list.
2. Make the location requests asynchronously - this would likely be miscontrued as a Denial of Service attack by the server.

There are other options - e.g. batch the calls to make 50 requests at a time, followed by the next 50, etc. but this will still be subject to latency.

A more optimal solution would either be to return the entity bodies in the initial call (potential a large amount of data in a single request), or adding querying to only get the locations that meet a set of criteria.

Scenario: As a client application that supports showing a users current loans list, I need to get the details of the users loans along with identifying information that is relevant to a human. This would likely include title, contributor, end-due-date. To create this list, we need to make a request for the list of the users loan entities:

1. /lcf/1.0/patrons/{patron-identifier}/loans

This will return an entity reference for each loan. In some cases, this could be 60-80 references. In the case of 80 active loans, we then need to make 80 requests (one for each loan entity reference). This would return the end-due-date and an item entity reference.

From this we need to make 80 item requests (one for each item entity reference returned from the loan entities). Each of these would return a manifestation entity reference.

From this we make 80 manifestation requests, which then provides the bibliographic information (title,contributor, isbn).

In summary, for a user with 80 active loans we would need to make 241 requests to display their loans list in a human readable fashion. This would then need to be repeated when the user wants to refresh this list, or perhaps automatically after a loan renewal is requested and confirmed.

(Sidenote: the issue is likely an order of magnitude larger for past loans, but more likely to be subject to paging)

A solution to the requirement for nested calls is somewhat more complex than the desire for a single level of entity object detail returned (e.g. issue #280 ).

[nchamen]

Having raised issue #323 and been pointed towards this issue as addressing my question, I just wanted to add my thoughts. The scenario I'm working on is returning patron loans and I'm in agreement with @andrewdaye that the current method for doing this is not practical, due to the large number of calls that would need to be made to get the data required.

Either the Loans entity needs to be expanded to include data from other entities (Item & Manifestation in particular), such as would be needed to display relevant patron loans info, or there needs to be the capacity to return the relevant sub-entities, populated with required data. Given a choice, I would lean towards the former.