Come sfruttare al meglio il proprio content con l’aiuto di un CMS headless

Senza Content Ma­na­ge­ment System il lavoro degli autori di content sarebbe no­te­vol­men­te più complesso. Difatti, invece di lavorare di­ret­ta­men­te sul codice del sito web, con un CMS i contenuti si in­se­ri­sco­no tramite un back end e vengono ri­pro­dot­ti dal sistema sul front end. Questa ope­ra­zio­ne funziona molto bene fintanto che si gestisce un solo sito web, tuttavia spesso redattori e content manager devono am­mi­ni­stra­re più siti e ap­pli­ca­zio­ni allo stesso tempo e per fare questo ne­ces­si­ta­no di più CMS; ciò even­tual­men­te può com­por­ta­re il tra­sfe­ri­men­to manuale dei contenuti da un CMS all’altro. Esiste però una comoda al­ter­na­ti­va: si può infatti ricorrere a un CMS headless, il quale consente l’output su tutti i media che de­si­de­ra­te.

Un CMS headless, let­te­ral­men­te “senza testa”, è al contempo sia la versione evoluta sia quella ridotta di un CMS tra­di­zio­na­le. Al sistema vengono tolti dei com­po­nen­ti integrali per renderlo com­pa­ti­bi­le con i più svariati compiti. Questo è possibile riesce grazie al fatto che all’interno di un CMS headless il front end e il back end non sono più connessi in­dis­so­lu­bil­men­te tra loro.

Per pro­get­ta­re l’utilizzo di questi sistemi nella maniera più semplice possibile si punta al col­le­ga­men­to mo­no­li­ti­co di front end e back end. Ad esempio sulla piat­ta­for­ma ge­stio­na­le di WordPress si può cambiare l’aspetto del sito anche senza avere par­ti­co­la­ri co­no­scen­ze di web design grazie all’aiuto del template engine. Ciò però significa anche che nella creazione siete vincolati alle direttive del sistema e vale sia per il numero delle pub­bli­ca­zio­ni sia per l’utilizzo del lin­guag­gio di pro­gram­ma­zio­ne (su WordPress si tratta del PHP). Per aggirare questo ostacolo potete ricorrere a un CMS headless.

La REST API (Re­pre­sen­ta­tio­nal State Transfer Ap­pli­ca­tion Pro­gram­ming Interface) è un’in­ter­fac­cia non par­ti­co­lar­men­te complessa per cui anche molto fles­si­bi­le; per la co­mu­ni­ca­zio­ne si serve dei metodi di richiesta HTTP come PUT, GET, POST e DELETE. Con simili comandi un client è in grado di attingere alle in­for­ma­zio­ni del server, con­sul­tar­le e persino mo­di­fi­car­le. Es­sen­zial­men­te la REST altro non fa che seguire lo stile di ar­chi­tet­tu­ra del web. Le REST API, spesso chiamate anche RESTful API, sono strut­tu­ra­te secondo i seguenti criteri:

• i server mettono a di­spo­si­zio­ne le risorse: la REST API è anche a di­spo­si­zio­ne di ap­pli­ca­zio­ni esterne per mezzo di un server, di con­se­guen­za l’accesso non funziona solamente in locale.

• Gli indirizzi iden­ti­fi­ca­no delle cose: le dif­fe­ren­ti tipologie di ap­pli­ca­zio­ne ne­ces­si­ta­no di dif­fe­ren­ti formati di file. L’URI/URL nella REST non fa ri­fe­ri­men­to solo a una risorsa in un formato specifico, bensì solamente all’elemento in sé. Tramite Content Ne­go­tia­tion i client ri­chie­do­no l’elemento nel formato de­si­de­ra­to.

• I messaggi sono au­toe­spli­ca­ti­vi: ogni messaggio al server è chiuso in sé stesso e non fa ri­fe­ri­men­to a messaggi pre­ce­den­ti.

• Col­le­ga­men­to delle risorse at­tra­ver­so dei link: all’interno della REST gli oggetti sono in­ter­con­nes­si tramite degli hyperlink così da garantire una na­vi­ga­zio­ne semplice.

Ri­spet­tan­do questi principi di ar­chi­tet­tu­ra, la co­mu­ni­ca­zio­ne tra server/API e vari client funziona in maniera inec­ce­pi­bi­le. Per questo motivo l’ar­chi­tet­tu­ra REST si adatta per­fet­ta­men­te a un’API per CMS headless.

La se­pa­ra­zio­ne descritta sopra ha senso da due punti di vista. In­nan­zi­tut­to dal punto di vista dello sviluppo sul back end c'è il desiderio di non limitarsi a di­stri­bui­re contenuti solamente at­tra­ver­so un'unica uscita. In un CMS headless non importa su quale piat­ta­for­ma debba essere pub­bli­ca­to il contenuto. La REST API fornisce solo i dati (sotto forma di JSON) e questi possono essere letti da qualsiasi front end, in­di­pen­den­te­men­te dalle tecniche con cui sono stati pro­gram­ma­ti.

