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-fragments-delivery-feature-video-use.html
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.
Hope this will help!!