SOAP vs REST (differenze)

Ho letto articoli sulle differenze tra SOAP e REST come protocollo di comunicazione del servizio Web, ma penso che i maggiori vantaggi di REST su SOAP siano:

1. REST è più dinamico, non è necessario creare e aggiornare UDDI (Universal Description, Discovery e Integration).

2. REST non è limitato al solo formato XML. I servizi Web RESTful possono inviare testo semplice / JSON / XML.

Ma SOAP è più standardizzato (es. Sicurezza).

Quindi, ho ragione in questi punti?

Sfortunatamente, ci sono molte informazioni sbagliate e idee sbagliate su REST. Non solo la tua domanda e la risposta di @cmd riflettono quelle, ma la maggior parte delle domande e risposte relative all'argomento su Stack Overflow.

SOAP e REST non possono essere confrontati direttamente, poiché il primo è un protocollo (o almeno cerca di esserlo) e il secondo è uno stile architettonico. Questa è probabilmente una delle fonti di confusione intorno ad essa, poiché le persone tendono a chiamare REST qualsiasi API HTTP che non sia SOAP.

Spingendo un po 'le cose e cercando di stabilire un confronto, la differenza principale tra SOAP e REST è il grado di accoppiamento tra implementazioni client e server. Un client SOAP funziona come un'applicazione desktop personalizzata, strettamente accoppiata al server. Esiste un contratto rigido tra client e server e ci si aspetta che tutto si rompa se entrambe le parti cambiano qualcosa. Hai bisogno di aggiornamenti costanti a seguito di qualsiasi modifica, ma è più facile accertare se il contratto è stato seguito.

Un client REST è più simile a un browser. È un client generico che sa come utilizzare un protocollo e metodi standardizzati e un'applicazione deve adattarsi a questo. Non violate gli standard del protocollo creando metodi aggiuntivi, sfruttate i metodi standard e create le azioni con essi sul vostro tipo di supporto. Se fatto bene, c'è meno accoppiamento e le modifiche possono essere affrontate con più grazia. Un client dovrebbe entrare in un servizio REST con nessuna conoscenza dell'API, ad eccezione del punto di ingresso e del tipo di supporto. In SOAP, il cliente ha bisogno di conoscenze precedenti su tutto ciò che utilizzerà o non inizierà nemmeno l'interazione. Inoltre, un client REST può essere esteso tramite il codice su richiesta fornito dal server stesso,

Penso che questi siano i punti cruciali per capire di cosa tratta REST e come si differenzia da SOAP:

• REST è indipendente dal protocollo. Non è accoppiato a HTTP. Praticamente come se fosse possibile seguire un collegamento ftp su un sito Web, un'applicazione REST può utilizzare qualsiasi protocollo per il quale esiste uno schema URI standardizzato.

• REST non è una mappatura dei metodi CRUD su HTTP. Leggi questa risposta per una spiegazione dettagliata al riguardo.

• REST è standardizzato come le parti in uso. La sicurezza e l'autenticazione in HTTP sono standardizzate, quindi è quello che usi quando fai REST su HTTP.

• REST non è REST senza hypermedia e HATEOAS . Ciò significa che un client conosce solo l'URI del punto di ingresso e le risorse dovrebbero restituire i collegamenti che il client dovrebbe seguire. Quei generatori di documentazione fantasiosi che danno schemi URI per tutto ciò che puoi fare in un'API REST perdono completamente il punto. Non stanno solo documentando qualcosa che dovrebbe seguire lo standard, ma quando lo fai, stai accoppiando il client a un momento particolare nell'evoluzione dell'API e qualsiasi modifica all'API deve essere documentata e applicata, o si romperà.

