API URLs and Caching

Nomad Media uses several distinct URLs for different parts of the application. These are defined in the system config under the system/urls block:

"system/urls": {
    "adminSiteUrl": "https://{domain}-admin/",
    "contentSiteUrl": "https://{domain}-content/",
    "restrictedContentSiteUrl": "https://{domain}-rcontent/",
    "publicSiteUrl": "https://{domain}/",
    "adminServicesUrl": "https://{domain}-api-admin/",
    "publicServicesUrl": "https://{domain}-api/"
}

URL Reference

URL	Notes
`adminSiteUrl`	The URL to the admin web application.
`publicSiteUrl`	The URL to the portal web application.
`contentSiteUrl`	The URL to the CloudFront-cached content. This is the primary URL returned by `publicServicesUrl` for all content requests.
`restrictedContentSiteUrl`	The URL to CloudFront-cached content that is geo-restricted. Returned by `publicServicesUrl` for any geo-restricted content.
`adminServicesUrl`	The URL to the Admin API (API Gateway endpoint). Intended only for managing content in the application. Not cacheable — content URLs returned are direct S3 URLs rather than through CloudFront.
`publicServicesUrl`	The URL to the Portal API (API Gateway endpoint). Intended for developer usage and standard API requests in normal or low-volume scenarios. All content returned uses CloudFront via `contentSiteUrl`. See the caching note below.

Caching the Public Services URL

For production use, there is an additional cached variant of publicServicesUrl. It is identical to publicServicesUrl except the "api" segment is changed to "app":

publicServicesUrl:  https://{domain}-api/
Cached URL:         https://{domain}-app/

All GET API calls made through the cached URL are cached via CloudFront, keyed by their full querystring. All other methods (POST, PUT, DELETE, etc.) are not cached and pass through normally.

Development vs. Production

Environment	Recommended URL
Development	`publicServicesUrl` — live, uncached responses for fast iteration
Production	Cached `app` URL — CloudFront caching for high scalability

During development, use publicServicesUrl for live, uncached responses. Periodically verify that the cached (app) URL also works correctly. Once deployed to production, always use the cached URL to achieve high-scale capability.