Due modi diversi di avere un'API su un CMS

Quasi ogni CMS puo' esporre un'API REST: WordPress ha REST API core piu' plugin come WPGraphQL o WP REST API Controller, altri CMS si appoggiano a plugin di terze parti. ApiCms segue un approccio diverso: l'API non e' un'aggiunta esterna, e' parte nativa del CMS fin dal disegno iniziale.

I limiti reali dei plugin REST aggiunti dopo

Un plugin REST installato su un CMS pensato per l'admin web classico porta con se' problemi tipici: overhead di un livello di traduzione in piu' tra il plugin e il core, rischio di breaking change quando il CMS si aggiorna e il plugin resta indietro, spesso permessi e autenticazione gestiti in modo diverso dal resto del sistema, con superficie di attacco piu' ampia da mantenere sotto controllo.

Cosa cambia con un'API nativa

Con ApiCms ogni azione disponibile via API (creare un articolo, un prodotto, aggiornare il menu, caricare un'immagine) e' la stessa identica funzione che usa l'admin web — non un livello parallelo. Questo significa niente disallineamenti, autenticazione con lo stesso sistema di token del CMS, e ogni nuova funzionalita' del CMS e' automaticamente disponibile anche via API senza aspettare un aggiornamento separato del plugin.

Il vantaggio pratico: pilotare il sito in chat

Con un'API nativa affidabile diventa realistico pilotare l'intero sito scrivendo richieste in linguaggio naturale a un assistente AI, che traduce la richiesta in chiamate API dirette — niente FTP, niente pannello admin da navigare a mano. E' il caso d'uso reale che ha spinto la scelta architetturale di ApiCms fin dall'inizio: il CMS come infrastruttura pilotabile, non solo come pannello da cliccare.