• REST è lo stile architettonico del web stesso. Quando inserisci Stack Overflow, sai cosa sono un utente, una domanda e una risposta, conosci i tipi di media e il sito web ti fornisce i collegamenti ad essi. Un'API REST deve fare lo stesso. Se progettassimo il Web nel modo in cui le persone pensano che REST dovrebbe essere fatto, invece di avere una home page con collegamenti a domande e risposte, avremmo una documentazione statica che spiega che per visualizzare una domanda, devi prendere l'URI stackoverflow.com/questions/<id>, sostituisci id con Question.id e incollalo sul tuo browser. Questa è una sciocchezza, ma è quello che molte persone pensano che sia REST.

Quest'ultimo punto non può essere enfatizzato abbastanza. Se i tuoi clienti stanno creando URI da modelli nella documentazione e non stanno ottenendo collegamenti nelle rappresentazioni delle risorse, questo non è REST. Roy Fielding, l'autore di REST, ha chiarito in questo post del blog: le API REST devono essere guidate dall'ipertesto .

Tenendo presente quanto sopra, ti renderai conto che mentre REST potrebbe non essere limitato a XML, per farlo correttamente con qualsiasi altro formato dovrai progettare e standardizzare un formato per i tuoi collegamenti. I collegamenti ipertestuali sono standard in XML, ma non in JSON. Esistono bozze di standard per JSON, come HAL .

Infine, REST non è per tutti, e una prova di ciò è come la maggior parte delle persone risolve molto bene i propri problemi con le API HTTP che hanno erroneamente chiamato REST e non si avventurano mai oltre. A volte è difficile eseguire REST, soprattutto all'inizio, ma paga nel tempo con una più facile evoluzione sul lato server e la resilienza del client alle modifiche. Se hai bisogno di qualcosa fatto rapidamente e facilmente, non preoccuparti di ottenere il REST giusto. Probabilmente non è quello che stai cercando. Se hai bisogno di qualcosa che dovrà rimanere online per anni o addirittura decenni, allora REST fa per te.

RESTvs nonSOAP è la domanda giusta da porre.

REST, a differenza di nonSOAP è un protocollo.

RESTè uno stile architettonico e un progetto per architetture software basate su rete.

RESTi concetti sono indicati come risorse. Una rappresentazione di una risorsa deve essere apolide. È rappresentato tramite un tipo di supporto. Alcuni esempi di tipi di supporto comprendono XML, JSONe RDF. Le risorse sono manipolate dai componenti. I componenti richiedono e manipolano le risorse tramite un'interfaccia uniforme standard. Nel caso di HTTP, questa interfaccia è costituito da OPS HTTP standard ad esempio GET, PUT, POST, DELETE.

La domanda di @ Abdulaziz chiarisce il fatto che RESTe HTTPsono spesso usati in tandem. Ciò è dovuto principalmente alla semplicità di HTTP e alla sua mappatura molto naturale ai principi RESTful.

Principi fondamentali di REST

Comunicazione client-server

Le architetture client-server hanno una netta separazione di preoccupazioni. Tutte le applicazioni costruite nello stile RESTful devono anche essere client-server in linea di principio.

apolide

Ogni richiesta client al server richiede che il suo stato sia completamente rappresentato. Il server deve essere in grado di comprendere completamente la richiesta del client senza utilizzare alcun contesto o stato della sessione del server. Ne consegue che tutto lo stato deve essere mantenuto sul client.

cacheable

È possibile utilizzare i vincoli della cache, consentendo così di contrassegnare i dati di risposta come memorizzabili nella cache o non memorizzabili nella cache. Tutti i dati contrassegnati come memorizzabili nella cache possono essere riutilizzati come risposta alla stessa richiesta successiva.

Interfaccia uniforme

