Content fragments can now be exposed via new AEM HTTP API.
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.
Use AEM Content Services and Proxy API pages (Video #2) when the primary use case is deliver Content Fragments for consumption (Read-only) by a 3rd party channel. The Content Services framework provides more flexibility and options as to what data gets exposed. Developers can also extend the Content Services framework to augment and/or enrich the data.
Use the Assets HTTP API (Video #3) when the 3rd party channel needs to modify and/or update Content Fragments. A typical use case is ingesting 3rd party content on an AEM author environment.
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.