Content can be created as Content Fragments and Editable Templates to create the Content Service API
The key concept with Content Fragments, is the authored content is presentation-agnostic, meaning its intended for multi-channel use where the consuming application, be that AEM, a single page application, or a Mobile app, controls how the content is displayed to the user.
The primary concern of the Content Fragment is to ensure:
The correct content is collected from the author
The content can be exposed in a structured, well-understood format to consuming applications.
This chapter covers enabling and defining Content Fragment Models used to define a normalized data structure and authoring interface for modeling and creating “Events”.
3. How could the front end consumes AEM Experience Fragments?
Any content can be consumed in JSON format by any other service once they are exposed as CaaS.
Update : I will try to answer below question asked in the comment of this Reply
Everything looks similar between regular AEM and Headless AEM implementations. Then What is the difference in efforts estimation/implementation between regular AEM and Headless AEM?
I agree that to some extend but the fact is the effort is much lesser compared to the Regular AEM project , where you need to estimate for the UI effort , design the components and all the thinks included in deploying it as the final AEM website/portal . But in Headless AEM , you create the content in AEM either using CF or a Template to expose the content as an API. You really don't invest much in the FE design in AEM , as the content is delivered only as JSON to be consumed by your services. The only focus is in the structure of the JSON to be delivered. Does that help to understand ?