As already mentioned, I assume that having a new goal might be more effective than patching RTAC.
One approach could be to expose all relevant Information in the response. In other words, RTAC-2 should just provide all (non classified) attributes of 'holding', 'item', and 'location'. This will allow a library to use all attributes of this objects to pass hints to a discovery system. (e.g. the note fields). The current RTAC provides only a selection of all possible information, which leads into the well documented limitations.
Request
Task | Method | Path | PostParms |
---|---|---|---|
Inquirer information about one instance defined by UUID | GET | /rtac/uuid/{instance_uuid} | |
Inquirer information about one instance defined by HRID | GET | /rtac/hrid/{instance_uuid} | |
Inquirer information about multiple instances defined by UUID | POST | /rtac/uuid | List of UUIDs |
Inquirer information about multiple instances defined by HRID | POST | /rtac/hrid | List of HRIDs |
Notes:
- HRID as query parameter is indispensable for most German libraries.
- Since clients are capable to do asynchronous concurrent requests, it seems be outdated to provide a batch mode (POST endpoints).
Response
According to current design patterns JSON is assumed as transport format for the RTAC response.
Example
Short hypothetical response to http://somehost/rtac/hrid/12345678
Schema
Preliminary definition the response. This version is far from complete. In the final version it should be capable to transport all attributes of 'holding', 'item' and 'location'.