Breaking changes version 3
Describes breaking changes in version 3 of the Optimizely Content Delivery API.
A breaking change may cause a component to fail. When a breaking change is made to a signature of a method, class, or interface, the former signature is often kept intact but set as obsolete and may cause a warning message in Visual Studio. To delay fixing the warning messages, you can disable Treat Warnings as Errors. Right-click on your project and go to Properties > Build > set Treat Warnings as Errors to Specific warnings or None.
Classes that expose constructors that take dependencies are normally deleted without an obsolete warning in major releases, because the compiler provides information about what you need to change. Keeping those classes makes dependency injection complex because, over time, there would be multiple constructors to choose from that might overlap.
In each major version, obsolete methods are removed permanently to make sure that the API is kept clean and usable. If you could postpone fixing warning messages, you should make sure warning messages are fixed before upgrading to a major version. For version 3, some methods that were made obsolete in prior versions are now deleted.
|Version 2||Version 3|
|ContentApiConfiguration||Obsoleted. Use ContentApiOptions directly instead.|
|Clients||Obsoleted. Use the built-in CORS middleware instead, see CORS in Configuration.|
|IncludeNullValues||Obsoleted. Use IncludeEmptyContentProperties instead.|
|MinimumRoles||Obsoleted. Use ContentDeliveryApiOptions.AllowedScopes instead to control who can make API calls.|
|RequiredRole||Obsoleted. Use ContentDeliveryApiOptions.RequiredRole and/or ContentApiSearchOptions.RequiredRole instead.|
|SiteDefinitionApiEnabled||Obsoleted. Use ContentDeliveryApiOptions.SiteDefinitionApiEnabled instead.|
|Set*||All "Set" methods were removed.|
Changes in class namespaces
In version 3, many classes were moved to internal namespaces, removed, or made public for behavior customization. This section describes the changes, grouped by the most common customization scenarios.
Customize content conversion
The main flow of content conversion can be described as follows:
- Content is acquired by
IContentModelMapper were removed.
IContentConverter, that serves the same purpose, are introduced instead in an internal namespace.
ContentConvertingService were moved to an internal namespace.
To customize the content that is returned, use
IContentModelFilter instead. Also see How to customize data returned to clients.
Customize how data is returned to client
IJsonSerializerConfiguration were removed.
IContentFilter, that serves the same purpose, were made public. See How to customize data returned to clients for more information.
ContentAPIRouteService was moved to an internal namespace.
Classes made internal
In addition to classes mentioned above, the following classes were made internal:
ContentApiModelFilter(from preview to internal)
ContentFilter(from preview to internal)
ISecurityPrincipal was removed and
ContentApiAuthorizationService is moved to an internal namespace. These classes were previously used to customize authorization.
In version 3, the EPiServer.ContentDeliveryApi.OAuth package was replaced by EPiServer.OpenIDConnect. See API authentication.
Following security-related classes and interfaces were removed:
Updated about 1 month ago