Data Layer API specification
This document is for illustration and discussion only. It has no official standing.
- Add references to the gedragsprofielen digitaal erfgoed.
- Make a clean separation between the specification of the interface and the behaviour of the data layer (what it must or should do).
- Include a 'Metamodel Informatiemodellering' (MIM), explaining the information model on which the API is grounded.
Introduction
This document defines API specifications for the exchange of heritage information between data layers and presentation layers within the Dutch Digital Heritage Network (NDE). By standardizing data layer interfaces, we enable presentation layer developers to build generic API clients that are compatible with any data layer, reducing the need for custom integrations.
To be discussed: is the name API Specifications a sound one? It could suggest concrete specifications, whereas they're a bit more abstract. Alternatively, API Framework or API Interoperability Framework?
Version
The document describes version 0.0.1 of the API specifications.
This is the initial development version, version zero. Breaking changes are introduced within the same major version, following semantic versioning for version zero.
Definitions
- A data layer combines heritage information from multiple data providers and exposes it through an API for use by one or more presentation layers.
- A presentation layer uses heritage information from data layers and makes it accessible to end users, e.g. via websites or mobile apps.
Audience
This document is intended for:
- Data layer developers building compliant APIs.
- Presentation layer developers building generic clients that work across various data layers.
Conformance
The keywords MAY, MUST, MUST NOT, OPTIONAL, SHOULD, and SHOULD NOT are to be interpreted as described in RFC 2119, when, and only when, they appear in all capitals, as shown here.