Ma anche dalla pro­spet­ti­va dello sviluppo del front end si evi­den­zia­no dei vantaggi: con un CMS headless i web designer non sono più vincolati alle premesse della gestione del content. In questo modo anche il lin­guag­gio di pro­gram­ma­zio­ne è a scelta e consente così la pro­get­ta­zio­ne di app mobili su dif­fe­ren­ti piat­ta­for­me. Solamente i dati puri vanno ricevuti e rie­la­bo­ra­ti, di con­se­guen­za c’è molta più libertà di azione nella rap­pre­sen­ta­zio­ne rispetto ai comuni CMS tra­di­zio­na­li.

Un ulteriore vantaggio è l’abilità della richiesta dinamica: nei CMS tra­di­zio­na­li ogni nuova richiesta di contenuti su un sito implica un nuovo ca­ri­ca­men­to della pagina web. La REST API invece fornisce dati dinamici che possono essere integrati in qualsiasi momento all’interno della struttura delle pagine, anche senza doverli ri­ca­ri­ca­re.

Tramite la se­pa­ra­zio­ne del back end del CMS headless dal front end in­di­vi­dua­le viene a crearsi una si­tua­zio­ne di praticità: siccome i trend del web design sono sot­to­po­sti a regolari mutamenti, risulta piuttosto sensato di tanto in tanto adattare il front end del proprio sito web. Se questo non è vincolato a un database e a un content ma­na­ge­ment, vi si possono comunque apportare delle modifiche. I redattori possono quindi con­ti­nua­re a creare, am­mi­ni­stra­re e pub­bli­ca­re contenuti anche mentre si sta lavorando a un nuovo front end.

Rias­su­men­do, i vantaggi di un CMS headless sono:

• Numero il­li­mi­ta­to di front end

• Com­bi­na­bi­le con vari linguaggi di pro­gram­ma­zio­ne

• Pro­get­ta­zio­ne del front end più fles­si­bi­le

• Con­ti­nui­tà tramite se­pa­ra­zio­ne

• Dati dinamici

L’offerta in ambito di Content Ma­na­ge­ment System headless è in crescita. La prin­ci­pa­le dif­fe­ren­za che in­ter­cor­re tra le varie piat­ta­for­me elencate di seguito riguarda il contenuto delle offerte: se si tratta di un pacchetto completo a pagamento o piuttosto di una versione open source gratuita. Oltre a ciò le soluzioni mettono a di­spo­si­zio­ne diverse offerte di hosting.

• Con­tent­ful Il team con sede a Berlino lavora già dal 2011 al principio di un CMS headless: infatti l’azienda ha svi­lup­pa­to il proprio sistema partendo da zero, incluso un back end altamente efficace, invece di lavorare su un CMS tra­di­zio­na­le già esistente. In cambio l’offerta gratuita è di­spo­ni­bi­le solamente in misura limitata.

• Directus L’azienda Directus segue un percorso diverso rispetto a Con­tent­ful. Il sistema è offerto prin­ci­pal­men­te in forma gratuita come pacchetto open source. Chi desidera ri­vol­ger­si a un’al­ter­na­ti­va già hostata può scegliere tra diverse varianti di ab­bo­na­men­to.

• Con­ten­tstack Built.io, pro­dut­to­re di molte soluzioni digitali, mette a di­spo­si­zio­ne Con­ten­tstack, un CMS headless a pagamento. Anche qui i content creator hanno a di­spo­si­zio­ne un back end facile da uti­liz­za­re che grazie a una REST API è in grado di procurare contenuti per il web, le app Mobile e l’Internet of things. L’offerta si rivolge in primo luogo ad aziende più grandi.

• Cloud CMS Questa azienda offre il suo CMS headless come servizio cloud. In linea di principio funziona allo stesso modo delle altre offerte, eccetto che la gestione dei contenuti, il database e l'in­ter­fac­cia non vengono eseguiti sul proprio host bensì sul cloud del provider. Solo nella fascia di prezzo più alta è previsto un CMS self hosted.

• eZ Platform Dal 1999 ad oggi l’azienda eZ Systems metteva a di­spo­si­zio­ne un CMS tra­di­zio­na­le con il suo prodotto open source eZ Publish. 16 dopo anni il vecchio concetto è stato ab­ban­do­na­to e con la soluzione eZ Platform l'at­ten­zio­ne è stata in­te­ra­men­te portata a un CMS headless. Una versione open source si ritrova anche qui: il prodotto è di­spo­ni­bi­le gra­tui­ta­men­te con la licenza GNU GPL. In aggiunta ci sono varianti a pagamento con supporto pro­fes­sio­na­le e altre offerte di licenza.

