In this part of the AEM Headless Developer Journey, learn how to use the REST API to access and update the content of your Content Fragments.
In the previous document of the AEM headless journey, How to Access Your Content via AEM Delivery APIs you learned how to access your headless content in AEM via the AEM GraphQL API and you should now:
This article builds on those fundamentals so you understand how to update your existing headless content in AEM via the REST API.
In the previous stage of the Headless Journey, you learned about using the AEM GraphQL API to retrieve your content using queries.
So why is another API needed?
The Assets HTTP API does allow you to Read your content, but it also allows you to Create, Update and Delete content - actions that are not possible with the GraphQL API.
The Assets REST API is available on each out-of-the-box install of a recent Adobe Experience Manager as a Cloud Service version.
The Assets HTTP API encompasses the:
The current implementation of the Assets HTTP API is based on the REST architectural style and enables you to access content (stored in AEM) via CRUD operations (Create, Read, Update, Delete).
Content Fragments are used for headless delivery, and a Content Fragment is a special type of asset. They are used to access structured data, such as texts, numbers, dates, amongst others.
The Assets REST API uses the
/api/assets endpoint and requires the path of the asset to access it (without the leading
For example, to access
/api/assetsdoes not need the use of the
/content/path/to/pagedoes require the use of the
The HTTP method determines the operation to be executed:
The request body and/or URL parameters can be used to configure some of these operations; for example, define that a folder or an asset should be created by a POST request.
The exact format of supported requests is defined in the API Reference documentation.
Usage can differ depending on whether you are using an AEM author or publish environment, together with your specific use case.
It is strongly recommended that creation is bound to an author instance (and currently there is no means to replicate a fragment to publish using this API).
Delivery is possible from both, as AEM serves requested content in JSON format only.
Storage and delivery from an AEM author instance should suffice for behind-the-firewall, media library applications.
For live web delivery, an AEM publish instance is recommended.
The dispatcher configuration on AEM cloud instances might block access to
For further details, see the API Reference. In particular, Adobe Experience Manager Assets API - Content Fragments.
Usage is via:
The response is serialized JSON with the content structured as in the content fragment. References are delivered as reference URLs.
Two types of read operations are possible:
Usage is via:
The body has to contain a JSON representation of the content fragment to be created, including any initial content that should be set on the content fragment elements. It is mandatory to set the
cq:model property and it must point to a valid content fragment model. Failing to do so will result in an error. It is also necessary to add a header
Content-Type which is set to
Usage is via
The body has to contain a JSON representation of what is to be updated for the given content fragment.
This can simply be the title or description of a content fragment, or a single element, or all element values and/or metadata.
Usage is via:
For further details of using the AEM Assets REST API, you can reference:
Now that you have completed this part of the AEM Headless Developer Journey, you should:
You should continue your AEM headless journey by next reviewing the document How to Put It All Together - Your App and Your Content in AEM Headless where you will get familiar with the AEM architecture basics and tools you need to use to put your application together.