REST o SOAP in un ambiente cloud-native

I modelli di dati API basati su cloud non solo hanno migliorato l'esperienza del cloud, ma hanno anche fornito agli sviluppatori e agli amministratori un modo per integrare i carichi di lavoro nel cloud utilizzando tali API. Per la maggior parte delle aziende, le API consentono di condividere le informazioni tra varie applicazioni locali e basate su cloud. Svolgono anche un ruolo importante per integrare i carichi di lavoro della piattaforma in modo più trasparente. Poiché l'adozione del cloud continua a crescere, aumenta la domanda di punti di integrazione tra le applicazioni all'interno e all'esterno dell'ambiente cloud. L'aumento della strategia multicloud insieme alla necessità di migliorare le funzionalità cross-cloud hanno aumentato la dipendenza dall'ambiente API cloud. Ma qual è l'approccio migliore e quale supporto ottieni nel tuo ambiente cloud?

SAPONE in poche parole

SOAP (abbreviazione di Simple Object Access Protocol), l'approccio precedente, aveva un supporto a livello di settore che andava da società di prodotti come IBM e Microsoft agli implementatori di servizi. Inoltre è stato fornito con un insieme completo ma complesso di standard. Il team Microsoft che ha progettato SOAP lo ha reso estremamente flessibile, per essere in grado di comunicare su reti private, Internet ed e-mail. Era supportato anche da diversi standard. La versione iniziale di SOAP faceva parte di una specifica che conteneva UDDI (Universal Description, Discovery, and Integration) e WSDL (Web Services Description Language).

SOAP fornisce essenzialmente la busta per l'invio dei messaggi dei servizi web. L'architettura stessa è progettata per aiutare l'esecuzione di varie operazioni tra i programmi software. La comunicazione tra i programmi di solito avviene tramite richieste basate su XML e risposte basate su HTTP. HTTP è principalmente un protocollo di comunicazione utilizzato, ma possono essere utilizzati anche altri protocolli.

Un messaggio SOAP contiene alcune parti obbligatorie come ad esempio ENVELOPE, HEADER, BODY, e FAULT. L'  ENVELOPEoggetto definisce l'inizio e la fine della richiesta di messaggio XML, HEADERcontiene tutti gli elementi di intestazione che devono essere elaborati dal server e BODYcontiene l'oggetto XML rimanente che costituisce la richiesta. FAULToggetto viene utilizzato qualsiasi gestione degli errori.

RIPOSO

REST (Representational State Transfer) viene solitamente indicato come uno stile architettonico piuttosto che un protocollo, che viene utilizzato per creare servizi web. L'architettura REST consente la comunicazione tra due programmi software, in cui un programma può richiedere e manipolare risorse dall'altro. Richiesta REST per accedere alle risorse sul programma di destinazione utilizza HTTP verbi: GET, POST, PUT, e DELETE. Queste richieste possono utilizzare formati di dati inclusi XML, HTML e JSON. JSON è il più preferito in quanto è più compatibile e facile da usare. la maggior parte delle API REST sono basate su URI (Uniform Resource Identifier) ​​e sono specifiche del protocollo HTTP. 

REST è intuitivo per gli sviluppatori perché il suo stile più semplice lo rende più facile da implementare e utilizzare rispetto a SOAP. REST è meno dettagliato e viene inviato un volume di dati inferiore durante la comunicazione tra due endpoint.

Perché SOAP o REST?

Mentre SOAP è come usare una busta che contiene molte informazioni di elaborazione al suo interno, REST può essere considerata una cartolina che ha un URI come indirizzo di destinazione, è leggera e può essere memorizzata nella cache. REST è basato sui dati ed è utilizzato principalmente per accedere a una risorsa (URI) per determinati dati; SOAP è un protocollo basato sulla funzione. REST offre flessibilità nella scelta del formato dei dati (testo normale, HTML, XML o JSON) mentre SOAP utilizza solo XML.

SOAP è adatto per applicazioni in cui è necessario un livello di sicurezza più elevato. SOAP viene fornito con funzionalità di sicurezza di livello aziendale supportate da WS-Security, insieme al supporto SSL. Se stai cercando di sviluppare una soluzione di mobile banking, le API SOAP sarebbero probabilmente la prima considerazione per i requisiti di sicurezza. SOAP fornisce anche una logica di ripetizione per il successo garantito e una comunicazione affidabile. REST utilizza HTTP e può risolvere gli errori di comunicazione solo riprovando, tuttavia la logica dei tentativi non è incorporata in REST. SOAP fornisce logica di ripetizione incorporata.

Cosa cambia in un ambiente cloud-native?

Dal punto di vista di uno sviluppatore, nulla cambia realmente nella scelta tra REST o SOAP, ma la progettazione del servizio in un ambiente cloud-native porta in considerazione la prospettiva della piattaforma. La disponibilità del servizio e il tempo di risposta giocano un ruolo fondamentale nella progettazione di servizi aziendali e applicazioni cloud native. Dal punto di vista della sicurezza, il protocollo WS-Security (Web Service Security), che fornisce sicurezza a livello di messaggio end-to-end utilizzando messaggi SOAP, è ampiamente applicato nel cloud computing per proteggere la sicurezza della maggior parte dei servizi Web correlati al cloud computing. Ma WS-Security utilizza gli elementi dell'intestazione SAOP per trasportare le informazioni relative alla sicurezza. Un messaggio SOAP è di formato di tipo XML e normalmente è di dimensioni molto più grandi del messaggio effettivo in formato binario. Ciò aumenta il tempo e l'elaborazione per comunicare ed elaborare i dati.Questo può essere argomento di dibattito per la scelta di REST rispetto a SOAP, ma c'è un passaggio da SOAP a REST indipendentemente dalla piattaforma su cui verrà eseguita l'applicazione.

Verso la fine del 2016, Microsoft Azure ha aggiunto il supporto del passthrough SOAP a Gestione API di Azure che aiuta gli sviluppatori a creare un proxy per le proprie API SOAP nello stesso modo in cui creano proxy per le API REST / HTTP. Utilizzando il supporto passthrough SOAP, è possibile importare documenti WSDL e creare un nuovo proxy API; il processo esamina tutte le azioni SOAP nel documento e le crea efficacemente negli endpoint API. In una versione futura, potremmo vedere una funzionalità richiesta per creare il front-end REST utilizzando un back-end SOAP.

All'interno del mondo AWS, la maggior parte delle API AWS è accessibile solo tramite REST e ha un supporto limitato per SOAP. Le risorse EC2 sono disponibili tramite REST o Query API, mentre SOAP API per EC2 è stata deprecata dalla fine del 2015. Anche servizi come Amazon S3 e RDS supportano REST mentre SOAP è supportato solo tramite HTTPS; SOAP per HTTP è deprecato. Amazon SQS non supporta più SOAP. Mentre REST sembra guidare le API AWS, Amazon API Gateway si integra con l'ecosistema AWS e fornisce supporto per la creazione, la gestione e la distribuzione di un'API RESTful per esporre endpoint HTTP / HTTPS back-end, funzioni AWS Lambda e / o altri servizi AWS. API Gateway aiuta anche a invocare metodi API esposti tramite gli endpoint HTTP front-end.

Sempre più supporto si appoggia alle API RESTful. La sua semplicità con operazioni simili a verbi lo rende adatto agli sviluppatori. È compatibile con la maggior parte dei formati ed è facile da usare. Non c'è tramonto neanche per SOAP, ma REST sarà sicuramente popolare tra la comunità degli sviluppatori.