Novità È disponibile GajaCms 2026.9 — MCP e pannello di approvazione delle proposte AI. Leggi il changelog
Guida di GajaCms Guida di GajaCms
LA RISPOSTA DI PAGINA

Struttura della risposta di pagina

L'endpoint di risoluzione restituisce sempre lo stesso oggetto, qualunque sia il tipo di contenuto risolto. Questa pagina ne descrive il wrapper: le proprieta di primo livello, le regole che valgono per l'intero documento JSON e l'ordine in cui un software di rendering le utilizza.

Un solo oggetto per ogni pagina

L'endpoint di risoluzione restituisce un wrapper comune a tutta l'API, con la pagina risolta nella proprieta data. La forma di quell'oggetto non cambia: una home page, un articolo, una scheda prodotto e una pagina della guida espongono le stesse proprieta di primo livello. Cio che cambia e quale di esse risulta valorizzata.

Questo permette a un software di rendering di trattare ogni pagina con la stessa procedura: verifica il redirect, prepara i metadati del documento, monta le regioni comuni e infine percorre le aree di contenuto.

Forma della risposta
{
  "success": true,
  "data": {
    "id": "5eb29ec2-4634-4613-9fd3-9599f70f6918",
    "route": { },
    "layout": { "id": "d9ff2cc6-1550-4bc1-90cb-4d1eb8766982", "name": "Pagina" },
    "type": "Page",
    "website": { },
    "publishedAt": "2026-09-10T06:23:01.135761Z",
    "tableOfContents": [ ],
    "content": { },
    "regions": {
      "topHeader": [ ],
      "header": [ ],
      "contentAreas": [ ],
      "footer": [ ],
      "shared": [ ],
      "docNavigation": [ ]
    },
    "socials": [ ],
    "plugins": [ ],
    "clientInjections": [ ],
    "contractPages": { }
  },
  "timestampUtc": "2026-09-10T06:38:49.335475Z"
}

Le proprieta di primo livello

Ogni proprieta e trattata in dettaglio in una pagina dedicata. La tabella indica il ruolo di ciascuna e dove viene approfondita.

Proprieta

Tipo

Ruolo

id

identificativo

Identificativo della pagina risolta. Coincide con l'identificativo del contenuto esposto in content.

route

oggetto

URL, titoli, metadati SEO, briciole di pane, versioni in altre lingue ed eventuale redirect.

layout

oggetto

Modello di pagina applicato: identificativo, nome ed eventuale modalita di apertura del popup.

type

enumerazione

Tipo di pagina risolta. Determina quale proprieta di content risulta valorizzata.

website

oggetto

Dati del sito: nome, versione, icone, loghi, valutazioni esterne, percorso base degli asset.

publishedAt

data e ora

Data di pubblicazione del contenuto, in UTC. Utile per i dati strutturati e per la cache del client.

tableOfContents

elenco

Sommario della pagina, gia calcolato dai titoli dei componenti.

content

oggetto

Contenuto risolto. Una sola proprieta e valorizzata, coerente con type, oltre all'eventuale galleria di dettaglio.

regions

oggetto

Le sei regioni della pagina: topbar, header, aree di contenuto, footer, componenti condivisi e navigazione della guida.

socials

elenco

Profili social del sito, con tipo, indirizzo e ordinamento.

plugins

elenco

Servizi di terze parti configurati nel pannello, con le rispettive chiavi.

clientInjections

elenco

Risorse lato client da inserire nel documento: meta tag, script, fogli di stile, HTML.

contractPages

oggetto

Indirizzi delle informative privacy e cookie del sito.

Regole valide per tutto il documento

Le regole seguenti valgono a ogni profondita della risposta e vanno considerate nella progettazione del software di rendering.

  • Le proprieta nulle non vengono serializzate. Una proprieta assente dal JSON equivale a una proprieta priva di valore: il client non deve distinguere i due casi.

  • Gli elenchi vuoti vengono invece serializzati come array vuoti. La presenza di [] e informativa: la regione o la raccolta esiste ma non contiene elementi.

  • I nomi delle proprieta sono in notazione a cammello, con l'iniziale minuscola.

  • Le enumerazioni dei contratti di contenuto sono serializzate come stringhe, con la stessa capitalizzazione riportata in questa documentazione: "Page", "Image", "Internal". Un valore sconosciuto va ignorato senza interrompere il rendering.

  • Gli identificativi sono stringhe in formato GUID e restano stabili tra una pubblicazione e l'altra. Sono adatti come chiave nei cicli di rendering.

  • Le date sono in UTC, nel formato ISO 8601. La conversione al fuso orario del visitatore spetta al client.

  • Diversi oggetti del contratto espongono piu proprieta alternative fra loro, di cui una sola risulta valorizzata. Accade in content, in data dei componenti e in background. In ognuno di questi casi una proprieta di tipo indica quale.

  • Le risposte sono compresse con Brotli o Gzip quando il client lo dichiara negli header. Il payload di una pagina completa e nell'ordine delle centinaia di kilobyte non compressi.

Ordine di lettura per il rendering

La sequenza seguente descrive l'uso tipico della risposta in un software di rendering.

  1. Verificare route.redirect. Se valorizzato, emettere il reindirizzamento HTTP e terminare: il resto della risposta e vuoto.

  2. Costruire la testa del documento con route.seo, route.canonicalUrl, route.localizedRoutes, website.icons e le voci di clientInjections destinate alla testa.

  3. Montare le regioni comuni: regions.topHeader e regions.header in cima, regions.footer in fondo, usando i loghi di website.logos e i profili di socials.

  4. Rendere il contenuto principale percorrendo regions.contentAreas nell'ordine dell'indice, e per ciascuna area i suoi componenti nell'ordine dell'elenco.

  5. Integrare i dati specifici del tipo di pagina leggendo content e, dove previsto, il sommario tableOfContents e la navigazione regions.docNavigation.

  6. Applicare plugins e le restanti clientInjections, rispettando le categorie di consenso dichiarate.

Cosa la risposta non contiene

La risposta e completa per quanto riguarda la struttura della pagina, ma alcune raccolte possono essere volutamente vuote e destinate a un caricamento successivo.

  • Le gallerie e le vetrine con lazyLoad a true arrivano senza elementi. Il client li richiede con gli endpoint dedicati quando il componente entra nel viewport.

  • Gli elenchi paginati di articoli ed eventi non fanno parte della risposta di pagina e hanno endpoint propri.

  • I dati soggetti a disponibilita, come i preventivi, non sono precalcolati nella pagina.

La risposta e generata a partire da una cache di rendering per sito e per route. Il contenuto riflette lo stato dell'ultima pubblicazione, non le modifiche ancora in bozza nel pannello.