Tutti i componenti devono interagire attraverso un'unica interfaccia uniforme. Poiché tutte le interazioni tra componenti si verificano tramite questa interfaccia, l'interazione con servizi diversi è molto semplice. L'interfaccia è la stessa! Questo significa anche che le modifiche all'implementazione possono essere fatte isolatamente. Tali modifiche non influiranno sull'interazione dei componenti fondamentali poiché l'interfaccia uniforme è sempre invariata. Uno svantaggio è che sei bloccato con l'interfaccia. Se è possibile fornire un'ottimizzazione a un servizio specifico modificando l'interfaccia, si è sfortunati poiché REST lo proibisce. Il lato positivo, tuttavia, REST è ottimizzato per il web, quindi incredibile popolarità di REST su HTTP!

I concetti di cui sopra rappresentano le caratteristiche distintive di REST e differenziano l'architettura REST da altre architetture come i servizi web. È utile notare che un servizio REST è un servizio Web, ma un servizio Web non è necessariamente un servizio REST.

Vedi questo post sul blog sui principi di progettazione REST per maggiori dettagli su REST e i punti elenco sopra indicati.

EDIT: aggiorna il contenuto in base ai commenti

SOAP ( Simple Object Access Protocol ) e REST ( Representation State Transfer ) sono entrambi meravigliosi a modo loro. Quindi non li sto confrontando. Invece, sto cercando di rappresentare l'immagine, quando ho preferito usare REST e quando SOAP.

Cos'è il payload?

Quando i dati vengono inviati su Internet, ogni unità trasmessa include sia le informazioni dell'intestazione sia i dati effettivi inviati. L'intestazione identifica l'origine e la destinazione del pacchetto, mentre i dati effettivi vengono definiti payload . In generale, il payload è costituito dai dati trasportati per conto di un'applicazione e dai dati ricevuti dal sistema di destinazione.

Ora, ad esempio, devo inviare un telegramma e sappiamo tutti che il costo del telegramma dipenderà da alcune parole.

Quindi dimmi tra i due citati di seguito, quale è più economico da inviare?

<name>Arin</name>

o

"name": "Arin"

So che la tua risposta sarà la seconda, sebbene entrambe rappresentino lo stesso messaggio, la seconda è più economica in termini di costi.

Quindi sto cercando di dire che, l' invio di dati in rete in formato JSON è più economico rispetto all'invio in formato XML per quanto riguarda il payload .

Ecco i primi vantaggi o vantaggi di REST su SOAP . SOAP supporta solo XML, ma REST supporta formati diversi come testo, JSON, XML, ecc. E sappiamo già che, se utilizziamo Json, saremo sicuramente in una posizione migliore per quanto riguarda il payload.

Ora, SOAP supporta l'unico XML, ma ha anche i suoi vantaggi.

Veramente! Come?

SOAP si basa su XML in tre modi Envelope: questo definisce ciò che è nel messaggio e come elaborarlo.

Un insieme di regole di codifica per i tipi di dati e infine il layout delle chiamate di procedura e delle risposte raccolte.

Questa busta viene inviata tramite un trasporto (HTTP / HTTPS) e viene eseguito un RPC (Remote Procedure Call) e la busta viene restituita con le informazioni in un documento in formato XML.

Il punto importante è che uno dei vantaggi di SOAP è l'uso del trasporto "generico", ma REST utilizza HTTP / HTTPS . SOAP può utilizzare quasi tutti i mezzi di trasporto per inviare la richiesta, ma REST no. Quindi qui abbiamo il vantaggio di usare SOAP.

Come ho già accennato nel paragrafo precedente "REST utilizza HTTP / HTTPS" , quindi approfondisci un po 'queste parole.

Quando parliamo di REST su HTTP, tutte le misure di sicurezza applicate HTTP vengono ereditate e questo è noto come sicurezza a livello di trasporto e protegge i messaggi solo mentre si trova all'interno del filo ma una volta che lo hai consegnato dall'altra parte non lo sai quante fasi dovrà passare prima di raggiungere il punto reale in cui i dati verranno elaborati. E, naturalmente, tutte quelle fasi potrebbero usare qualcosa di diverso rispetto a HTTP. Quindi il riposo non è completamente più sicuro, giusto?

