The Content Service provides two main key features: a fully headless CMS and application specific theme fields.
The headless CMS functionality is provided by a few main entities within the service.
The first is the ContentModel
. This entity is responsible for setting up the metadata about how content is managed. It defines what fields are available, their types, which are required and other useful information that can be used when configuring the actual content. A content model can also specify that it is a "page type" with the use of a Uri. This is useful when creating content like landing pages.
A ContentItem
is the actual piece of structured content that will be presented to the user. The fields available for any given content item are defined by the associated model.
The final entity is the ContentZone
. These allow the user to define specific zones on a page where content can be placed. This is useful when creating content like banners and ads where the user may want to define rotating or targeted content.
Because this is a Headless CMS, it is up to the customer facing frontend application to decide how to display any piece of content retrieved. The response from the ContentItemResolverEndpoint
includes each content item’s model and associated information to help decided how it should be displayed to the user.
The purpose of the ThemeField
domain is to provide a way to allow admin users the ability to tweak settings that may have been previously hardcoded into the frontend application. Examples of this might include primary and secondary colors, application information or properties, etc. In a multi-tenant context, theme fields can be defined at the tenant level and inherited down to the individual applications where the default values can be overridden.