Per scegliere la giusta offerta di CMS headless, è prima di tutto ne­ces­sa­rio esaminare i requisiti in­di­vi­dua­li e le com­pe­ten­ze spe­ci­fi­che. A coloro che di­spon­go­no di un server proprio e hanno quindi la pos­si­bi­li­tà di con­fi­gu­ra­re un CMS open source, si rac­co­man­da di uti­liz­za­re le versioni gratuite di eZ Systems o Directus. Se però non disponete delle co­no­scen­ze ne­ces­sa­rie per l'in­stal­la­zio­ne e la con­fi­gu­ra­zio­ne del sistema, dovreste invece scegliere una versione a pagamento per be­ne­fi­cia­re dei vantaggi di questa versione di gestore dei contenuti.

Da quando si parla sempre più fre­quen­te­men­te di CMS headless, anche i provider di CMS tra­di­zio­na­li si stanno con­vin­cen­do della loro utilità. WordPress, ad esempio, ha aggiunto la REST API come com­po­nen­te integrale a partire dalla versione 4.7; nelle versioni pre­ce­den­ti questo era possibile solamente at­tra­ver­so un plug-in. Tuttavia l’esten­sio­ne non lo rende un CMS headless: WordPress diventa piuttosto un CMS scol­le­ga­to. Gli utenti che ap­prez­za­no la vastità della soluzione di gestione del contenuto, incluso il template engine, possono con­ti­nua­re a uti­liz­zar­lo senza dover temere una perdita di funzioni. Chi però desidera uti­liz­za­re il CMS ad esempio anche per la gestione dei contenuti di un’app, può ap­pro­fit­ta­re dell’in­ter­fac­cia aggiunta. Anche Drupal può essere con­ver­ti­to a una forma ibrida, poiché anche questo CMS open source offre l’opzione di pub­bli­ca­re contenuti su ulteriori front end grazie ai RESTful Web Services a partire dalla versione 8.

Il passaggio o meno dal sistema tra­di­zio­na­le a un CMS headless dipende prin­ci­pal­men­te dalle vostre in­ten­zio­ni. Se volete pre­sen­ta­re i vostri contenuti solo su un sito web, come un blog, allora non è una buona idea fare a meno del front end. No­no­stan­te il CMS headless offra anche vantaggi che vanno al di là della quantità di supporti di output possibili, questo può giu­sti­fi­ca­re lo sforzo nei casi più rari. Anche l'uso di un CMS scol­le­ga­to non co­sti­tui­sce alcun valore aggiunto: perché im­ple­men­ta­re un'in­ter­fac­cia se si utilizza solo il front end integrato nel sistema?

La si­tua­zio­ne è però diversa nel momento in cui si pub­bli­ca­no contenuti su piat­ta­for­me diverse. I punti di forza di un CMS headless entrano in gioco so­prat­tut­to quando si de­si­de­ra­no rea­liz­za­re grandi progetti. Capacità mul­ti­ca­na­le, siti web in PHP, Python o Ruby, ap­pli­ca­zio­ni per iOS o Android: grazie a un CMS headless tutto questo non è più un problema. I redattori e gli altri content creator possono gestire i propri contenuti come al solito tramite l'in­ter­fac­cia del back end. Con un CMS headless (e con l'uso corretto di un CMS scol­le­ga­to) sono gli svi­lup­pa­to­ri pro­fes­sio­ni­sti di front end a occuparsi della pre­sen­ta­zio­ne e possono farlo con tutta la libertà che vogliono, poiché la REST API lo rende possibile.

Dato il di­mez­za­men­to del sistema, più che di uno sviluppo vero e proprio si parla di un cambio dello sviluppo dei nuovi sistemi di gestione dei contenuti. Si tratta di una reazione al­l'e­vo­lu­zio­ne delle esigenze di Internet. Le pe­cu­lia­ri­tà degli smart­pho­ne, del­l'In­ter­net of things e delle realtà virtuali rendono ne­ces­sa­rio un ri­pen­sa­men­to del modo in cui i contenuti vengono creati e pub­bli­ca­ti. I CMS headless e quelli scol­le­ga­ti sono solo l’inizio di questa tendenza. Pertanto, anche se lavorare con un CMS tra­di­zio­na­le è ancora più che suf­fi­cien­te, non dovreste perdere di vista ciò che accade nel settore. Alla luce dei rapidi sviluppi degli ultimi anni è pre­ve­di­bi­le che i CMS tra­di­zio­na­li siano presto al­tret­tan­to in­suf­fi­cien­ti a sod­di­sfa­re le abitudini e le esigenze di molti utenti quanto lo sono già ora i siti web statici.