Ma SOAP supporta SSL proprio come REST , inoltre supporta anche WS-Security che aggiunge alcune funzionalità di sicurezza aziendale. WS-Security offre protezione dalla creazione del messaggio al suo consumo . Quindi, per la sicurezza a livello di trasporto qualunque scappatoia abbiamo trovato che può essere evitato usando WS-Security.

A parte questo, poiché REST è limitato dal suo protocollo HTTP, quindi il suo supporto alle transazioni non è né conforme ACID né può fornire commit in due fasi su risorse transnazionali distribuite.

Ma SOAP ha un supporto completo sia per la gestione delle transazioni basata su ACID per transazioni di breve durata sia per la gestione delle transazioni basata sulla compensazione per transazioni di lunga durata. Supporta inoltre il commit in due fasi tra risorse distribuite .

Non sto tracciando alcuna conclusione, ma preferirò il servizio web basato su SOAP mentre la sicurezza, le transazioni, ecc. Sono le preoccupazioni principali.

Ecco il "Tutorial Java EE 6" in cui hanno affermato che un progetto RESTful può essere appropriato quando sono soddisfatte le seguenti condizioni . Dare un'occhiata.

Spero ti sia piaciuto leggere la mia risposta.

REST ( RE presentation S tate T ransfer)
RE presentational S tate of a Object is T ransferred is REST ie non inviamo Object, inviamo lo stato di Object. REST è uno stile architettonico. Non definisce così tanti standard come SOAP. REST serve per esporre API pubbliche (ad esempio API di Facebook, API di Google Maps) su Internet per gestire le operazioni CRUD sui dati. REST si concentra sull'accesso alle risorse denominate attraverso un'unica interfaccia coerente.

SOAP ( S imple O bject A ccess P rotocol)
SOAP porta il proprio protocollo e si concentra sull'esposizione di parti di logica applicativa (non dati) come servizi. SOAP espone le operazioni. SOAP si concentra sull'accesso alle operazioni denominate, ogni operazione implementa alcune logiche aziendali. Sebbene SOAP sia comunemente indicato come servizi Web, questo è improprio. SOAP ha poco o nulla a che fare con il Web. REST fornisce veri servizi Web basati su URI e HTTP.

Perché riposare?

• Poiché REST utilizza HTTP standard, è molto più semplice quasi sempre.
• REST è più facile da implementare, richiede meno larghezza di banda e risorse.
• REST consente molti formati di dati diversi in cui SOAP consente solo XML.
• REST consente un supporto migliore per i client browser grazie al supporto per JSON.
• REST ha prestazioni e scalabilità migliori. Le letture REST possono essere memorizzate nella cache, le letture basate su SOAP non possono essere memorizzate nella cache.
• Se la sicurezza non è una delle maggiori preoccupazioni e abbiamo risorse limitate. Oppure vogliamo creare un'API che sarà facilmente utilizzata da altri sviluppatori pubblicamente, quindi dovremmo andare con REST.
• Se abbiamo bisogno di operazioni CRUD senza stato, vai con REST.
• REST è comunemente usato nei social media, nella chat web, nei servizi mobili e nelle API pubbliche come Google Maps.
• Il servizio RESTful restituisce vari MediaTypes per la stessa risorsa, a seconda del parametro dell'intestazione della richiesta "Accetta" come application/xmlo application/jsonper POST e /user/1234.jsono GET /user/1234.xmlper GET.
• I servizi REST devono essere chiamati dall'applicazione lato client e non direttamente dall'utente finale.
• ST nel resto proviene da S tato T ransfer. Si trasferisce lo stato in giro invece che il server lo memorizzi, questo rende i servizi REST scalabili.

Perché sapone?

