We can use the .NET SDKs from the headless CMS vendors to retrieve data and evaluate the JSON formats uses to represent Entries in each system. While we should use strongly-typed Entry Model classes as described in the blog post https://deliverystack.wordpress.com/2020/07/20/net-core-headless-cms-entry-models-and-entry-model-classes/, we can evaluate the raw JSON to see how the systems represent data, what data is available, potential challenges in parsing that data, potential performance impact of storage formats, and so forth.
First, create a Content Type in each system. For demonstration purposes, I created Content Types with number, single-line text, date or datetime, asset, and rich text fields. Where possible, I indicated that the Fields could repeat (contain multiple values).
In each system, I created a Content Type named FieldTypes. I could not figure out how to allow any Fields to repeat within a Contentful and Kentico Kontent Content Types. Each seems to have support for groups/nesting/referenced Entries and lists, but those are relatively advanced or irrelevant features and I want to try to keep things simple for now. The Contentful field for selecting Assets allows the CMS user to select multiple Assets.
Below is the code that I used and the output for each. In some cases, the JSON includes not only the Entry, but results from the RESTful API call. Note that the JSON visible here may not exactly match the JSON retrieved from the CMS; the JObject used to store the original JSON may serializes to a different JSON format than the original.
Sorry for the pastebins but this WordPress Rich Text Editor is reminding me of one reason to run as fast as you can whenever anyone mentions content management.
Contentful Fetch Entry with C#
Contentful Entry JSON Representation
Contentstack Fetch Entry with C#
Contentstack Entry JSON Representation
Kentico Kontent Fetch Entry with C#
Kentico Kontent Entry JSON Representation
Snippy-Quick Analysis
From this, we can see a few things:
- The systems all provide basically the exact same functionality. Even the code is almost identical, although Kentico allows queries across Content Types where the others do not (although I think that there are ways to achieve this with at least Contentful with something like deriving Content Types from a base Content Type; see https://www.contentfulcommunity.com/t/how-to-query-on-multiple-content-types/473).
- The JSON payloads include significant metadata that consuming applications are unlikely to use, which reduces performance. To me, the schema definition data belongs in the Content Type rather than the individual Entries.
- Because some CMS allow fields to repeat/contain multiple values and others do not, we cannot use the same Entry Model for all CMS (unless we redefine the fields to support only single values).
- Contentstack and Kentico both inline metadata from Assets into the JSON representation of the Entry, which can have advantages. Contentful likely provides an option to do the same rather than requiring additional RESTful API calls to retrieve Asset metadata.
- Contentful uses a proprietary format to represent HTML as JSON. Theoretically, this could have advantages in some cases, but approximately 100% of the time I would want HTML rather than JSON, so this is going to be a hassle that consumes bandwidth and CPU cycles to transfer and convert. This presents coding challenges because our Entry Models should not contain CMS-vendor-specific code, but we have this vendor-specific format to manage. This issue deserves its own blog post (//TODO: link).
Deliverystack.net 
4 thoughts on “Entry Data Formats in Headless CMS”