We are working on the implementation of new Rest Services in Sitefinity. With this functionality we are aiming to replace the existing backend services, expose Sitefinity data via modern intuitive rest endpoints and make possible and easier the integration with external platforms(link) and services.
We’ve chosen to use OData + WebApi as a framework, because of the tight integration between those two. OData exposes an out of the box protocol and infrastructure that we can leverage to more easily develop this feature and is used among major companies and products which will allow Sitefinity to integrate with those easily.
Configuration for the services:
Here is the structure of the configuration (images attached):
A profile will group a set of types that will be exposed through the service. The profile will also contain a base url for all of the exposed types. Each profile will relate to a separate Route and will contain different metadata depending on the types specified in the configuration. A profiles can have as many types as needed depending on the data to be exposed. Each profile will have to be explicitly entered and enabled in the configuration.
Each profile consists of types. You will be able to register persistent types that you want to be exposed to the outside world. The type has several important configurations available:
- The UrlKey by which to expose the type. For example if the profile has the URL “api/odata”, and you register the news with a UrlKey “news”, the all of the news items will be available at “api/odata/news”;
- Each type can have methods exposed to it. These methods will be used to have more semantic urls. For example if you have the URL query /api/odata/news?$filter = startswith(Title, ‘News’)&$expand=’Tags’&$select=Title&$orderby=DateCreated, this can simple be mapped to the method /api/odata/news/filterednews
Each type will expose three types of properties – Persistent, Navigational, Calculated. For each property you will be able to choose a user-friendly alias that suits your needs. For example if the property name “Content” does not mean anything, you can change that to be served as “Description”.
These represent the properties that are stored in the database and can be modified. Furthermore these properties can be configured to enable Sorting, Filtering. This is handy in case you do not to filter by a property that has no index on it.
These represent the associations for the specified type. For example you can have a registered type BlogPost and you will be able to expose the property “Parent” which will map to the parent Blog item and will be able to be served using the OData query operator “$expand”. Navigational properties will be supported for standard Content relations like BlogPost-> Blog, for Taxonomies and for Related Data.
These represent those properties that will be dynamic and not persistent in the database. For example if you would like to deliver the url of a related image, you can configure a Calculated property – “ImageUrl” that will hold the absolute URL of the related image.
The CRUD operations will follow the OData protocol with some adjustments for sitefinity’s lifecycle.
As per the Odata protocol, there will be endpoints available for modifying the relations of a type(click). For example if you have the relation NewsItem -> Tags, you will be able to use these endpoints to add/remove tags from the NewsItem.
There are still many unknowns.
For example - What kind of security mechanism should we use - should we use the current one or switch to API Keys ?
We would be happy to know that you think of the proposed solution. Are there any specific requirements or requests, which you would like us to address?
We look forward to receiving your feedback!