API Basics
What Are We Dealing With?
At its core, this is a Headless CMS. The CMS UI ("CMS frontend" or "maintenance application") offers a dynamically created user interface based on the required data types for maintaining content. The configuration of the CMS is done via an HTTP/REST API. Data maintenance itself also uses an analogous HTTP/REST API, which is also used by the maintenance application.
How Is Configuration Done?
The term API is used here, which ultimately describes an HTTP/REST CRUD interface to a single object class. An API is created with a description of an object class (POST) and can subsequently also be modified (PUT) and of course deleted (DELETE). Some methods allow the retrieval (GET) of interfaces and their descriptions.
To provide multi-tenancy capability, the name of an API is divided into two parts separated by a slash in a URL, e.g. tutorial/demo1. The first part (tutorial) is called the namespace, the second (demo1) is the unique name of the API in this namespace. For unique namespaces, the concept of reverse domain names can be used to separate tenants — as is common in the Android and Java world, for example.
Why Multi-Tenancy Capable?
In most cases there is naturally only one end customer for whom the CMS is implemented. However, it is often the case that multiple service providers create different software applications for a project. Tenants are therefore in this case different service providers, i.e. companies that may want to use their own namespace for their software in a project. So a tenant also has a namespace in the form: Tenant/ Data_for_xy
How Is Data Maintained?
Once an API is created, an HTTP/REST CRUD interface for maintenance is automatically offered. When creating (POST) and changing (PUT) data, it is checked against the description of the object class. For this check, the fastest-validator is used as a basis, which can be used in both client and server. The generic CMS UI can not only build suitable forms using this description but also perform preliminary checks in advance — certainly not completely, since some checks are only possible on the server.
What Access Protection Is Available?
A rights system allows not only multi-tenancy capability to be established via namespaces. Rather, restricting access to data is also possible.
Note: Currently a distinction is made between read and write rights on entire objects. A future extension could break down the rights to individual fields.
How Best to Get Started?
A small tutorial in the chapter after next already describes the first steps, but it will probably only get interesting in the details. The tutorial is however important to understand the few basics needed to communicate with the CMS.
Even if it is actually secondary at first, one should first become familiar with the basic security concept. After understanding the API interface, you know everything necessary for configuring the CMS.
But actually these are all one-time actions; much more interesting is actually the data interface with which data can be brought into the CMS, read out, modified, and deleted again. This interface is actually so simple that even a very brief introduction here will be enough to work with the CMS.
Note: Currently there is a pure CRUD interface. With further development of the CMS there are certainly enough ideas for HTTP/POST actions beyond this, which can then be integrated via extensions.