Account Accedi
Graphically illustrated browser windows, smart phones, and computers, all connecting via an API interface
Vai al paragrafo

Cos'è un webhook?

Copia URL

Un webhook è una funzione di callback HTTP che consente a due interfacce di programmazione delle applicazioni (API) di comunicare in modo semplice e basato sugli eventi. Funzionali a numerose app web per la ricezione di piccole quantità di dati da altre app, possono anche attivare flussi di lavoro di automazione in ambienti GitOps.

Cos'è un'API?

Le API (acronimo di Application Programming Interface, ovvero Interfaccia di programmazione delle applicazioni) sono set di definizioni e protocolli con i quali vengono realizzati e integrati software applicativi. Le comunicazioni tra API possono essere considerate come un contratto tra un fornitore di informazioni e l'utente destinatario di tali dati: l'API stabilisce il contenuto richiesto dal consumatore (la chiamata) e il contenuto richiesto dal produttore (la risposta). Questa relazione è anche descritta come la chiamata dall'app client all'app server, ma i ruoli possono essere invertiti, a seconda di quale app richiede i dati in una determinata situazione.  

In genere, le API web utilizzando il protocollo HTTP per richiedere i dati ad altre app e definire la struttura dei messaggi di risposta, che spesso assumono la forma di file XML o JSON, due formati diffusi perché presentano i dati in modo da consentire alle altre app di gestirli facilmente. 

Quando un'API client richiede dati a un'API server, esegue una chiamata per controllare il verificarsi di un determinato evento, cioè se i dati del server sono stati modificati in un modo che può essere utile al client. Durante questo processo, noto come polling, il client invia a intervalli regolari una richiesta HTTP, fino a quando l'API del server invia i dati richiesti, in un processo noto come payload

L'app client non conosce lo stato dell'app server, quindi esegue il polling all'API del server per chiedere un aggiornamento, con chiamate regolari fino al verificarsi dell'evento specifico; il server invia i dati richiesti solo quando le informazioni sono disponibili. L'app client continua a richiedere l'aggiornamento e attende fino al verificarsi dell'evento pertinente.

Cosa distingue i webhook?

Per configurare un webhook, il client fornisce un URL univoco all'API server e specifica l'evento su cui richiede informazioni. Una volta configurato il webhook, il client non deve più eseguire il polling al server, poiché sarà quest'ultimo a inviare automaticamente il payload richiesto all'URL di webhook del client, non appena si verifica l'evento specificato. 

I webhook vengono spesso chiamati anche API inverse o API push, perché fanno ricadere la responsabilità della comunicazione sul server e non sul client. Non sarà il client che invia le richieste HTTP chiedendo i dati fino a quando il server risponde, ma è il server che invia al cliente una sola richiesta HTTP POST non appena i dati sono disponibili. Benché abbiano queste denominazioni, i webhook non sono API, ma funzionano insieme a queste. Per utilizzare un webhook, un'applicazione deve disporre di un'API. 

Il nome webhook è la combinazione dei termini web, in riferimento alla comunicazione basata su HTTP, e hooking, in riferimento alla funzione di programmazione che consente alle app di intercettare le chiamate o altri eventi di interesse. I webhook "agganciano" l'evento che si verifica sull'app server e chiedono al server di inviare il payload al client tramite web. Jeff Lindsay ha contribuito a divulgare il concetto con un articolo del 2007 intitolato: "Web hooks to revolutionize the web".

Per proteggere le app che comunicano tramite webhook, i team IT si avvalgono di numerosi metodi. Quasi tutte le app compatibili con i webhook aggiungono un codice segreto all'intestazione della richiesta di payload, in modo che il client possa confermare l'identità del server. I webhook sono spesso protetti dall'autenticazione mTLS (Mutual Transport Layer Security ), che verifica il client e il server prima dell'invio del payload. Per garantire che i dati trasferiti restino privati, spesso le app client utilizzano la crittografia SSL per l'URL del webhook.

