NeuroomNet CMS for software developers
What are we dealing with here?
At its core, this is a headless CMS. The CMS provides content via an HTTP/REST interface; how it is displayed is up to the respective application. A generic editing application (/form) builds its input forms dynamically from the description of the data.
The CMS is configured exclusively via the HTTP/REST interface. Data maintenance also uses such an interface, the same one that the editing application uses.
Terms
| Term | Meaning |
|---|---|
| Namespace | First part of an API name, e.g. tutorial. Separates tenants and is the boundary for rights. |
| API | Description of an object class (schema) together with the associated records, e.g. tutorial/demo1. An API provides an HTTP/REST CRUD interface. |
| Record | A single object of an API. |
| Field | A property of the object class, with data type and validation rules. |
| Project, Application | Optional details in the schema for grouping APIs in the project view of the editing application. |
How is configuration done?
An API is created with a description of its object class (POST), can be changed afterwards (PUT), and deleted again (DELETE). Further calls (GET) return the existing namespaces, APIs, and their descriptions. Details: API configuration.
Why multi-tenant?
The name of an API consists of two parts, separated by a slash in a URL, e.g. tutorial/demo1. The first part (tutorial) is the namespace, the second (demo1) the name of the API, unique within this namespace.
Usually there is only one end customer for whom the CMS is operated. Often, however, several service providers create applications for a project. In this case, the tenants are the individual companies, each using its own namespaces for its applications. The reverse domain name scheme, as is common in the Android and Java world, is well suited for unique names.
How is data maintained?
Once an API has been created, an HTTP/REST CRUD interface for maintaining its records is automatically available. When creating (POST) and changing (PUT), the data is validated against the description of the object class. This is based on the fastest-validator, which is used in both client and server. The editing application can thus not only build suitable forms but also validate in advance. Some validations, however, are only possible in the server.
Details: Data interface.
What access protection is there?
Access is exclusively encrypted and always requires authentication. A rights system based on namespaces separates tenants and restricts access to data. A distinction is made between read and write rights on entire records; there are no rights on individual fields.
Details: Rights and accounts, Authentication.
How best to get started?
- The quick start shows the first steps and conveys the few basics for communicating with the CMS.
- After that, it is worth taking a look at the rights concept.
- With the API configuration and the data types, you know everything needed to set up the CMS.
- These are one-time actions, though. In everyday use, what matters most is the data interface with the queries, through which applications obtain their content.
If you first want to put the CMS into context for a project, start with the overview.
Where do I find the CMS?
A local CMS runs in a NeuroomNet installation. The address is https://<name or IP of the server>:444; the editing application is located at /form. In addition, a CMS can be operated on the internet, for example during the development phase of a project. The operator provides the specific address.
In the examples in this documentation, https://cms.example.org stands for the address of the CMS.