Le REST API di WordPress

Siamo abituati a pensare a WordPress, il noto sistema di gestione dei contenuti, come ad un’applicazione monolitica in cui backend e frontend sono fortemente interconnessi, e per lo più è effettivamente così. Non tutti sanno, tuttavia, che i contenuti di un’installazione WordPress sono fruibili anche da parte di un’applicazione esterna tramite REST API. Cosa significa tutto ciò? Vediamolo insieme.

Definizione di API

In informatica un’API (acronimo di Application Programming Interface, liberamente traducibile con interfaccia di comunicazione) è un canale di comunicazione tra sistemi dissimili. In ogni scambio si identifica un mittente o server che fornisce i dati richiesti e un destinatario o client che effettua tale richiesta. Il server e i vari client che si connettono ad esso tramite API sono, di norma, applicativi prodotti con linguaggi e strutture dati disomogenee tra loro.

Le API sono pertanto un software che offre un servizio dati a prescindere dai dispositivi che si interfacciano, dal linguaggio di programmazione che usano e perfino dalle finalità per le quali vengono richiesti tali dati.

Tutti i siti che incorporano una mappa Google nelle loro pagine, ad esempio, stanno facendo uso in qualche modo delle API Google. Ogni sito sfrutta potenzialmente un linguaggio differente, eppure riesce a comunicare senza problemi con l’interfaccia messa a disposizione da Google i cui server, a loro volta, hanno peculiarità proprie certamente diverse dai client che si appoggiano ad essi.

Introduzione in WordPress

Le REST API erano inizialmente disponibili come plugin ma, a partire dal 2016 con la versione 4.7, sono state rilasciate come parte integrante del CMS. Si tratta quindi di una funzionalità ampiamente stabile e collaudata che tra l’altro è sfruttata da Gutenberg, il nuovo editor di testo alla base del backend di WordPress.

Le REST API di WordPress

È opportuno precisare che le REST API sono una funzionalità riservata agli sviluppatori e non all’utente comune. Ecco come le descrive la documentazione ufficiale.

L’API REST di WordPress fornisce degli endpoint REST (URL) che rappresentano post, pagine, tassonomie e altri tipi di dati integrati in WordPress. La tua applicazione può inviare e ricevere dati JSON a questi endpoint per interrogare, modificare e creare contenuti sul tuo sito. JSON è un formato di dati standard aperto che è leggero e leggibile dall’uomo e somiglia agli oggetti in JavaScript.

developer.wordpress.org

In altre parole qualunque applicazione al di fuori dell’installazione di WordPress potrà accedere e modificare i contenuti effettuando delle richieste HTTP a degli URL ben definiti (gli endpoint) che sono stati predisposti appositamente seguendo le linee guida del modello architetturale REST e che usano un formato di interscambio (JSON) comprensibile a tutte le parti in causa.

Non sarà necessario pertanto sviluppare un tema (o comprarne uno) integrato in WordPress, basterà essere in grado di interrogare le REST API con una qualunque applicazione.

Se preferisci scrivere il tuo tema, plug-in o applicazione esterna come un’applicazione JavaScript lato client o un programma autonomo in un linguaggio diverso da PHP, la tua applicazione avrà bisogno di un modo strutturato per accedere ai contenuti all’interno del tuo sito WordPress. Qualsiasi linguaggio di programmazione in grado di effettuare richieste HTTP e interpretare JSON può utilizzare l’API REST per interagire con WordPress: PHP, Node.js, Go e Java, a Swift, Kotlin e altri ancora.

developer.wordpress.org

Un tale utilizzo di WordPress è definito headless (senza testa) ed indica proprio il disaccoppiamento tra backend e frontend.

Pro e contro

In base alla mia personale esperienza e semplificando il più possibile, ci sono almeno un paio ragioni per le quali potrebbe essere vantaggioso un utilizzo headless e altrettante che potrebbero invece costituire un ostacolo da superare. Cominciamo dalle prime.

1. Multicanalità. WordPress potrebbe costituire una fonte web-based e fortemente specializzata nella produzione di contenuti condivisa da più applicazioni indipendenti e disparate, perfino applicazioni desktop.
2. Autonomia e ottimizzazione. L’approccio headless consente di non sottostare ai vincoli architetturali e alle convenzioni imposte dalla piattaforma, di non abbandonare i consueti schemi di lavoro e di ottimizzare liberamente ogni singola riga di codice per ottenere un design personalizzato e performante.

L’utilizzo delle REST API, d’altro canto, potrebbe rivelarsi non esattamente immediato come potrebbe sembrare a primo acchito.

1. Carico di lavoro extra. WordPress impone vincoli e convenzioni ma, dal punto di vista di uno sviluppatore che sposa appieno questa piattaforma, è innegabile che fornisca anche dei metodi comodi e largamente sperimentati a disposizione dello sviluppatore per presentare i contenuti e per strutturare il proprio layout. Ci vuole motivazione, competenza e tempo a disposizione da investire per sfruttare le REST API con un’efficienza comparabile. Per reperire tutti i dati che occorrono, inoltre, ci si potrebbe trovare a personalizzare ed estendere le risposte predefinite del sistema o perfino a creare nuovi endpoint incorrendo nel paradosso di continuare a produrre codice per WordPress avendo l’intento di rendersi autonomi da esso.
2. Backend e plugin. A corollario di quanto appena scritto: alcune funzionalità del backend di WordPress non saranno disponibili e nemmeno gran parte dei plugin della repository ufficiale, a meno che, ovviamente, questi non espongano le proprie REST API.

L’approccio frameworkless

Personalmente le REST API si combinano perfettamente con l’approccio frameworkless che tendo ad avere inevitabilmente in tutti i miei lavori e progetti. Questo stesso sito funziona in modalità totalmente headless senza rinunciare agli indiscutibili benefici dell’utilizzo di Gutenberg per la produzione e la gestione di contenuti.

Ciò ovviamente non significa in alcun modo che questo punto di vista sia il migliore o quello da prediligere in ogni caso.

Come collegarsi

Concludiamo con un breve esempio di codice che effettua una chiamata alle REST API di un’installazione WordPress usando la libreria cURL di PHP, ma, così come abbiamo precedentemente affermato, avremmo potuto usare praticamente qualunque altro linguaggio.

L’indirizzo base a cui puntare è https://www.nomesito.com/wp-json/, qui invece un elenco di tutti gli endpoint disponibili. Per reperire i post di un sito l’URL risultante sarà https://www.nomesito.com/wp-json/wp/v2/posts; naturalmente nomesito.com andrà sostituito con l’indirizzo di un’installazione WordPress locale o remota realmente esistente. Possiamo eseguire questo codice per recuperare i post nomesito.com da una pagina php esterna a tale dominio.

La richiesta è parametrizzabile e rappresenta solo il nostro primo passo alla scoperta delle REST API.

In alternativa è possibile riportare lo stesso endpoint su Postman (un software appositamente progettato per testare API) per visualizzare i dati restituiti in maniera più ordinata e in sezioni comprimibili.