• SOAP non è molto facile da implementare e richiede più larghezza di banda e risorse.
• La richiesta di messaggio SOAP viene elaborata più lentamente rispetto a REST e non utilizza il meccanismo di memorizzazione nella cache Web.
• Sicurezza WS: Mentre SOAP supporta SSL (proprio come REST) ​​supporta anche WS-Security che aggiunge alcune funzionalità di sicurezza aziendale.
• WS-AtomicTransaction: hai bisogno di transazioni ACID su un servizio, avrai bisogno di SOAP.
• WS-ReliableMessaging: se l'applicazione richiede l'elaborazione asincrona e un livello garantito di affidabilità e sicurezza. Rest non ha un sistema di messaggistica standard e si aspetta che i clienti gestiscano gli errori di comunicazione tentando nuovamente.
• Se la sicurezza è una delle maggiori preoccupazioni e le risorse non sono limitate, allora dovremmo usare i servizi web SOAP. Come se stiamo creando un servizio web per gateway di pagamento, lavori finanziari e di telecomunicazione, dovremmo andare con SOAP poiché qui è necessaria un'elevata sicurezza.

source1
source2

Differenza tra riposo e sapone

SAPONE

1. SOAP è un protocollo.
2. SOAP è l'acronimo di Simple Object Access Protocol.
3. SOAP non può usare REST perché è un protocollo.
4. SOAP utilizza interfacce di servizi per esporre la logica aziendale.
5. SOAP definisce gli standard da seguire rigorosamente.
6. SOAP richiede più larghezza di banda e risorse rispetto a REST.
7. SOAP definisce la propria sicurezza.
8. SOAP consente solo il formato dati XML.
9. SOAP è meno preferito di REST.

RIPOSO

1. REST è uno stile architettonico.
2. REST è l'acronimo di Representational State Transfer.
3. REST può utilizzare i servizi Web SOAP perché è un concetto e può utilizzare qualsiasi protocollo come HTTP, SOAP.
4. REST utilizza l'URI per esporre la logica aziendale.
5. REST non definisce troppi standard come SOAP.
6. REST richiede meno larghezza di banda e risorse rispetto a SOAP.
7. I servizi Web RESTful ereditano le misure di sicurezza dal trasporto sottostante.
8. REST consente diversi formati di dati come testo normale, HTML, XML, JSON ecc.
9. RESTO più preferito di SAPONE.

Per maggiori dettagli, consultare qui

IMHO non puoi confrontare SOAP e REST dove quelle sono due cose diverse.

SOAP è un protocollo e REST è un modello architettonico del software. C'è un sacco di equivoci in Internet per SOAP vs REST .

SOAP definisce un formato di messaggio basato su XML che le applicazioni abilitate ai servizi Web utilizzano per comunicare reciprocamente su Internet. Per fare ciò le applicazioni richiedono una conoscenza preliminare del contratto di messaggio, dei tipi di dati, ecc.

REST rappresenta lo stato (come risorse) di un server da un URL. È apolide e i client non dovrebbero avere conoscenze preliminari per interagire con il server oltre la comprensione dell'hypermedia.

Prima di tutto: ufficialmente, la domanda corretta sarebbe web services + WSDL + SOAPvs REST.

Perché, sebbene il servizio Web , sia utilizzato in senso lato, quando si utilizza il protocollo HTTP per trasferire dati anziché pagine Web, ufficialmente è una forma molto specifica di quell'idea. Secondo la definizione, REST non è "servizio web".

In pratica, tuttavia, tutti lo ignorano, quindi ignoriamolo anche noi

Ci sono già risposte tecniche, quindi proverò a fornire alcune intuizioni.

Supponiamo che tu voglia chiamare una funzione in un computer remoto, implementata in qualche altro linguaggio di programmazione (questo è spesso chiamato chiamata di procedura remota / RPC ). Supponiamo che la funzione sia disponibile in un URL specifico, fornito dalla persona che l'ha scritta. Devi (in qualche modo) inviargli un messaggio e ottenere una risposta. Quindi, ci sono due domande principali da considerare.

