Decoupled/Headless CMS Details

Obtree WCM as REST source

Obtree WCM is fully dynamic and has a number of built-in options for rendering objects directly in response to a URL request:

  • Assigning a URL to an object
  • Calling built-in SOAP interfaces
  • Bespoke script handlers

These options can all deliver object content in response to a URL request, but the details and complexity differ. Therefore, specific implementations of this concept for Obtree WCM will likely be tailored to your requirements.

Object URLs

There are about 10 Obtree object types - Page, Template, Picture, Datatable etc. - which hold and manage different types of data. The core properties for all object types include the ability to assign a URL. By default, only Pages, Images and Link objects require a URL - because these are naturally called via a browser. However, any object can potentially have a URL assigned. Once one is assigned, the object can be requested directly in a browser via its URL.

In the context of surfacing authored content via a REST interface, the object type most relevant is the TEXT object. Normally, these are embedded within templates and assembled pages and are never requested in isolation. The other object type that may have manually authored content is the DATA object type, so it may be necessary to expose these as well. Assigning a URL to objects of either type will result in the unparsed content being rendered in the browser.


  • Straightforward to implement
  • Straightforward to automatically bulk apply URLs with a simple script
  • Minimal consultancy time needed


  • Unparsed content will likely include system tags (styling, formatting etc.) being rendered to the browser. This may cause visual artefacts
  • No exposed index of available objects [though bespoke endpoints can be created to list available objects]

SOAP interface

The core configuration of Obtree WCM allows the exposure of a number of system-manipulation SOAP APIs. These are primarily used by the editing tools but can of course be called directly.

Therefore, it is possible to create a client application that can access the object API in order to retrieve text cotent.


  • Core product
  • Can list objects as well as return single objects
  • Can manipulate objects via SOAP API if desired (though of course this requires considerably greater client complexity)


  • Requires more complex client connector to extract the content from the returned XML
  • It is an old SOAP style

Bespoke interface

As indicated above, any object type can be assigned a URL. This includes the server-side script objects. Therefore a bespoke interface layer can be written to match your requirements within a script, and this exposed as a bespoke SOAP or REST API.

Further, it is possible to programmatically parse an object and convert the system tokens into their correct output values. This parsing can be buffered, so the final string to return to the browser can be generated and held until requested by the browser. Therefore, we can retrieve text with all the styling flags converted into their proper HTML values. Note of course that any references to CSS classes or IDs will require your own CSS stylesheet.


  • Can tailor the interface to your requirements
  • Can filter, page and list objects as well as return single objects, dependant on the requirements
  • Can ensure that correctly processed text is returned to the browser


  • Requires a higher development effort.