If you missed the Episerver update 296 release notes or the Episerver Features February 2020 announcement – then this post is for you, because you have missed some important information about Episerver Content Delivery API. So keep on reading..
Episerver Content Delivery API new feature: support for local blocks
Before version 2.9.0 of Content Delivery API if you had used Episerver block (local block) as a property on a content type, then that property was not serialized to the Content Delivery API response – but starting from Content Delivery API version 2.9.0 local blocks are now supported (here is the feature ticket).
A simple sample can be made with the Episerver Alloy MVC site. The sites start page has used a local block as the logo type property. After installing Content Delivery API version 2.9.0 or newer, when you request the start page from Content Delivery API you also get the information about the logo type. Here is a screenshot from WinMerge comparision for version 2.6.1 VS 2.10.0 response where we can see that the local block is now included in the response (and also you can see that some properties now include “expanded” property).
Episerver Content Delievery API new options
Four new options where introduced in update 296 (copied from release notes):
- ValidateTemplateForContentUrl: Enable/Disable the validation of content URL. For example, this option should be set to false if you want to get the URL of a content folder
- FlattenPropertyModel: If this option is set to true, the response JSON will be flattened
- IncludeNullValues: If this option is set to false, the JSON serializer will ignore all null values in the response
- IncludeMasterLanguage: If this option is set to false, the response model of content will not contain the MasterLanguage property
All these new options are used in the Content Delivery API configuration module but at the time of this post writing that information is missing from the official Content Delivery API configuration documentation.
See the configuration used at the end of the page.
If we call in configuration to SetIncludeNullValues(false) and then compare the Content Delivery API output we can see that it has done exactly what is described, it has removed the null values:
Normally the Content Delivery API would have MasterLanguage property but when we set this to false that property is excluded from the output.
This option when set to true (default is false) has a big impact to the Content Delivery API output and I would say this is the option that the front-end developers have asked for, simple and “less verbose” model out-of-the-box (there is still information that most likely is not needed in front-end, but at least the model is now a bit simpler).
By default the Content Delivery API validates that there is a template for the content requested. So for example in the Alloy MVC sample site there are container page types which don’t have a template (ContainerPage tagged with IContainer) and this means that there is no public url to browse to with a browser. Alloy MVC for example has page “How to buy” which is a container and you cannot browse to that page with a browser. Now if we configure Content Delivery API with SetValidateTemplateForContentUrl(false) the template validation is skipped and url for the container page is generated to the response JSON.
So here was a quick look at the new Content Delivery API feature and new options. I believe these were things that front-end developers have been waiting for (and backend developers too :D). These additions take the Episerver Content Delivery API to the next level in the out-of-the-box category 🙂
Here is the configuration which was used in the samples: