Microsoft ha dato sei mesi per abbandonare SOAP
Microsoft ha avviato il countdown per l'abbandono dell'API SOAP di Microsoft Advertising. Gli sviluppatori hanno sei mesi per migrare a REST prima che le nuove funzionalità siano disponibili solo su questa architettura.
La piattaforma pubblicitaria spinge verso un’architettura moderna, lasciandosi alle spalle il protocollo XML.
Dal 1° aprile 2026, Microsoft ha avviato ufficialmente il countdown per l’abbandono dell’API SOAP di Microsoft Advertising. Secondo l’annuncio ufficiale del blog Microsoft Advertising, chi ancora costruisce integrazioni su SOAP ha esattamente sei mesi per completare la migrazione verso REST prima che tutte le nuove funzionalità diventino accessibili esclusivamente tramite l’API REST. Non è un dettaglio marginale: è una scelta architetturale che ridisegna lo stack per chiunque scriva codice sopra la piattaforma pubblicitaria di Microsoft.
Il Dettaglio che Fa la Differenza
SOAP — Simple Object Access Protocol — è un protocollo che ha dominato l’integrazione tra servizi web per buona parte degli anni Duemila. Basato su XML e pensato per ambienti enterprise con requisiti stringenti di tipizzazione e formalismo contrattuale, SOAP porta con sé una verbosità strutturale considerevole: ogni richiesta e ogni risposta sono incapsulate in buste XML, con overhead di parsing elevato e una rigidità che mal si sposa con i cicli di sviluppo moderni. REST, al contrario, è un’architettura che sfrutta i metodi HTTP nativi — GET, POST, PUT, DELETE — con payload tipicamente in JSON, molto più leggeri da elaborare e da leggere. La differenza non è solo estetica: è una questione di velocità di sviluppo, semplicità di debug e facilità di integrazione con strumenti contemporanei come OpenAPI, Postman o qualsiasi client HTTP.
Microsoft ha introdotto la sua API REST per Microsoft Advertising già nel 2024, ma fino ad oggi i due mondi hanno coesistito. Ora la direzione è esplicita: REST diventa la fondazione unica per tutto lo sviluppo futuro dell’API. Chi ha costruito su SOAP non perde nulla domani mattina, ma sta costruendo su sabbia che tra meno di un anno scomparirà del tutto.
La Macchina della Transizione
Le date sono tre, e ognuna ha un peso diverso. Il 1° aprile 2026 è il punto di partenza: da quel momento le nuove funzionalità smettono di essere sviluppate per SOAP. Il 1° ottobre 2026 è la prima vera scadenza operativa: tutte le nuove feature e i miglioramenti dell’API saranno disponibili solo su REST. Chi in quella data sarà ancora su SOAP potrà continuare a fare le stesse cose di prima, ma non potrà accedere a nulla di nuovo. Il 31 gennaio 2027 è il termine finale: l’API SOAP viene deprecata completamente, le integrazioni legacy smettono di funzionare.
Il meccanismo è progettato per minimizzare lo shock immediato: le integrazioni SOAP esistenti continueranno a operare senza interruzioni durante l’intero periodo di transizione. Non c’è un kill switch improvviso. È una dismissione graduale e dichiarata, con una finestra di nove mesi tra la prima scadenza funzionale e la deprecazione definitiva. Sul fronte pratico, Microsoft ha pubblicato una guida alla migrazione su documentazione tecnica Microsoft Advertising per la transizione REST, che accompagna gli sviluppatori attraverso il percorso di riscrittura. La struttura delle deadline lascia margine operativo, ma non lascia spazio all’inerzia.
Cosa Cambia Nello Stack
Pensate a SOAP come a un motore diesel degli anni Novanta: robusto, affidabile, con decenni di deployment alle spalle, ma progettato per un’infrastruttura che non esiste più nella sua forma originale. REST è il motore elettrico: meno pezzi in movimento, interfacce standardizzate, integrabile con tutto ciò che il toolchain moderno mette a disposizione. La transizione non riguarda solo la sintassi delle chiamate, ma il modo in cui si pensa alla struttura del codice.
Con REST, ogni endpoint è una risorsa identificata da un URL, e le operazioni su quella risorsa si esprimono attraverso i verbi HTTP. Il contratto tra client e server può essere descritto in modo leggibile con specifiche OpenAPI, versionabili e testabili automaticamente. Con SOAP, la descrizione del servizio passa attraverso un file WSDL — Web Services Description Language — che richiede tooling dedicato per essere consumato e genera codice spesso verboso e difficile da mantenere. Per uno sviluppatore che lavora con librerie moderne in Python, TypeScript o Go, la differenza di ergonomia è concreta e immediata.
L’implicazione più rilevante per chi costruisce integrazioni è che il codice scritto oggi determina quanto sarà costoso stare al passo domani. Restare su SOAP significa rinunciare a tutte le nuove funzionalità della piattaforma a partire da ottobre 2026 — campagne, targeting, formati pubblicitari, qualsiasi nuova capability che Microsoft rilascerà. Non è un trade-off ragionevole per nessuna integrazione attiva. Chi invece migra ora si posiziona su un’architettura che è esplicitamente dichiarata come fondamento per il futuro sviluppo dell’API: ogni nuova feature, ogni ottimizzazione, ogni endpoint inedito arriverà su REST e solo su REST.
Per chi costruisce, non si tratta solo di riscrivere chiamate da XML a JSON. È un’occasione per ripensare l’architettura dell’integrazione: strutturare meglio la gestione degli errori HTTP, sfruttare l’autenticazione OAuth2 in modo più pulito, adottare client generati da specifiche OpenAPI invece di proxy WSDL mantenuti a mano. La transizione è inevitabile e la sua struttura è ragionevole. Il costo di aspettare, invece, cresce ad ogni mese che passa.
