Internal Service APIs
Overview
Documents the internal service APIs.
This is a placeholder page with basic information and will be developed to fully document this aspect of the system.
Details
There is a collection of internal APIs that provide the core functionality. Applications could be developed to use a “within JVM” connection to these services and through JPA lazy initialization entire graphs of objects can be read from the database (in either their current state or any desired past state).
Data model access methods generally take either internal ids or terminology-specific assigned identifiers (e.g. SCTID) and return individual objects without any eagerly initialized connected data. For example, a concept obtained from the content service will simply be a concept entry without descriptions or relationships. Asking a concept for its descriptions will load them automatically from the database. A custom “graph resolver” is used to customize (and normalize) the amount of default information made available at the REST layer.
Methods that create objects make use of a configurable identifier assignment algorithm that can support a variety of modes, including application-managed assignment, assignment of UUIDs based on hashes of “identity” content, or delayed ID assignment until release time. The recommended assignment of concept identifiers is based on the presence of some connected data (parent concepts and FSN description) and the preferred option is to dynamically compute these identifiers as the content changes. This mechanism allows for dual independent review, where multiple authors can create and model the same concept independent of each other followed by a later conflict identification and resolution step. Though this is not required.
In general, methods that find data return search result objects with identifiers (with display labels) that can be used to perform subsequent lookups to retrieve the underlying model objects. These methods typically also take a paging/sorting/filtering parameter to allow for controlled access to the desired amount of data.
General Design
- getXXX methods return objects (and don't take PFS)
- findXXX methods return Lists (and take PFS - and need to fully support it - or throw exceptions).
Security Service
TODO: more details, including use cases
Metadata Service
TODO: more details, including use cases
Validation Service
TODO: more details, including use cases
Content Service
TODO: more details, including use cases
Action Service
TODO: more details, including use cases
History Service
TODO: more details, including use cases
References/Links
- n/a