This code is a supplement to a blog post on episerver.com: Episerver Content Has Always Been Headless
This code represents a proof-of-concept and sample code for manipulating non-visual/non-web content in Episerver. The content object definition (
Person.cs) and controller (
PersonController.cs) effectively form a very limited, bespoke headless endpoint for a specific type of content.
This is not a new feature. It's not even new code. This functionality has been in the product for years.
Episerver has a Content Delivery API. Use that instead of this.
This code exists merely to prove how easy it is to manipulate "pure" content in Episerver, and to demonstrate how Episerver content doesn't need to be traditional "web" content. In no way is this being presented as the correct way to work with Episerver content headlessly.
In data terms, Episerver content is based on a hierarchy of classes. The traditional "web" content is actually built on a foundation of more pure content representations.
ContentData is the abstract representation of content. The
BasicContent class extends from this and allows you to create, manipulate, persist, and delete content objects that have no URL and provide no web rendering.
(For web content,
ContentData extends into
BlockData. There are also classes for
Person object in the sample below can be persisted to and retrieved from the repository. It implements
IVersionable, so it will accumulate versions as you edit. It must exist as the child of a parent object (page, folder, root, whatever -- defined in the
ROOT_ID constant), and it can have children of its own.
Person object has two properties:
Nameis inherited from
Agehas been added directly to
Any property type in the Episerver library is available. From a modeling perspective, classes extending from
BasicContent perform like any other objects.
These objects will never appear in Edit Mode, nor will they have URL -- and they shouldn't, because they're not web content.
They're just...well, content.
(You could effectively "hide" content under pages this way. If you implemented, say, blog comments as
BasicContent, for example, you could make them children of the page they were entered on, which would make them easy to find from code, and they would delete with an "owning" page, but they would never appear in Edit Mode.)
These objects can be managed in Content Manager, since that UI is designed in part to service content outside the web channel. You can create a custom view for the content type, then create, edit, and delete them from the Content Manager UI. Additionally, the content is fully available from C# via
Again, I want to stress -- this is not a demonstration of Episerver's headless capabilities (see our Content Delivery API). This is simply to prove that Episerver is very good at managing content, and any web-specific functions and features are layered on top of that foundation.
These two files should "just work" if compiled into an Episerver installation, with two small changes:
- Change the
ROOT_IDconstant to represent the parent of where the new content should be created
- Ensure the content object represented by
Persontype as child objects via its
When functioning, the following URL patterns will become available (assuming no prior conflicts):
- There is absolutely no authentication on this. If you deploy this as-written, you deserve what you're gonna get.
- The format of the return value is created in the
GetSimplePersonmethod. This is a completely invented format. It's assumed you have your own format you want to return. Go nuts.
- All actions are implemented as GET requests to make it easy to demo and test. Most of these (anything other than
Show) should be re-implemented as POST.
The code is relatively solid and has been reviewed, but this is not something you should deploy to production.
Finally -- and I know I've said this before -- this not representative of Episerver's headless API or capabilities. This is very specific code meant to illustrate a very specific thing.