I webhook:

  • Eliminano la necessità del polling. Ciò consente di risparmiare le risorse dell'applicazione client.  
  • Si configurano rapidamente. In un'app compatibile con i webhook, la configurazione di questi avviene facilmente tramite l'interfaccia utente dell'app server, nella quale il client inserisce l'URL dei webhook della propria app e configura alcuni parametri di base, come l'evento a cui sono interessati.    
  • Automatizzano i trasferimenti dei dati. Il payload viene inviato non appena l'evento specificato si verifica sull'app server. Lo scambio è inizializzato dall'evento stesso, e pertanto avviene non appena è possibile trasferire i dati dal server al client, sostanzialmente in tempo reale come qualsiasi altro trasferimento di dati.
  • Sono una soluzione valida per payload specifici e leggeri. I webhook fanno affidamento sul server per determinare la quantità di dati inviata, e lasciano al client il compito di interpretare il payload e di utilizzarlo in modo efficiente. Poiché il client non controlla l'esattezza dei tempi o delle dimensioni del trasferimento dei dati, i webhook gestiscono piccole quantità di dati tra due endpoint, spesso in forma di notifica.

In linea di massima, i webhook vengono utilizzati per semplificare la comunicazione tra due applicazioni, ma sono anche in grado di automatizzare i flussi di lavoro Infrastructure as Code (IaC) e attivare procedure GitOps.

Cosa si intende con Infrastructure as Code (IaC)? 

Con Infrastructure as Code (IaC) intendiamo un approccio alla gestione e al provisioning dell'infrastruttura che avviene tramite codice anziché con processi manuali. Per l'IaC il controllo versione è un aspetto cruciale e i file di configurazione dovrebbero essere sottoposti al controllo della sorgente come qualsiasi altro file di codice sorgente del software. Implementare l'infrastruttura in forma di codice permette la suddivisione in componenti modulari che, attraverso l'automazione, possono essere combinati in modi diversi.

Automatizzare il provisioning dell'infrastruttura con l'IaC alleggerisce il carico sugli sviluppatori, che non devono più svolgere manualmente le attività di provisioning e gestione di server, sistemi operativi, storage e altri componenti dell'infrastruttura ogni volta che sviluppano o distribuiscono un'applicazione. Codificare l'infrastruttura permette di creare un modello di provisioning ripetibile, un'attività che può essere eseguita manualmente ma anche automatizzata con un motore della condizione target di livello enterprise, come Red Hat® Ansible Automation® Platform.

Che cos'è GitOps?

Spesso considerato un'evoluzione di IaC, GitOps è un approccio strategico per la gestione delle configurazioni di applicazioni e infrastrutture basata su Git, un sistema di controllo delle versioni open source. Seguendo le procedure GitOps, gli sviluppatori utilizzano Git come singola fonte di attendibilità per le applicazioni e l'infrastruttura dichiarativa, e le richieste pull Git per gestire automaticamente il provisioning e il deployment dell'infrastruttura. Il repository Git contiene informazioni complete sulla condizione del sistema, permettendo di visualizzare e controllare la traccia delle modifiche relative a tale condizione. 

Qual è il ruolo dei webhook?

I webhook riducono i passaggi necessari a implementare e gestire le pipeline di deployment incentrate su Git, e possono avviare automaticamente flussi di lavoro IaC completi. In un ambiente GitOps, il webhook funziona come tra due applicazioni: quando è attivato da un evento specifico, un'API invia un payload a un'altra API. La differenza sta nel tipo di evento che attiva il webhook e dal modo in cui il destinatario utilizza il payload.

In questo contesto, il repository git svolge il ruolo dell'app server, mentre il motore per la gestione della condizione target, che gestisce lo stato dell'infrastruttura, svolge il ruolo dell'app client. Il webhook può essere configurato per attivare la comunicazione al verificarsi di una modifica nel repository. Ad esempio, una parte di codice che viene aggiornata e inviata al repository Git è l'evento che attiva il webhook. Al suo verificarsi, il repository invia automaticamente il payload all'indirizzo del webhook del motore per la gestione della condizione target, comunicando la modifica al codice.

