Master Data Holder
How can I design an API that provides access to master data that lives for a long time, does not change frequently, and will be referenced from many clients?
- from
- Integration
- added
- 2026-10-10
- likes
- 0
similar
-
Reference Data Holder microservice-api-patterns.org
How should data that is referenced in many places, lives long, and is immutable for clients be treated in API endpoints? How can such reference data be used in requests to and responses from Processing Resources or Information Holder Resources?
-
Operational Data Holder microservice-api-patterns.org
How can an API support clients that want to create, read, update, and/or delete instances of domain entities that represent operational data: data that is rather short-lived, changes often during daily business operations, and has many outgoing relations?
-
Data Element microservice-api-patterns.org
How can domain/application-level information be exchanged between API clients and API providers without exposing provider-internal data definitions in the API? How can API client and API provider be decoupled from a data management point of view?
-
Information Holder Resource microservice-api-patterns.org
How can domain data be exposed in an API, but its implementation still be hidden? How can an API expose data entities so that API clients can access and/or modify these entities concurrently without compromising data integrity and quality?
-
Linked Information Holder microservice-api-patterns.org
How can messages be kept small even when an API deals with multiple information elements that reference each other?
-
Eternal Lifetime Guarantee microservice-api-patterns.org
How can a provider support clients that are unable or unwilling to migrate to newer API versions at all?
Integration › Integration Patterns > Microservice API Patterns: “How can I design an API that provides access to master data that lives for a long time, does not change frequently, and will be referenced from many clients?”