JSON delivery & content services
Purpose: Serve content as JSON for SPAs and apps: exporters, .model.json, and API-shape discipline.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Frontend engineers | Consuming AEM headlessly |
| Backend engineers | Designing the JSON |
The delivery options
| Mechanism | Shape | Use |
|---|---|---|
Sling default JSON (.json, .infinity.json) | Raw repository dump | Dev inspection only — never expose in prod |
Sling Model Exporter (.model.json) | Your model's designed JSON | Default choice for component/page data |
Page-level .model.json (SPA pattern) | Whole page: containers + components | SPA editor / app rendering AEM pages |
| Assets HTTP API | CF/asset JSON | Headless CF consumption |
| Custom servlet | Anything | Aggregations the above can't express |
Exporter output is an API contract
Once an app consumes gold-hospital.model.json, the JSON shape is a versionable interface:
- Additive changes only; removing/renaming fields breaks consumers silently.
- Exclude repository internals (
jcr:*, node paths) unless deliberately part of the contract — Jackson annotations control this. - Document the shape (even a checked-in sample) and treat model changes as API reviews.
Caching JSON
JSON endpoints cache at the dispatcher like any URL if they have an extension and no query strings. Design:
GOOD /content/phi/plans/gold-hospital.model.json (cacheable, invalidated on publish)
BAD /bin/planapi?id=gold-hospital (query string; path-registered; uncacheable by default)React translation
.model.json is your GET /api endpoint whose response shape you control in the Sling Model — the same model that feeds HTL. One adapter, two channels; keep it boring and additive.