DCB-ADR-0002 DCB API

Owned by Ian Ibbotson
Jul 08, 2023
2 min read

This ADR addresses the API which will be used for DCB implementation in the POC prototype.

15th October 2022

DCB Hub Discovery Prototype - API

Context:

DCB is a consortial architecture whereby resource sharing is very tightly integrated with the circulation operations of a library network. The ideal is that the extent of this integration renders consortial interlending identical to local patron lending. This contrasts with the peer-to-peer model which underpins the ILL activities supported by mod-rs today. Because of the need to support (a) Possibly different hosting/pod/cluster configurations of “Core” libraries in a network and (b) A extended network of heterogeneous “stand-alone” ILS implementations, an API is needed for a drop-in-replacement “Coordinator” or “Hub” service. Initially, this was seen as extensions and enhancements to the mod-rs component. Reviews of the existing interfaces in this space have demonstrated a number of mismatches between the OAKPI API, upon which mod-rs is founded, and which is strongly opinionated about a number of headers and authentication implementation details and the existing APIs. It may be possible to use edge adapters to massage the headers needed, and possibly the context paths required. A decision is needed which explains our approach to providing the least friction way to onboard existing LSP/LMS clients which we do not control

Decision:

For the POC, the team will build a stand-alone web service component. The existing DCB client ILS systems have equally strong opinions about authentication, tenancy, and API context paths (Specifically, standards-compliant JWT/OAuth and version-information-in-path). This service will not be an OKAPI module, but it will be zero trust. In line with discussions with the project team, the service will use a form of soft multitenancy whereby all holdings are gathered in a genuine union - this will allow libraries to join and leave multiple networks in a data-defined way.

Status:

Current/Done

Consequences:

The module will not be an OKAPI module - because it does not fit that model well. The approach taken will allow us to make an

  • Independently deployable service which is not constrained by the dependency graph of OKAPI

  • A Zero-Trust module

  • A Module that is capable of acting as an in-place drop-in replacement for existing DCB hubs, with the main goal being zero changes for interoperability with existing leaf nodes

Operated as a Community Resource by the Open Library Foundation