Content fragments can now be exposed via new AEM HTTP API.[0]
Is it okay to expose content fragments using this api to external applications or should we expose them via experience fragments, content fragments component and sling model exporter? Any recommendations ? With sling model exporter we have control on the JSON output but it requires additional steps from authors to set up experience fragments along with the content fragments.
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @Kunal_Gaba_ ,
It really depends on what your use case is. However, there are two options as per https://docs.adobe.com/content/help/en/experience-manager-learn/sites/content-fragments/content-frag...
From personal experience, I have used 1st method, because we wanted to expose content from AEM in a headless manner to our web application and apps.
We had a use case where we had to create different brand pages, which contained different content fragments and then it is exposed to different channels as a micro-service.
We find it useful to have the contract of the api in form of content fragment model and then flexibility with the authors to change the content in the pages using different content fragments on the pages and expose it through model.json.
The only downside, in my opinion with this approach is that model.json is not much readable, so we developed a micro-service which first transformed model.json in a readable format without nesting and then exposed the response. However, instead of micro-service, you can also do the same thing in Java service/utility in AEM.
Let me know if you want a working example of this approach.
Hope this will help!!
Hi @Kunal_Gaba_ ,
It really depends on what your use case is. However, there are two options as per https://docs.adobe.com/content/help/en/experience-manager-learn/sites/content-fragments/content-frag...
From personal experience, I have used 1st method, because we wanted to expose content from AEM in a headless manner to our web application and apps.
We had a use case where we had to create different brand pages, which contained different content fragments and then it is exposed to different channels as a micro-service.
We find it useful to have the contract of the api in form of content fragment model and then flexibility with the authors to change the content in the pages using different content fragments on the pages and expose it through model.json.
The only downside, in my opinion with this approach is that model.json is not much readable, so we developed a micro-service which first transformed model.json in a readable format without nesting and then exposed the response. However, instead of micro-service, you can also do the same thing in Java service/utility in AEM.
Let me know if you want a working example of this approach.
Hope this will help!!
Views
Replies
Total Likes
Firstly:
Content Fragment - Is of type dam:asset having data without experience.
Experience Fragment - Is of type cq:Page , which will have data and experience.
Any Data stored is content fragment can be exposed as a content service using various ways
Option1: Write custom code , which will return the data to external application in json or xml format.
Pros: Full control on the contract. Any updates to the content fragment model like adding a new field etc will not impact the contract.
Con : Developing a code example using servlet.
Option2 : Use the OOTB new AEM HTTP API
Con: No control on the contract. Any new field additions will impact contract.
Option2: is suggestible for simple integrations.
Option1 : suggestible for complex integrations.
content fragment exposing vis experience fragment --> feel like invalid.
Views
Replies
Total Likes
Views
Likes
Replies