Cosa sono le API? Immagina due uffici nello stesso palazzo che devono scambiarsi documenti ogni giorno.
Potrebbero farlo passandosi le carte a mano nel corridoio, ma qualcuno potrebbe perderli, qualcuno potrebbe consegnare la versione sbagliata di un documento, qualcuno potrebbe portarle la documentazione ad un ufficio che sta sul piano sbagliato.
Per evitare errori potrebbero costruire un sistema rigoroso, per esempio potrebbe essere una finestra dedicata dove passare i fogli, un formato standard per i documenti, un codice di accesso per garantire che solo chi è autorizzato possa passare materiale da un lato all’altro.
Questo sistema che descriviamo è, in sostanza, quello che fa un’API.
API è un acronimo che sta per Application Programming Interface, e come tutti gli acronimi tecnici tende a spaventare più di quanto dovrebbe.
Nell’episodio 264 di Ospitalità 4.0, Marco Matarazzi ed Edoardo Ridolfi ne hanno parlato con un obiettivo preciso: togliere la patina di mistero da uno strumento che ogni albergatore usa già ogni giorno, spesso senza saperlo.
Il channel manager che sincronizza le disponibilità con Booking.com sta usando un’API.
Il software di revenue management che legge le prenotazioni dal gestionale e riscrive le nuove tariffe sta usando un’API.
Il sistema di domotica che regola il riscaldamento delle camere in base agli arrivi previsti sta usando un’API.
Marco le definisce “patti di fiducia tra programmatori“, e questa definizione è più precisa di quanto sembri. Un’API non è solo un canale di comunicazione: è un contratto.
Stabilisce cosa si può chiedere, in che formato, con quale autorizzazione.
Chi sviluppa il software A si impegna a rispettare le regole definite da chi ha sviluppato il software B, e viceversa.
Finché il contratto viene rispettato, i due sistemi si parlano in modo affidabile e prevedibile.
Quando non viene rispettato, i dati si corrompono, le informazioni si perdono, e il problema che emerge in superficie, una prenotazione non scaricata, una tariffa non aggiornata, un addebito mancante, è quasi sempre il sintomo di un’API mal implementata o mal gestita a monte.
Come si scambiano i dati: lettura, scrittura e autenticazione
La meccanica dello scambio è meno complicata di quanto il gergo tecnico faccia pensare.
Un sistema può chiedere a un altro di leggere dei dati, cioè ricevere informazioni senza modificarle, oppure di scrivere dati, cioè inviare informazioni che l’altro sistema dovrà registrare. Nella pratica alberghiera, entrambe le direzioni servono, spesso in combinazione.
Prendiamo il caso del software di revenue management.
Ogni notte, o anche più volte al giorno, legge dal PMS le prenotazioni esistenti da comunicare al Portale Alloggiati, i prezzi attuali, l’occupazione prevista.
Elabora queste informazioni, calcola le tariffe ottimali e le riscrive nel PMS, che a sua volta le propaga verso il channel manager e il booking engine.
È un ciclo continuo che coinvolge tre sistemi distinti e due direzioni di flusso, lettura e scrittura, tutto orchestrato da API che si parlano in background senza che nessuno debba fare nulla manualmente.
Per garantire che solo i sistemi autorizzati possano accedere a questi dati, si usa un token di autenticazione: una chiave digitale, concettualmente simile a una password, che identifica chi sta facendo la richiesta e a quali dati ha diritto di accedere.
Ogni struttura ha la propria chiave, separata da quella delle altre strutture sullo stesso software.
Questo significa che un partner integrato con Slope può accedere ai dati dell’hotel X solo se l’hotel X lo ha esplicitamente autorizzato, e solo nei limiti di quell’autorizzazione.
Il punto che Marco sottolinea con forza è che questa chiave va trattata con la stessa cura di una password bancaria: condividerla in modo disinvolto, o affidarla a partner che non la gestiscono correttamente, apre rischi reali sulla sicurezza e sull’integrità dei dati.
Il PMS come collettore, arbitro e giuria
Se le API sono i canali di comunicazione, il PMS è la piazza centrale da cui partono e a cui arrivano tutti i flussi.
Marco lo descrive come “collettore, arbitro, giudice e giuria al centro del campo”, e l’immagine rende bene l’idea.
Ogni sistema verticale, dall’RMS alla domotica, dal software di ristorazione ai sistemi di reputazione, gravita attorno al gestionale e dipende dalla qualità dei dati che il gestionale è in grado di fornire.
Un sistema di domotica, per esempio, non ha bisogno di sapere il nome dell’ospite in camera 214: gli basta sapere se la camera è occupata, da quando, e fino a quando. Legge queste informazioni dal PMS e regola di conseguenza riscaldamento, illuminazione, climatizzazione.
Ma quando si tratta di generare una chiave NFC all’arrivo dell’ospite, la direzione si inverte: è il PMS che avvisa il sistema di domotica in tempo reale, non il contrario.
Il software del ristorante funziona in modo diverso ancora: legge le anagrafiche dal PMS per associare una consumazione al profilo corretto, e poi scrive l’addebito direttamente sul conto della prenotazione.
Tre integrazioni diverse, tre configurazioni diverse, tutte che hanno come punto di riferimento comune il gestionale.
Questo schema ha una conseguenza pratica che vale la pena capire bene: la qualità dell’intero ecosistema dipende dalla qualità dei dati nel PMS.
Se le prenotazioni sono inserite in modo incompleto, se i campi anagrafici sono compilati a metà, se le tariffe non sono strutturate in modo coerente, ogni sistema integrato erediterà queste imperfezioni e le amplierà.
Le API non correggono i dati sporchi: li trasmettono fedelmente, nel bene e nel male.
Un sistema installato fisicamente in hotel dieci anni fa, costruito prima che l’architettura cloud diventasse lo standard, fa fatica a comunicare con il mondo esterno per ragioni strutturali, non per scelta. Non è un problema di volontà: è un limite fisico dell’infrastruttura su cui poggia.
Slope e l’utilizzo delle API
Slope gestisce questo tema con un processo di certificazione per i partner che richiedono accesso alle API: non perché l’obiettivo sia creare barriere, ma perché un’integrazione mal costruita che scrive dati sbagliati nel gestionale danneggia l’hotel silenziosamente, spesso per settimane prima che qualcuno se ne accorga.
Il modello deve funzionare bene per tutti gli attori coinvolti, altrimenti non funziona bene per nessuno.