• qual è il formato del messaggio che dovresti inviare
• come dovrebbe essere portato avanti e indietro il messaggio

Per la prima domanda, la definizione ufficiale è WSDL . Questo è un file XML che descrive, in formato dettagliato e rigoroso, quali sono i parametri, quali sono i loro tipi, nomi, valori predefiniti, il nome della funzione da chiamare, ecc. Un esempio WSDL qui mostra che il file è umano leggibile (ma non facilmente).

Per la seconda domanda, ci sono varie risposte. Tuttavia, l'unico utilizzato nella pratica è SOAP . La sua idea principale è: avvolgere l'XML precedente (il messaggio effettivo) in un altro XML (contenente informazioni sulla codifica e altre cose utili) e inviarlo su HTTP. Il metodo POST dell'HTTP viene utilizzato per inviare il messaggio, poiché esiste sempre un corpo .

L'idea principale di questo intero approccio è che si associa un URL a una funzione , ovvero a un'azione . Pertanto, se si dispone di un elenco di clienti in alcuni server e si desidera visualizzare / aggiornare / eliminare uno, è necessario disporre di 3 URL:

• myapp/read-customer e nel corpo del messaggio, passa l'ID del cliente da leggere.
• myapp/update-customer e nel corpo, passare l'ID del cliente, così come i nuovi dati
• myapp/delete-customer e l'id nel corpo

L'approccio REST vede le cose diversamente. Un URL non dovrebbe rappresentare un'azione, ma una cosa (chiamata risorsa nel linguaggio REST). Poiché il protocollo HTTP (che stiamo già utilizzando) supporta i verbi, usa quei verbi per specificare quali azioni eseguire sulla cosa.

Quindi, con l'approccio REST, il cliente numero 12 verrebbe trovato sull'URL myapp/customers/12. Per visualizzare i dati del cliente, premi l'URL con una richiesta GET. Per eliminarlo, lo stesso URL, con un verbo DELETE. Per aggiornarlo, di nuovo, lo stesso URL con un verbo POST e il nuovo contenuto nel corpo della richiesta.

Per maggiori dettagli sui requisiti che un servizio deve soddisfare per essere considerato veramente RESTful, consultare il modello di maturità di Richardson . L'articolo fornisce esempi e, cosa più importante, spiega perché un servizio SOAP (cosiddetto) è un servizio REST di livello 0 (sebbene, livello 0 significhi bassa conformità a questo modello, non è offensivo ed è ancora utile in molti casi).

Tra le molte altre già trattate nelle molte risposte, vorrei evidenziare che SOAP consente di definire un contratto, il WSDL, che definisce le operazioni supportate, tipi complessi, ecc. SOAP è orientato alle operazioni, ma REST è orientato alle risorse. Personalmente selezionerei SOAP per interfacce complesse tra applicazioni aziendali interne e REST per interfacce pubbliche, più semplici, senza stato con il mondo esterno.

Aggiunta per:

++ Un errore che viene spesso commesso quando ci si avvicina al REST è quello di pensarlo come "servizi web con URL": pensare al REST come a un altro meccanismo di chiamata (RPC) di procedura remota, come SOAP, ma invocato tramite semplici URL HTTP e senza il pesante SOAP Spazi dei nomi XML.

++ Al contrario, REST ha poco a che fare con RPC. Mentre RPC è orientato al servizio e focalizzato su azioni e verbi, REST è orientato alle risorse, sottolineando le cose e i nomi che compongono un'applicazione.

Molte di queste risposte hanno completamente dimenticato di menzionare i controlli ipermediali (HATEOAS) che è completamente fondamentale per il REST. Alcuni altri l'hanno toccato, ma non lo hanno spiegato così bene.

Questo articolo dovrebbe spiegare la differenza tra i concetti, senza entrare nelle erbacce su specifiche funzionalità SOAP.