Every CapObject and CapType is equipped with a stable string ID that can be persistently stored and converted back into an object reference as needed. To this end, CapObject has got a method getId() for retrieving the ID. Methods for converting IDs into object references are typically provided by the repository objects.

Every ContentObject and every Member on the Content Management Server also has an additional UUID, a stable and universally unique identifier as defined in RFC 4122. ContentObjects have the same UUID on Live Servers, if they were created by publication or replication with release 2210.1 or newer. ContentObjects that have been created with an older release do not have UUIDs on Live Servers, but Content UUIDs can be added as described in Section 3.13.2.4, “Content UUID Migration and Transfer” in Content Server Manual.

UUIDs are not meant as replacement of simple string IDs, but make sense in certain scenarios. For details on ContentObject UUIDs, have a look at Section 5.2, “UUIDs”. For details on Member UUIDs, have a look at Section 7.2, “UUIDs”.

It is recommended that you treat the string IDs as opaque strings, because the exact format of the strings might change in future releases of CoreMedia CMS. Still, CoreMedia provides detail information about the IDs for the purposes of debugging and for interfacing the Unified API with legacy clients which might insist on using numeric IDs.

The class com.coremedia.cap.common.IdHelper is provided for formatting and parsing all sorts of ID strings. Note that all methods in that class may be redefined arbitrarily in the next CoreMedia CMS release.

The following table summarizes the various ID formats for CapObjects.

The CapTypes are also identified by an ID.

There are some other objects that are also assigned an ID, but that do not implement CapObject or CapType. Such objects implement the method getId(), but they do not provide getters and setters for properties.

Unified API objects that define a string ID are equal in the sense of Object.equals(Object), if and only if their string IDs are equal and if they belong to the same Unified API connection.

Figure 4.4. Class Diagram: Repositories and Identified Objects

It is recommended to use string IDs only when a string representation is needed. The identified objects of the Unified API are lightweight, so that it makes no sense to store IDs in main memory for a long time. IDs are more difficult to handle and often larger than their object counterparts. IDs are useful for some administrative command line tools and for generating debugging output.

If you need to reference content externally, like in a database or file, it's recommended to store the UUID of the content instead of its ID. Simple string IDs will not stay the same if content is exported and imported, for example when it is transferred between different Content Servers. Content UUIDs can be used, if stable references are needed.