Assets

Assets represent the smallest units of managed content in Oracle Content and Experience. For example, each specific article based on the content type Article is an asset of its own and managed individually.

Once a content type is added to a repository, anyone with access to the repository can see and create assets of that content type. For example, let’s have another look at the content type called Article, which was already mentioned earlier. It has four data fields (title, body, author, and picture). The data field author is a reference to the content type Author, which has three data fields: two images (a large photo and a small avatar) and biography text.


Description of headless_assets_article_content_type.png follows
Description of the illustration headless_assets_article_content_type.png

Description of headless_assets_author_content_type.png follows
Description of the illustration headless_assets_author_content_type.png

A content author can now go into the repository that the content type is associated with and create a new content item based on the Author or Article content type, as well as any media content associated with them (for example, photos).

Description of headless_assets_create_asset.png follows
Description of the illustration headless_assets_create_asset.png

This will open auto-generated forms for creating assets of a specific content type, showing all data fields defined for that content type. For example, the Article form would look as shown in the following image, where each field type shows up with a specific editor (as configured when the content type was created), so content authors can create content in a way that makes sense.


Description of headless_assets_article_form.png follows
Description of the illustration headless_assets_article_form.png

Once created, all content items appear in the associated asset repository.


Description of headless_assets_new_article.png follows
Description of the illustration headless_assets_new_article.png

Assets exist both in a management context and in a delivery context (after publishing). For an authored content item to be used in an application, it must first be published, so the asset is available in the delivery context. We’ll mostly focus on the delivery context here as that is of primary interest to developers. See Managing Assets with Oracle Content and Experience for more information on assets from a management perspective.

Once published, each asset is available as a REST resource. The address to the resource can be found as part of the content item properties.


Description of headless_assets_asset_properties.png follows
Description of the illustration headless_assets_asset_properties.png

Let’s explore what such a REST resource looks like in the delivery context. First, the URL has a specific form:

http://. . ./content/published/api/v1.1/items/CORE05DB981E7DA9470D844310E3053B2
682?channelToken=9f817f8edb7f4c38add244cd39bdd18b
  • The access context identifier /published indicates that this is about delivery of published content.
  • The object identifier /items indicates that we’re working with content items (and not other object types).
  • This is followed by the identifier of the asset, which is a series of letters and numbers; for example, CORE05DB981E7DA9470D844310E3053B2682. Each asset has its own unique identifier.
  • This is followed by a query parameter, channelToken, which is an identifier for the channel that this asset has been published to. It’s the context in which the asset is being accessed.

The body of the response for this resource corresponds to data that was entered when the content item was created. It looks something like this:


Description of headless_assets_rest_response.png follows
Description of the illustration headless_assets_rest_response.png

Fields in green are all standard fields; they are present in every asset. One such standard field is the unique identifier (id) of the asset. The other standard fields are the asset type, name, description, slug, language, translatability status (translatable), and the creation and update dates (createdDate and updatedDate).

A child-node field contains all user-defined field values, such as title, body, or whatever else was specified in the content type definition.

Any reference fields (such as the author field in the preceding example) don't contain the complete data set for the author asset, but merely an identifier, name, type, and a link to the author asset. Following that link leads to the complete author asset.

Looking at the picture field, you may notice that this looks very much like the author field. In fact, a Media field (the data type for the picture field) is actually a reference field behind the scenes. It's a reference to an out-of-the-box type called DigitalAsset (which is why type under the picture field says "DigitalAsset").

Suppose you want to access all of the author field along with the article without having to incur additional network calls. You can easily do that by simply adding expand=fields.author as a query parameter, and the author field expands inside the Article response, as shown in the following image (see the section marked bold and italics).

"id": "COREF6925F275F854B5598BA7B830A0E303D",
  "type": "Article",
  "name": "First article",
  "description": "Lorem ipsum dolor sit amet",
  "slug": "1481786083723-first-article",
  "language": "en-US",
  "translatable": true,
  "createdDate": {
    "value": "2019-10-22T10:30:35.164Z",
    "timezone": "UTC"
  },
  "updatedDate": {
    "value": "2019-10-22T10:30:35.164Z",
    "timezone": "UTC"
  },
  "fields": {
    "title": "Lorem ipsum dolor sit amet",
    "body": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna 
aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute 
irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non 
proident, sunt in culpa qui officia deserunt mollit anim id est laborum",
     "author": {
      "id": "CORE05DB981E7DA9470D844310E3053B2682",
      "type": "Author",
      "name": "John Doe",
      "description": "John",
      "slug": "1481786083700-john-doe",
      "language": "en-US",
      "translatable": true,
      "createdDate": {
        "value": "2019-10-22T10:30:35.164Z",
        "timezone": "UTC"
      },
      "updatedDate": {
        "value": "2019-10-22T10:30:35.164Z",
        "timezone": "UTC"
      },
      "fields": {
        "author_image_header": {
          "id": "CONT069975B56A3044BEB8A18ADA1587C765",
          "type": "DigitalAsset",
          "name": "hk.jpeg",
          "links": [
            {
              "href": "http://. . ./content/published/api/v1.1/items/CONT069975B56A3044BEB8A18ADA1587C765?channelToken=9f817f8edb7f4c38add244cd39bdd18b",
              "rel": "self",
              "method": "GET",
              "mediaType": "application/json"
            }
          ]
        },
        "author_bio": "Great writer!!",
        "author_image_avatar": {
          "id": "CONT069975B56A3044BEB8A18ADA1587C765",
          "type": "DigitalAsset",
          "name": "hk.jpeg",
          "links": [
            {
              "href": "http://. . ./content/published/api/v1.1/items/CONT069975B56A3044BEB8A18ADA1587C765?channelToken=9f817f8edb7f4c38add244cd39bdd18b",
              "rel": "self",
              "method": "GET",
              "mediaType": "application/json"
            }
          ]
        }
      },
      "links": []
    },
    "picture": {
      "id": "CONT337B107EAF904296B382BE08C82A08B8",
      "type": "DigitalAsset",
      "name": "pexels-photo-134602.jpeg",
      "links": [
        {
          "href": "http://. . ./content/published/api/v1.1/items/CONT337B107EAF904296B382BE08C82A08B8?channelToken=9f817f8edb7f4c38add244cd39bdd18b",
          "rel": "self",
          "method": "GET",
          "mediaType": "application/json"
        }
      ]
    }
  },
  "links": []
}