AEM Headless with Site API

AEM offers different approaches to implement headless solutions: Content Fragment with GraphQL and “hybrid” with pages, Sling Models and a REST API. This talk will give you an overview and a comparison to find the sweet spot for your needs.

Further down the road using the hybrid approach, we introduce the Site API set of modules, which makes it easy to provide an efficient REST API with consistent handling of media and link references and context-aware configurations and a simple-to-use alternative to the SPA editor.


Can we expose content fragments via this site api?

(see answer in talk video)
How versioning is maintained for Sites API?
(see answer in talk video)

Vugar Aghayev

How difficult it’s to extend the Site API with a new selector to expose content which is not covered by the OOTB selectors and make sure this content is excluded from the existing selectors e.g navigation

(see answer in talk video)


Does the Generic View support XF reference?

(see answer in talk video)


Could this be used in conjunction with the universal editor? I believe I've mixed up some of the responsibilities of the universal editor and something like Franklin. It seems like this is custom built for both.

Stefan Seifert

basically yes. in my understanding universal editor could be used to edit more or less anything - and adobe is definitely working also on support for pages+components in addition to CF. but it would be a completely separate *additional* edit mode to the AEM page editor.

What’s your take on Adobe’s SPA Editor approach?
(see answer in talk video)

Ben Peter

Have you considered using API Mesh on top of the "REST API" approach?

Stefan Seifert

you are referencing to no, i've not looked in detail into this so far.

Tomasz S

What is your experience with this approach and content modeling for omni channel content? Does this mean that content is modelled for web and then other channels need to cherry pick from various pages then content they need?

Stefan Seifert

our goal ist to use the same JSON for all channels, so it should be modeled carefully. in our experience this works very well with the hypermedia approach. one point to consider are rich text fragments. we usually put rich text as HTML code in a JSON property - which is a bit ugly. we make sure that all link references are rewritten properly to follow the hypermedia approach. but it requires that the client apps are capable of parsing simple HTML markup. you could use a custom transformation.


Authering content fragment seems tedious for author especially when there are nested fragments. Is there any advice to improve the author experience?

Stefan Seifert

well, the point is that i propose to use the traditional AEM page editor with pages and components. on the other hand, editing CFs in the author has greatly improved in most recent AEMaaCS releases (content fragment console), so be sure to try that out. not available in AEM 6.5 to my knowledge (also not in local AEMaaCS SDK).