Deprecated

Note that as of version 6.2 of Ceptor, the REST services mentioned here are all deprecated, and replaced with OpenAPI versions, available exposed on an internal Gateway.

Refer to default configuration for more info.

Ceptor (from version 5.70 and onwards) supports fetching statistics and different status information through rest services.

Launcher Configuration

In order to get the Rest services enabled the services startup must be configured in the ceptor_launch.xml. The Rest services do not require its own JVM to run, so if the existing capacity can handle it, it could as an example be a service defined in the session controller classloader/JVM – for example like this:

<classloader name="restservices">
  <service name="restservices" launcherclass="dk.itp.security.rest.RestServicesLauncher">
    <property name="restservice.status" value="true"/>
    <property name="restservice.statistics" value="true"/>
    <property name="restservice.admin" value="false"/>
    <property name="restservice.agent" value="false"/>
    <webserver webapp="${portalprotect.home}/ppserver/restservices" httpport="5300" />
  </service>
</classloader>

However if the load is not controlled it can take significant CPU time and a separate JVM might be a good idea to instantiate.

The two launcher properties that can be configured are:

restservice.status – used to enable the status rest service, can be true/false – default is true
restservice.statistics – used to enable the statistics rest service, can be true/false – default is true
restservice.admin – used to enable the admin client rest service, can be true/false – default is false
restservice.agent – used to enable the agent rest service, can be true/false – default is false

The status, statistics and admin rest services can be accessed either by having a valid session id provided in the HTTP header or by providing an admin userid/password in the configuration which will be used for accessing the data.

The agent rest service does not support this and requires a valid sessionId for each request to be able to access the REST methods - the sessionId is provided through the REST arguments for the agent REST service methods.

Some methods in the agent rest interface require proper setup of the agent (it should either be in the same classloader as the application it supports or it must have proper configuration to be able to access for example the correct authorization methods.

A typical configuration

<server name="restservices" type="app" description="RestServices server" extends="applications">
  <group name="general" description="general configuration">
    <property name="sessioncookiename" value="sessionid" description="The name of the session cookie used to login if admin.logintype=sessionid"/>
    <property name="json.prettyoutput" value="true" description="Formats the output JSON object data in a pretty readable way (takes more bandwidth)"/>
    <property name="admin.logintype" value="userid" description="Type type of login used towards the admin client. Valid values are sessionid and userid"/>
    <property name="admin.credentials.user" value="user1" description="The user ID used if admin.logintype=userid, not used otherwise"/>
    <property name="admin.credentials.password" value="{encoded}94E3EF8563BE8C03" description="The password if admin.logintype=userid, not used otherwise - clear text or encoded as normal"/>
  </group>
  <group name="statistics" description="cluster server configuration">
    <property name="functioncache.timeout" value="5" description="Function cache timeout in seconds"/>
    <property name="statuscache.timeout" value="5" description="Server status cache timeout in seconds"/>
    <property name="webstatuscache.timeout" value="5" description="Server status cache timeout in seconds"/>
  </group>
</server>