SOAP (Simple Object Access Protocol) e REST (Representational State Transfer) sono entrambi protocolli di comunicazione del servizio web. SOAP è stato a lungo l'approccio standard alle interfacce dei servizi web, sebbene negli ultimi anni sia stato dominato da REST, con REST che ora rappresenta oltre il 70% delle API pubbliche secondo Stormpath. Comprendi le principali differenze tra SOAP e REST e come ciascuna di esse può beneficiare gli obiettivi della tua organizzazione.
REST opera attraverso un'interfaccia solitaria e coerente per accedere alle risorse denominate. È più comunemente utilizzato quando esponi un'API pubblica su Internet. SOAP, d'altra parte, espone i componenti della logica dell'applicazione come servizi piuttosto che come dati. Inoltre, funziona tramite diverse interfacce. In parole povere, REST accede ai dati mentre SOAP esegue le operazioni attraverso un set più standardizzato di modelli di messaggistica. Tuttavia, nella maggior parte dei casi, è possibile utilizzare REST o SOAP per ottenere lo stesso risultato (ed entrambi sono scalabili all'infinito), con alcune differenze nel modo in cui lo configureresti.
SOAP è stato originariamente creato da Microsoft ed è in circolazione da molto più tempo di REST. Ciò gli conferisce il vantaggio di essere un protocollo consolidato e legacy. Ma anche REST è in circolazione da molto tempo. Inoltre, è entrato in scena come un modo per accedere ai servizi Web in un modo molto più semplice di quanto possibile con SOAP utilizzando HTTP.
Oltre a utilizzare HTTP per semplicità, REST offre una serie di altri vantaggi rispetto a SOAP:
REST consente una maggiore varietà di formati di dati, mentre SOAP consente solo XML.
Insieme a JSON (che in genere funziona meglio con i dati e offre un'analisi più rapida), REST è generalmente considerato più facile da usare.
Grazie a JSON, REST offre un supporto migliore per i client browser.
REST fornisce prestazioni superiori, in particolare attraverso la memorizzazione nella cache di informazioni che non vengono alterate e non dinamiche.
È il protocollo utilizzato più spesso per i principali servizi come Yahoo, Ebay, Amazon e persino Google.
REST è generalmente più veloce e utilizza meno larghezza di banda. È anche più facile integrarsi con i siti web esistenti senza necessità di refactoring dell'infrastruttura del sito. Ciò consente agli sviluppatori di lavorare più velocemente anziché perdere tempo a riscrivere un sito da zero. Invece, possono semplicemente aggiungere funzionalità aggiuntive.
Tuttavia, SOAP rimane il protocollo preferito per alcuni casi d'uso. Il consenso generale tra gli esperti in questi giorni è che REST è il protocollo generalmente preferito a meno che non ci sia un motivo valido per utilizzare SOAP (e ci sono alcuni casi in cui SOAP è preferito).
Poiché puoi ottenere la maggior parte dei risultati utilizzando entrambi i protocolli, a volte è una questione di preferenze personali. Tuttavia, ci sono alcuni casi d'uso per cui SOAP tende ad essere più adatto. Ad esempio, se hai bisogno di una sicurezza più robusta, il supporto SOAP per WS-Security può tornare utile. Offre alcune garanzie aggiuntive per la riservatezza e l'integrità dei dati. Fornisce inoltre il supporto per la verifica dell'identità tramite intermediari anziché solo punto a punto, come fornito da SSL (che è supportato sia da SOAP che da REST).
Un altro vantaggio di SOAP è che offre una logica di ripetizione dei tentativi incorporata per compensare le comunicazioni non riuscite. REST, d'altra parte, non ha un sistema di messaggistica integrato. Se una comunicazione non riesce, il client deve affrontarla riprovando. Inoltre, non esiste un insieme standard di regole per REST. Ciò significa che entrambe le parti (il servizio e il consumatore) devono comprendere sia il contenuto che il contesto.
Il protocollo HTTP standard di SOAP ne semplifica il funzionamento attraverso firewall e proxy senza modifiche al protocollo SOAP stesso. Tuttavia, poiché utilizza il complesso formato XML, tende ad essere più lento rispetto a middleware come ICE e COBRA.
Inoltre, sebbene sia raramente necessario, alcuni casi d'uso richiedono una maggiore affidabilità transazionale rispetto a ciò che può essere ottenuto con HTTP (che limita REST in questa capacità). Se hai bisogno di transazioni conformi ad ACID, SOAP è la strada da percorrere.
In alcuni casi, la progettazione di servizi SOAP può effettivamente essere meno complessa rispetto a REST. Per i servizi Web che supportano operazioni complesse, che richiedono la manutenzione di contenuto e contesto, la progettazione di un servizio SOAP richiede meno codifica a livello di applicazione per transazioni, sicurezza, fiducia e altri elementi.
SOAP è altamente estensibile tramite altri protocolli e tecnologie. Oltre a WS-Security, SOAP supporta WS-Addressing, WS-Coordination, WS-ReliableMessaging e una serie di altri standard di servizi Web, un elenco completo dei quali è possibile trovare su W3C.
Alla fine della giornata, il protocollo migliore è quello che ha più senso per l'organizzazione, i tipi di clienti che devi supportare e ciò di cui hai bisogno in termini di flessibilità. La maggior parte delle nuove API viene creata utilizzando REST e JSON, semplicemente perché in genere consuma meno larghezza di banda ed è più facile da capire sia per gli sviluppatori che implementano le API iniziali sia per altri sviluppatori che potrebbero scrivere altri servizi contro di essa. Poiché è più facilmente utilizzato dalla maggior parte dei browser web odierni, REST + JSON è diventata la tecnologia di fatto per la maggior parte delle API pubbliche. Tuttavia, SOAP rimane un protocollo prezioso in alcune circostanze. Inoltre, non devi guardare lontano per trovare fan accaniti che sostengono SOAP per determinati casi d'uso.
Programmatore informatico italiano, mi occupo di sviluppo sia Front-end che Back-end presso una grande azienda. La programmazione è stata la mia passione, insieme allo sport e al teatro che pratico tutt'ora. Ho deciso di aprire questo blog per dare consigli e condividerli con chi, come me, porta con sé questa passione. [..]
