Here is the list of REST API that's currently available in CMS. This article gives you instructions on how to add a new REST end point in CMS.
Add A New Type of Element to be managed by REST CMS
From this diagram, you can actually see the FOUR major components you need to create in order to have your element managed by the REST CMS: a controller, a configuration manager, a configuration validator and a configuration realizer.
Controller
In order to add a rest end point, we will need a controller entry point to handle the request. You can see RegionManagementController as an example. Here is a few things you need to pay attention to:
- @ApiOperation: this is to make your rest end point available in Cli. The value attribute of this annotation will be the name of the command line to invoke this rest end point. If this rest end point is a list/get type of operation, you can provide an optional 'jqFilter' attribute to filter out the json response as a tabular result to this cli command. Command line users can override this jqFilter by providing their own when executing this command, this attribute is there only as a default filter.
- @PreAuthorize: specifies the permission needed to execute this rest end point.
- Don't put too much logic in the controllers. The controller should simply use the request parameters, form them into the arguments that cluster management service API accepts and return the results.
The moment you want to call the CMS API, you find yourself in need of two basic types for your Element: a Configuration object and a RuntimeInfo.
Configuration Object
This objects specifies how you want to configure this element like Region, Index, GatewayReceiver etc. To get started, consider only adding those attributes that you want to expose through rest api. For example, although according to the cache.xsd, a region can be configured with many attributes (see RegionConfig, which is generated by the jaxb service using the cache.xsd file), in rest management api, we don't want to overwhelm users, so we only expose those that are more commonly used. That would require us to expose a different configuration object called Region (better to put all configuration object in one package).
Your configuration object should either extend AbstractConfiguratioin if you can only configure one of it in the entire cluster (like PDX, can only be defined in the cluster level), or GroupableConfiguration if there could be one per server group (like region). There are also interfaces your configuration needs to consider adding: RegionScoped and HasFile. If your configuration lives under the Region element in cache.xml (like Index), then your configuration object needs to implement RegionScoped. If your object has file content (like Deployment), then it needs to implement HasFile. Note if your object implement RegionScoped, then you need to extend AbstractConfiguration, not GroupableConfguration.
When you create your Configuration object, you notice you will need to type it with a RuntimeInfo. This is used to tell the framework what's the corresponding RuntimeInfo object this configuration object is related to. For example, Region is related to RuntimeRegionInfo, which give more information about the state of the region on each server, that's why Region extends GroupableConfiguration<RuntimeRegionInfo>. If your configuration object doesn't have any corresponding runtime information, you can simply type it with the abstract class itself, like <code>class XYZ extends AbstractConfiguration<RuntimeInfo></code>.
RuntimeInfo Object
Like said above, this object collects runtime information about this configuration object on each server. For example, entry count for the region, specific jar location on each server about each deployment etc. If you don't need to collect any runtime information for your configuration object, you don't need to implement this.
Configuration Manager
Now that you have the configuration object ready, you will need to create a ConfigurationManager that tells the framework how this object is to be managed by the configuration service. If your configuration object is part of the cache xml, your configuration manager should extend CacheConfigurationManager. If your object affects other parts outside cache.xml, like jar deployment or runtime properties, you will need to extend its parent class ConfiguratioonManager.