Questo impiego dei webhook consente ai motori di gestione della condizione target di mantenere chiuse le schede relative alle modifiche all'infrastruttura, senza dover attivamente monitorare i repository. Se il motore supporta anche l'automazione, i webhook possono attivare anche i flussi di lavoro IaC. Ad esempio, con un motore per la gestione della condizione target di livello enterprise come Red Hat Ansible Automation Platform, un amministratore di sistema può utilizzare i webhook per distribuire automaticamente le modifiche più recenti apportate agli host gestiti.

In Red Hat® Ansible® Automation Platform sono integrati alcuni webhook di automazione, che consentono di supportare le procedure IaC e GitOps. I webhook consentono l'integrazione nativa di un repository Git, tramite un servizio quale GitHub o GitLab, con Ansible Automation Platform. Una volta configurato il collegamento al repository, Ansible Automation Platform intercetta i commit Git del sistema Git e utilizza tali eventi allo scopo di attivare i processi di automazione per l'aggiornamento dei progetti, la gestione degli inventari e l'esecuzione di deployment.

Con i webhook di automazione puoi attivare automaticamente i flussi di lavoro di automazione quando gli eventi si verificano nel sistema di controllo della sorgente. Si evita così di dover ricorrere ad altri strumenti CI/CD per monitorare i repository e lanciare le attività di automazione in presenza di modifiche, semplificando così il flusso di lavoro GitOps e ottimizzando le operazioni. Red Hat Ansible Automation Platform funziona con un'ampia gamma di strumenti di sviluppo e automazione, ed è pertanto possibile personalizzare il flusso di lavoro GitOps con gli strumenti e i processi preferiti.

Continua a leggere

Articolo

I concetti base di Ansible

Ansible consente di automatizzare i processi IT, come il provisioning e la gestione della configurazione. Questo articolo fornisce un'introduzione ai concetti base di Ansible.

Articolo

Cos'è la gestione dei processi aziendali?

La gestione dei processi di business (BPM, business process management) consiste nella creazione di modelli di business, nell'analisi e nell'ottimizzazione dei processi aziendali end to end per realizzare i tuoi obiettivi aziendali strategici.

Articolo

Perché scegliere Red Hat per l'automazione

Red Hat Ansible Automation Platform include tutti gli strumenti necessari per condividere le competenze di automazione tra i team e adottare l'automazione a livello aziendale.

Scopri di più sull'automazione

Prodotti

Red Hat Consulting

Collabora con il nostro team di consulenti strategici in grado di analizzare l'azienda nel suo insieme e valutare le sfide da affrontare, per aiutarti a superarle con soluzioni complete e convenienti.

Red Hat Ansible Automation Platform

Una piattaforma per implementare l'automazione in azienda, in qualsiasi fase del tuo percorso di trasformazione

Red Hat Process Automation

Una piattaforma per lo sviluppo delle applicazioni cloud native destinate all'automazione dei processi e delle decisioni aziendali.

Risorse

Formazione

Corso di formazione gratuito

Ansible Essentials: Simplicity in Automation Technical Overview

Corso di formazione gratuito

Red Hat Ansible Automation for SAP

Illustration - mail

Ricevi contenuti simili

Iscriviti a Red Hat Shares, la nostra newsletter gratuita.

Red Hat logo LinkedInYouTubeFacebookTwitter

Prodotti

Strumenti

Provare, acquistare, vendere

Comunica

Informazioni su Red Hat

Red Hat è leader mondiale nella fornitura di soluzioni open source per le aziende, tra cui Linux, Kubernetes, container e soluzioni cloud. Le nostre soluzioni open source, rese sicure per un uso aziendale, consentono di operare su più piattaforme e ambienti, dal datacenter centrale all'edge della rete.

Ricevi la nostra newsletter, Red Hat Shares

Iscriviti subito

Seleziona la tua lingua

© 2022 Red Hat, Inc. Red Hat Summit