Quali sono i fattori decisivi nella scelta di esporre un servizio web come servizio SOAP o REST?

Per quanto posso vedere consumare SOAP richiede uno stack SOAP, quindi è più difficile consumare i tuoi clienti, cioè devono assicurarsi che dispongano di uno stack SOAP che formatta correttamente i dati POST e le intestazioni e poi ti restituisca un po ' struttura dei dati, mentre con REST fai una richiesta HTTP GET con gli argomenti nella stringa di query e recuperi del testo che suppongo sia probabilmente XML.

Quindi cosa ti offre l'overhead / complessità extra di SOAP, quando ne hai bisogno e quando potresti e dovresti farne a meno?

Ho implementato un'API REST prima e mi è davvero piaciuta. In generale, quando si implementa REST su SOAP, il client / server è più ortogonale, il che significa che è possibile modificare molto più liberamente il server senza influire sui client. Questa ortogonalità è dovuta all'utilizzo di una comunicazione più astratta e già ben definita tramite verbi HTTP. Inoltre, l'uso di collegamenti ipertestuali incorporati nelle risposte REST semplifica l'estensione e la crescita dell'API in modo relativamente indolore. I clienti dovrebbero seguire questi collegamenti incorporati per accedere a nuove risorse come un umano seguirebbe i collegamenti su una pagina Web per "approfondire" per ulteriori informazioni.

Detto questo, ho avuto alcuni colleghi a cui è stato detto che dovevano usare il SAPONE e si sono sempre lamentati. Quindi sono andato a ricercare i due un po 'più in dettaglio.

In generale quello che ho scoperto è che REST è adatto per applicazioni altamente distribuite , quando si hanno centinaia, migliaia o milioni di client . Uno dei motivi è l'ortogonalità sopra menzionata, un altro è la memorizzazione nella cache che si ottiene gratuitamente poiché si utilizza HTTP.

SOAP potrebbe essere il modo più rapido di procedere quando hai bisogno di un'API più piccola per un client o due rapidamente e non sei troppo preoccupato per la scalabilità. Potrebbe anche adattarsi meglio se non si dispone di un'architettura strutturata in base alle risorse , perché potrebbe volerci del tempo per ristrutturare l'app per poter persino implementare REST.

Potrebbe essere un punto secondario, ma REST è interamente basato su HTTP.

SOAP non richiede HTTP e sei libero di utilizzare qualsiasi mezzo di trasporto ti piaccia.

I messaggi SOAP possono essere instradati in modo asincrono e affidabile, mentre REST è praticamente un paradigma sincrono.

REST non ti dice nulla su come dovrebbero apparire i dati che stai inviando e ricevendo. C'è WADL, ma per lo più fai affidamento sul fatto che la documentazione dell'API sia corretta. SOAP ha un circo di tecnologie XML per rendere la descrizione dei dati meno soggetta a errori. WSDL, Schema ...

Alla fine della giornata REST fondamentalmente ti fornisce un file system basato su HTTP. Se il tuo sistema può adattarsi a quel paradigma, allora potrebbe essere una buona scelta.

Quindi cosa ti offre l'overhead / complessità extra di SOAP, quando ne hai bisogno e quando potresti e dovresti farne a meno?

La più grande differenza tra i due è che il REST è supposto essere apolide, laddove SOAP non lo è . In pratica molte implementazioni REST implementano effettivamente uno stato nella sessione attraverso qualcosa come OAuth.

Un'altra differenza è che REST è molto "risorsa" o orientato al nome . Interagisci con le risorse tramite operazioni CRUD. Tutto ciò che non si adatta a questo paradigma diventa ingombrante e imbarazzante.

D'altra parte SOAP è solo un protocollo RPC (chiamata di procedura remota) . Non viene fornito con un paradigma, è solo il livello di trasporto.

REST utilizza anche la posta. In effetti, quando si utilizza REST, i verbi http indicano l'operazione in corso.

REST e SOAP sono solo standard diversi per il passaggio di dati su Internet.

Avendo usato entrambi raccomanderei generalmente di usare REST piuttosto che SOAP a meno che tu non sappia che le persone che consumeranno il tuo servizio web stanno usando .net e Visual Studio. In genere è molto più semplice consumare un servizio web REST tranne che con .net VS che fa la maggior parte del lavoro per te quando usi SOAP.

Una cosa che vorrei menzionare è l'interoperabilità: se hai intenzione di chiamare il tuo servizio da un'app scritta in .NET e il server è scritto in Java (o qualsiasi altra combinazione), scegli REST. Ho visto troppe lievi incompatibilità tra le implementazioni SOAP per preoccuparmi di considerarlo più.

Se desideri semplicemente una guida visiva semplice che ti aiuti a misurare SOAP e REST rispetto ai requisiti delle tue applicazioni ...

Vijay Prasad Gupta ha messo insieme un diagramma di flusso semplice e utile.

Link diretto al diagramma di flusso: https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit

Link all'articolo: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs

Ora è il 2015. Avrei sperato che ormai SOAP fosse morto, ma persiste ancora come un cattivo odore. A parte le applicazioni "esemplificative" di base, l'integrazione con un servizio SOAP è piena di sfide. È un'architettura complessa, con molte opzioni a più livelli, combinata con le stranezze di implementazioni multiple e incompatibilità sottili (e non così sottili). Non ho mai avuto una sola buona esperienza con esso. REST, d'altra parte, è un gioco da ragazzi: tutti capiscono HTTP. Nella maggior parte dei casi, JSON ha quindi molta più utilità di XML InfoSet.

Per darti un'idea della complessità di SOAP, prova a integrare una libreria SOAP nel tuo progetto. Per Java, il client Apache Axis2 più semplice (usando un semplice binding di dati ADB) inserisce 23 nuovi JAR. Ventitré! 20 MB di libreria gonfia. CXF è simile: 21 JAR, quando ho contato l'ultima volta.

Se lo desideri davvero, puoi eseguire REST con una semplice libreria HTTP.