mod-agreements communicates with
mod-kb-ebsco-java to retrieve information about the resources. This interaction happens through the endpoint which accepts a single id parameter and returns a single entity. In case of loading n resources the
mod-agreements should perform n requests to
mod-kb-ebsco-java, which may cause the delay for display information.
This spike is addressed to provide a solution for reducing a number of requests to
mod-kb-ebsco-java and introduction of an endpoint to accept list of resources.
Option 1 - Introduce new GET endpoint with body
Based on the specification there is no restriction on usage payload for GET request
- It is not commonly used approach
Option 2 - Use GET endpoint with additional parameter 'id'
- No need in new endpoint creation
- HTTP protocol does not defined limitation for URI according to specification but the server and browsers do. General recommendation is no longer than 2000 characters.
Option 3 - Introduce new POST endpoint
- HTTP protocol does not defined limitation for the body of the POST method but server and browsers do.
- The semantics of POST is intended to create entries but not fetching them.
During the presentation of the spike it was decided that the best approach to solve current issue is to use
POST method to load resources. Below you may find the sequence diagram.
According to the mod-agreements file mod-agreements is interested in following attributes:
some of them are related to package and some to a resource
|package attributes||resource attributes|
We also had an assumption that usage of
holdings table can simplify the work of loading but some of the properties are absent
here is an example of loaded holding
seems that for
managedCoverages dates two types of parameters are used, they are
dateFirstIssueOnline and it is not clear what property is used for
customCoverages if it is present. Also
titleCount property is not present. So, the holding table is likely can not be used as a source of the truth.