Qual è il significato attuale di SOAP

REST è davvero uno stile architettonico. SOAP è un protocollo dati. La distinzione è importante; non puoi confrontarli direttamente.

Lo scopo principale di REST è di rappresentare risorse su Internet, e per fornire meccanismi per scoprirli. Al contrario, SOAP viene usato per comunicare dati strutturati tra computer, e questo è tutto ciò che fa veramente .

Si noti che in realtà non è necessario REST per creare una relazione client / server tra due computer su Internet. Tutto ciò di cui hai bisogno è un meccanismo che trasferisca JSON o XML, e non ti serve nemmeno se sei disposto a essere incompatibile con tutti gli altri.

Tuttavia, SOAP ha perso il favore delle nuove API pubbliche, sebbene sia ancora comunemente usato per le applicazioni B2B perché è possibile definire un "contratto dati" con esso. I servizi web JSON hanno il pregio di essere piuttosto leggeri e flessibili, e dal momento che Javascript riconosce JSON in modo nativo, è una scelta naturale per i browser.

Ma niente di tutto ciò ha molto a che fare con REST, davvero.

Ulteriori letture
REST è meglio di SOAP? (buon articolo, anche se in modo errato chiama REST un protocollo).
Il modello di maturità Richardson

REST è molto più limitato di SOAP, che è la sua forza e il motivo della sua popolarità.

In SOAP, la serie di operazioni consentite e il set di tipi di dati consentiti è essenzialmente senza limiti. SOAP è un protocollo di procedura remota, che si utilizza per esporre le API locali attraverso la rete senza perdere fedeltà. Ciò ha reso SOAP popolare negli ambienti aziendali in cui i sistemi transazionali complessi dovevano interagire attraverso la rete senza perdere la fedeltà lungo il percorso. Questa ricchezza di capacità è anche la rovina di SOAP, perché rende le API SOAP così ingombranti da comprendere e utilizzare che ha reso necessaria la creazione di strumenti automatizzati sotto forma di librerie client WSDL e SOAP per dare un senso alle cose. Inoltre, l'esposizione della ricchezza completa del sistema sottostante non è interessante nelle API pubbliche, in cui si desidera fornire astrazioni che consentono di evolvere il sistema sottostante senza dover interrompere o eseguire la versione dell'API.

REST + JSON ha guadagnato popolarità in particolare per la sua semplicità. Definisce un insieme limitato di operazioni con un insieme limitato di tipi di dati, richiedendo al progettista dell'API di progettare attentamente le astrazioni che si adattano a questo vocabolario limitato e di pensare davvero attraverso la mappatura del dominio aziendale alle risorse REST. Un'API REST è facile da capire e facile da usare senza strumenti speciali. Per un'API pubblica, in cui i tuoi utenti API possono disporre di tutti i livelli di competenza e conoscenza, questo è esattamente ciò che desideri, ed è per questo che tutte le API che vedi sul Web sono state trasferite su REST. SOAP è relegato in situazioni aziendali in cui esiste ancora un desiderio e la necessità di condividere API complesse tra sistemi. Tuttavia, con tendenze architettoniche verso micro-servizi con versioni indipendenti sviluppate da team separati, anche quel dominio sta perdendo terreno.

In sostanza, ciò che le persone hanno capito è che l'insieme di vincoli che è necessario applicare alla progettazione dell'API per rendere l'API semplice e abbastanza astratta da essere gestibile e facile da usare è esattamente l'insieme di restrizioni che introduce REST, che neutralizza efficacemente i benefici di SOAP lasciandovi solo i suoi lati negativi. Potresti creare un'API semplificata con SOAP, ma non sarebbe mai così facile da usare come REST, quindi in pratica tutti scelgono REST.

Non puoi confrontare REST e SOAP. REST è uno stile architettonico mentre SOAP è un protocollo.

Sfortunatamente, REST è diventato un sinonimo colloquiale sinonimo di servizio HTTP RESTful, ovvero una realizzazione dell'architettura in stile REST con protocollo HTTP come (applicazione).

REST si basa sui seguenti principi (vincoli ed elementi) (tra parentesi la realizzazione in HTTP RESTful) [1] .

• Stateless (HTTP è un protocollo stateless)
• Risorsa (identificata dagli URI)
• Interfaccia uniforme (metodi HTTP)
• Rappresentazione (MIME-TYPE)
• HATEOS (collegamenti ipertestuali)
• Cache (cache HTTP)

Dall'altro lato, molte persone intendono dire SOAP un servizio web basato su WSDL e SOAP che fanno parte dell'architettura del servizio web W3C [2] .

• SOAP viene utilizzato come protocollo per lo scambio di informazioni (fondamentalmente nome del metodo, parametri, valori di ritorno, tipi di dati, ...).
• WSDL una lingua di definizione dell'interfaccia per descrivere il servizio Web.

What is the present-day significance of SOAP*?

SOAP è uno standard W3C ed è utilizzato come formato di scambio di informazioni nei servizi Web W3C. Quei servizi web erano - specialmente durante l'hype delle SOA (archi- tetture orientate ai servizi) intorno al 2008 (+ - 3 anni) - e (sfortunatamente) sono ancora implementati principalmente nelle applicazioni aziendali.

Questo ha diverse ragioni. Allora HTTP RESTful non era ben noto ed è stato frainteso. Sfortunatamente, è ancora incompreso per dare un'occhiata alle altre risposte

„[...]REST is much more limited than SOAP[...].“

„The primary purpose of REST is to represent resources on the Internet[...].“

Inoltre, SOAP (e WSDL) fanno parte dello stack di protocolli del servizio Web W3C che fornisce ancora più standard per l'implementazione di un servizio Web.

Are people still developing new SOAP-based APIs, or it's mostly a legacy now?

Quindi sì, ci sono ancora e ci saranno anche nei sistemi futuri là fuori che stanno usando SOAP (almeno nei sistemi aziendali, soprattutto dietro le porte). Ma la maggior parte sta cercando di fare una specie di "REST" al giorno d'oggi.

Can someone please correct me if I am wrong about this difference between SOAP and REST?

Dire REST è un'architettura stateless più flessibile per il trasferimento dei dati non è una buona spiegazione. REST semplicemente parlato è uno stile di architettura con vincoli ed elementi specifici. Considerando che SOAP è un protocollo di scambio di informazioni.

Come ho già scritto, non puoi confrontarli. Ma puoi confrontare un servizio Web HTTP RESTful con un servizio Web SOAP / WSDL.