it-swarm-eu.dev

SOAP o REST per i servizi Web?

REST è un approccio migliore all'esecuzione di servizi Web o è SOAP? O sono strumenti diversi per problemi diversi? O è una questione sfumata - cioè, è leggermente migliore in alcune arene rispetto a un altro, ecc.?

Gradirei in particolare informazioni su questi concetti e sulla loro relazione con l'universo PHP e anche le moderne applicazioni web di fascia alta.

378
user13276

Ho creato uno dei primi SOAP server, inclusa la generazione di codice e generazione WSDL, dalle specifiche originali durante lo sviluppo, mentre lavoravo a Hewlett-Packard. NON consiglio di usare SOAP per nulla.

L'acronimo "SOAP" è una bugia. Non è semplice, non è orientato agli oggetti, non definisce regole di accesso. È, probabilmente, un protocollo. È la peggior specifica di Don Box di sempre, ed è una vera impresa, dato che è l'uomo che ha perpetrato "COM".

Non c'è nulla di utile in SOAP che non può essere fatto con REST per il trasporto e JSON, XML o persino testo semplice per la rappresentazione dei dati. Per la sicurezza dei trasporti, è possibile utilizzare https. Per l'autenticazione, autenticazione di base. Per le sessioni, ci sono i cookie. La versione REST sarà più semplice, più chiara, funzionerà più velocemente e utilizzerà meno larghezza di banda.

XML-RPC definisce chiaramente i protocolli di richiesta, risposta ed errore e ci sono buone librerie per la maggior parte delle lingue. Tuttavia, XML è più pesante del necessario per molte attività.

560
mdhughes

REST è un'architettura, SOAP è un protocollo.

Questo è il primo problema.

È possibile inviare SOAP buste in un'applicazione REST.

SOAP stesso è in realtà piuttosto semplice e semplice, sono gli standard WSS- * che lo rendono molto complesso.

Se i tuoi consumatori sono altre applicazioni e altri server, oggi c'è molto supporto per il protocollo SOAP e le basi dello spostamento dei dati sono essenzialmente un clic del mouse nei moderni IDE.

Se i tuoi consumatori hanno maggiori probabilità di essere clienti RIA o Ajax, probabilmente vorrai qualcosa di più semplice di SOAP e più nativo per il cliente (in particolare JSON).

I pacchetti JSON inviati su HTTP non sono necessariamente un'architettura REST, sono solo messaggi agli URL. Tutto perfettamente funzionante, ma ci sono componenti chiave nel linguaggio REST. Tuttavia, è facile confondere i due. Ma solo perché stai parlando di richieste HTTP non significa necessariamente che hai un'architettura REST. Puoi avere un'applicazione REST senza HTTP (attenzione, questo è raro).

Pertanto, se si dispone di server e utenti "a proprio agio" con SOAP, SOAP e stack WSS possono essere utili. Se stai facendo più cose ad hoc e vuoi interfacciarti meglio con i browser Web, allora anche alcuni protocolli più leggeri su HTTP possono funzionare bene.

197
Will Hartung

REST è un paradigma sostanzialmente diverso da SOAP. Una buona lettura su REST può essere trovata qui: Come ho spiegato REST a mia moglie .

Se non hai tempo di leggerlo, ecco la versione breve: REST è un po 'un cambio di paradigma concentrandosi su "sostantivi" e limitando il numero di "verbi" che puoi applicare a quelli sostantivi. Gli unici verbi ammessi sono "get", "put", "post" ed "delete". Ciò differisce da SOAP dove molti verbi diversi possono essere applicati a molti nomi diversi (cioè molte funzioni diverse).

Per REST, i quattro verbi sono associati alle richieste HTTP corrispondenti, mentre i nomi sono identificati da URL. Ciò rende la gestione dello stato molto più trasparente rispetto a SOAP, dove spesso non è chiaro quale sia lo stato sul server e ciò che è sul client.

In pratica, sebbene la maggior parte di questo scompaia, e REST di solito si riferisce solo a semplici richieste HTTP che restituiscono risultati in JSON , mentre SOAP è un altro API complesse che comunicano passando XML. Entrambi hanno i loro vantaggi e svantaggi, ma ho scoperto che nella mia esperienza REST di solito è la scelta migliore perché raramente, se mai, hai bisogno della piena funzionalità che ottieni da SOAP.

102
toluju

Abbassamento rapido per la domanda 2012:

Le aree per cui REST funziona davvero bene sono:

  • Larghezza di banda e risorse limitate. Ricorda che la struttura di ritorno è realmente in qualsiasi formato (definito dallo sviluppatore). Inoltre, è possibile utilizzare qualsiasi browser poiché l'approccio REST utilizza i verbi GET, PUT, POST e DELETE standard. Ancora una volta, ricorda che REST può anche usare l'oggetto XMLHttpRequest che la maggior parte dei browser moderni supporta oggi, il che aggiunge un ulteriore bonus di AJAX.

  • Operazioni totalmente senza stato. Se un'operazione deve essere continuata, allora REST non è l'approccio migliore e SOAP potrebbe adattarsi meglio. Tuttavia, se hai bisogno di operazioni CRUD (Crea, Leggi, Aggiorna ed Elimina) senza stato, allora REST lo è.

  • Situazioni di memorizzazione nella cache. Se le informazioni possono essere memorizzate nella cache a causa dell'operazione totalmente senza stato dell'approccio REST, questo è perfetto. molte soluzioni nelle tre precedenti.

Quindi perché dovrei anche prendere in considerazione SOAP? Ancora una volta, SOAP è abbastanza maturo e ben definito e include una specifica completa. L'approccio REST è proprio questo, un approccio ed è ampiamente aperto allo sviluppo, quindi se hai i seguenti, SOAP è un'ottima soluzione:

  • Elaborazione e invocazione asincrona. Se l'applicazione richiede un livello di affidabilità e sicurezza garantiti, allora SOAP 1.2 offre standard aggiuntivi per garantire questo tipo di funzionamento. Cose come WSRM - WS-Reliable Messaging.

  • Contratti formali. Se entrambe le parti (fornitore e consumatore) devono concordare il formato di scambio, SOAP 1.2 fornisce le rigide specifiche per questo tipo di interazione.

  • Operazioni con stato. Se l'applicazione necessita di informazioni contestuali e gestione dello stato conversazionale, allora SOAP 1.2 ha le specifiche aggiuntive nella struttura WS * per supportare queste cose (sicurezza, transazioni, coordinamento, ecc.). Comparativamente, l'approccio REST consentirebbe agli sviluppatori di creare questo impianto idraulico personalizzato.

http://www.infoq.com/articles/rest-soap-when-to-use-each

59
PmanAce

SOAP attualmente ha il vantaggio di strumenti migliori in cui genereranno molto codice della piastra di caldaia sia per il livello di servizio che per generare client da un dato WSDL.

REST è più semplice, di conseguenza può essere più semplice da mantenere, si trova al centro dell'architettura Web, consente una migliore visibilità del protocollo ed è stato dimostrato che si adatta alle dimensioni del WWW stesso. Alcuni framework là fuori ti aiutano a creare REST servizi, come Ruby su Rails, e alcuni ti aiutano persino a scrivere client, come ADO.NET Data Services. Ma per la maggior parte, manca il supporto degli strumenti.

44
Mark Cidade

SOAP è utile dal punto di vista degli utensili perché il WSDL è così facilmente consumato dagli strumenti. Quindi, puoi ottenere i client dei servizi Web generati per te nella tua lingua preferita.

REST funziona bene con le pagine Web di AJAX. Se mantieni semplici le tue richieste, puoi effettuare chiamate di servizio direttamente dal tuo JavaScript, e questo è molto utile. Cerca di stare lontano dall'avere qualsiasi spazio dei nomi nel tuo XML di risposta, ho visto i browser soffocare su quelli. Quindi, xsi: type probabilmente non funzionerà per te, senza schemi XML eccessivamente complessi.

REST tende ad avere anche prestazioni migliori. I requisiti della CPU del codice che genera risposte REST tendono ad essere inferiori rispetto a quelli mostrati dai framework SOAP. E, se hai le anatre di generazione XML allineate sul lato server, puoi trasmettere in modo efficace l'XML al client. Quindi, immagina di leggere righe del cursore del database. Mentre leggi una riga, la formatti come un elemento XML e lo scrivi direttamente al consumatore del servizio. In questo modo, non è necessario raccogliere tutte le righe del database in memoria prima di iniziare a scrivere l'output XML: leggere e scrivere contemporaneamente. Cerca in nuovi motori di template o XSLT per far funzionare lo streaming per REST.

D'altra parte, SOAP tende a essere generato da servizi generati da strumenti come un grande blob e solo allora scritto. Questa non è una verità assoluta, intendiamoci, ci sono modi per ottenere le caratteristiche di streaming da SOAP, come usando gli allegati.

Il mio processo decisionale è il seguente: se voglio che il mio servizio sia facilmente gestibile dai consumatori e i messaggi che scrivo saranno di dimensioni medio-piccole (10 MB o meno) e non mi dispiace bruciare qualche CPU aggiuntiva Cicli sul server, vado con SOAP. Se devo servire a AJAX sui browser web, o ho bisogno della cosa per lo streaming, o le mie risposte sono gigantesche, vado REST.

Infine, ci sono molti grandi standard sviluppati attorno a SOAP, come WS-Security e ottenere servizi Web con stato, a cui puoi collegarti se stai usando gli strumenti giusti. Questo tipo di cose fa davvero la differenza e può aiutarti a soddisfare alcuni requisiti pelosi.

40
Dave Woldrich

So che questa è una vecchia domanda, ma devo pubblicare la mia risposta - forse qualcuno la troverà utile. Non riesco a credere a quante persone stiano raccomandando REST su SOAP. Posso solo supporre che queste persone non siano sviluppatori o che non abbiano mai implementato un servizio REST di dimensioni ragionevoli. L'implementazione di un servizio REST richiede MOLTO più tempo dell'implementazione di un servizio SOAP. E alla fine esce anche molto più disordinato. Ecco i motivi per cui sceglierei SOAP 99% delle volte:

1) L'implementazione di un servizio REST richiede infinitamente più tempo rispetto all'implementazione di un servizio SOAP. Esistono strumenti che tutti i linguaggi/framework/piattaforme moderni possono leggere in un WSDL e generare classi e client proxy. L'implementazione di un servizio REST viene eseguita manualmente e - ottieni - leggendo la documentazione. Inoltre, durante l'implementazione di questi due servizi, devi fare delle "ipotesi" su cosa tornerà attraverso la pipe in quanto non esiste uno schema reale o un documento di riferimento.

2) Perché scrivere un servizio REST che restituisca comunque XML? L'unica differenza è che con REST non conosci i tipi rappresentati da ciascun elemento/attributo: sei tu stesso a implementarlo e speri che un giorno non si trovi una stringa in un campo il pensiero era sempre un int. SOAP definisce la struttura dei dati utilizzando WSDL, quindi questo è un gioco da ragazzi.

3) Ho sentito il reclamo che con SOAP hai il "sovraccarico" di SOAP Envelope. Al giorno d'oggi, dobbiamo davvero preoccuparci di una manciata di byte?

4) Ho sentito l'argomento che con REST puoi semplicemente inserire l'URL nel browser e vedere i dati. Certo, se il tuo servizio REST utilizza un'autenticazione semplice o nulla. Il servizio Netflix, ad esempio, utilizza OAuth che richiede di firmare e codificare le cose prima ancora di poter inviare la richiesta.

5) Perché abbiamo bisogno di un URL "leggibile" per ogni risorsa? Se stessimo utilizzando uno strumento per implementare il servizio, ci preoccupiamo davvero dell'URL effettivo?

Devo andare avanti?

29
Josh M.

La maggior parte delle applicazioni che scrivo sono C # lato server o Java o applicazioni desktop in WinForms o WPF. Queste applicazioni hanno bisogno di un'API di servizio più ricca di quella che REST può fornire. Inoltre, non voglio dedicare più di un paio di minuti alla creazione del mio client di servizi web. Gli strumenti di generazione del client di elaborazione WSDL mi consentono di implementare il mio client e passare all'aggiunta di valore aziendale.

Ora, se stessi scrivendo un servizio web esplicitamente per alcune chiamate javascript ajax, probabilmente sarebbe in REST; solo per il gusto di conoscere la tecnologia client e sfruttare JSON. A mio avviso, le API dei servizi Web utilizzate da JavaScript probabilmente non dovrebbero essere molto complesse, poiché quel tipo di complessità sembra essere gestito meglio sul lato server.

Detto questo, ci sono alcuni client SOAP per javascript; So che jQuery ne ha uno. Pertanto, SOAP può essere sfruttato da JavaScript; semplicemente non come un servizio REST che restituisce stringhe JSON. Quindi, se avessi un servizio web che volevo essere abbastanza complesso da essere flessibile per un numero arbitrario di tecnologie e usi client, andrei con SOAP.

19
Travis Heseman

Ti consiglio di scegliere prima REST - se stai usando Java guarda JAX-RS e l'implementazione Jersey . REST è molto più semplice e facile da interagire in molte lingue.

Come altri hanno già detto in questo thread, il problema con SOAP è la sua complessità quando arrivano le altre specifiche WS- * e ci sono innumerevoli problemi di interoperabilità se ti allontani dalle parti sbagliate di WSDL, XSD, SOAP, WS-Addressing ecc.

Il modo migliore per giudicare il dibattito REST v SOAP è guardare su internet - praticamente tutti i grandi giocatori nello spazio web, google, Amazon, ebay, Twitter e altri utilizzare e preferire le API RESTful rispetto alle SOAP.

L'altro approccio di Nizza con REST è che puoi riutilizzare molto codice e infrastruttura tra un'applicazione web e un front-end REST. per esempio. il rendering di HTML rispetto a XML rispetto a JSON delle tue risorse è in genere abbastanza semplice con framework come JAX-RS e viste implicite - inoltre è facile lavorare con risorse RESTful utilizzando un browser Web

17
James Strachan

Sono sicuro che Don Box ha creato SOAP come uno scherzo - 'guardati può chiama i metodi RPC sul web' e oggi geme quando si rende conto di quale incubo gonfio di standard web è diventato :-)

REST è buono, semplice, implementato ovunque (quindi più uno "standard" rispetto agli standard) veloce e facile. Usa REST.

16
gbjbaanb

Penso che entrambi abbiano un loro posto. Secondo me:

SOAP: una scelta migliore per l'integrazione tra sistemi legacy/critici e un sistema web/web-service, sul livello base, dove WS- * ha senso (sicurezza, politica, ecc.).

RESTful: una scelta migliore per l'integrazione tra siti Web, con API pubblica, nella parte superiore del livello (VISUALIZZA, ovvero javascript che portano le chiamate agli URI).

15
irobson

Una cosa che non è stata menzionata è che una busta SOAP può contenere intestazioni e parti del corpo. Ciò consente di utilizzare la piena espressività di XML per inviare e ricevere informazioni fuori banda. REST, per quanto ne so, ti limita alle intestazioni HTTP e ai codici risultato.

(otoh, puoi usare i cookie con un servizio REST per inviare dati "header" di tipo fuori banda?)

13
John Saunders

Rispondere alla domanda aggiornata del 2012 (con la seconda ricompensa) e rivedere i risultati di oggi (altre risposte).


SAPONE, pro e contro

Informazioni su SOAP 1.2, vantaggi e svantaggi rispetto a "REST" ... Bene, dal 2007 è possibile descrivere REST servizi Web con WSDL e utilizzare SOAP protocol ... Cioè, se lavori un po 'di più, tutti gli standard W3C dello stack del protocollo dei servizi web possono essere REST !

È un buon punto di partenza, perché possiamo immaginare uno scenario in cui tutte le discussioni filosofiche e metodologiche sono temporaneamente evitate. Possiamo confrontare tecnicamente "RIPOSO SAPONE" con "RIPOSO NON SOAP" in servizi simili,

  • SOAP-REST (= "REST-SOAP"): come mostrato da L.Mandel , WSDL2 può descrivere un REST webservice e, se supponiamo che XML esemplificato possa essere racchiuso in SOAP, tutta l'implementazione sarà "SOAP-REST".

  • NON-SOAP-REST : qualsiasi servizio web REST che non può essere SOAP ... Cioè, "90%" di i ben noti REST esempi. Alcuni non usano XML (es. I tipici REST AJAX usano JSON invece), altri usano altre strutture XML, senza le intestazioni o le regole SOAP. PS: per evitare l'informalità, possiamo supporre REST livello 2 nei confronti.

Naturalmente, per confrontare più concettualmente, confronta "NON-REST-SOAP" con "NON-SOAP-REST", in quanto approcci di modellazione diversi. Quindi, completando questa tassonomia dei servizi Web:

  • NON-REST-SOAP : qualsiasi SOAP servizio web che non può essere REST ... Cioè, "90%" di i ben noti esempi SOAP.

  • NON-REST-NEITHER-SOAP : sì, l'universo della "modellazione dei servizi web" comprende altre cose (es. XML-RPC ).

SAPONE nelle condizioni REST

Confronto di cose comparabili: SOAP-REST con NON-SOAP-REST .

PROFESSIONISTI

Spiegando alcuni termini,

  • Stabilità contrattuale : per tutti i tipi di contratti (come "accordi scritti"),

    • Con l'uso degli standar : tutti i livelli dello stack W3C sono reciprocamente conformi. REST, d'altra parte, non è uno standard W3C o ISO e non ha dettagli normatizzati sulle periferiche di servizio. Quindi, come I , @DaveWoldrich (20 voti), @cynicalman (5), @Exitos (0) hanno detto prima, in un contesto in cui sono NECESSARI STANDARD, hai bisogno di SAPONE.

    • Con l'uso delle migliori pratiche : l '"aspetto dettagliato" delle implementazioni dello stack W3C , traduce i relativi accordi umani/legali/giuridici .

  • Robustezza : la sicurezza della struttura e delle intestazioni SOAP. Con metada communication (con la piena espressività di XML) e verifica hai una "polizza assicurativa" contro qualsiasi cambiamento o rumore.
    SOAP ha "affidabilità transazionale (...) per gestire gli errori di comunicazione. SOAP ha più controlli sulla logica dei tentativi e quindi può fornire più affidabilità end-to-end e garanzie di servizio", - E. Terman .

Ordinamento dei professionisti per popolarità,

  • Strumenti migliori (~ 70 voti): SOAP attualmente ha il vantaggio di strumenti migliori, dal 2007 e ancora dal 2012, perché è uno standard ben definito e ampiamente accettato. Vedi @MarkCidade (27 voti), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9).

  • Conformità standard (25 voti): as I , @DaveWoldrich (20 voti), @cynicalman (5), @Exitos (0) ha detto prima, in un contesto in cui sono NECESSARI STANDARD, è necessario il sapone.

  • Robustezza : assicurazione di intestazioni SOAP, @JohnSaunders (8 voti).

CONS

  • La struttura SOAP è più complessa (più di 300 voti): tutte le risposte qui, e le fonti su "SOAP vs REST", manifestano un certo disprezzo con SOAP ridondanza e complessità. Questa è una conseguenza naturale dei requisiti per verifica formale (vedi sotto) e per robustezza (vedi sopra). "REST NON-SOAP" (e XML-RPC, il SOAP originator ) può essere più semplice e informale.

  • La restrizione "solo XML" è un ostacolo alle prestazioni quando si utilizzano piccoli servizi (~ 50 voti): vedere json.org/xml = e questa domanda , oppure quest'altra . Questo punto è mostrato da @toluju (41) e altri.
    PS: as JSON non è uno standard IETF , ma possiamo considerare uno de facto standard per la comunità di software web.


Servizi di modellazione con SOAP

Ora, possiamo aggiungere SOAP-NON-REST con NON-SOAP-REST confronti e spiegare quando è meglio usare SOAP :

  • Necessità di standard e contratti stabili (vedere la sezione "PRO"). PS: vedi un tipico "bisogno B2B per gli standard" descritto da @saille .

  • Necessità di strumenti (vedere la sezione "PRO"). PS: standard e l'esistenza di verifiche formali (vedi sotto), sono questioni importanti per l'automazione degli strumenti.

  • Elaborazione parallela pesante (vedere la sezione "Contesto/Fondamenti" di seguito): con processi più grandi e/o più lenti, indipendentemente da una maggiore complessità di SAPONE, l'affidabilità e la stabilità sono le migliori investimenti.

  • Hai bisogno di più sicurezza : quando è richiesto più di HTTPS e hai davvero bisogno di funzionalità aggiuntive per la protezione, SOAP è una scelta migliore ( vedi @ Bell , 32 voti). "Invio del messaggio lungo un percorso più complicato della richiesta/risposta o su un trasporto che non comporta HTTP", S. Seely . XML è un problema fondamentale che offre standard per XML Encryption , XML Signature e XML Canonicalization e, solo con SOAP puoi incorporare questi meccanismi in un messaggio secondo uno standard ben accettato come WS-Security .

  • Hai bisogno di più flessibilità (meno restrizioni): SOAP non necessita di corrispondenza esatta con un URI; non limitato a HTTP; non è necessario limitare a 4 verbi. Come dice @TravisHeseman (9 voti), se volevi qualcosa di "flessibile per un numero arbitrario di tecnologie e usi client", usa SOAP.
    PS: ricorda che XML è più universale/espressivo di JSON (et al).

  • Necessità di verifiche formali: importante capire che stack W3C usa metodi formali e REST è più informale. La descrizione del servizio WSDL (a linguaggio formale ) è specifica formale delle interfacce dei servizi Web e SOAP è un protocollo affidabile che accetta tutti i possibili WSDL prescrizioni.

CONTESTO

Storico

Per valutare le tendenze è necessaria la prospettiva storica. Per questo argomento, una prospettiva di 10 o 15 anni ...

Prima della standardizzazione del W3C, ci sono alcune anarchie. È stato difficile implementare servizi interoperabili con diversi framework e più difficile, costoso e dispendioso in termini di tempo per implementare qualcosa di interoperabile tra le società. Gli standard W3C stack sono stati una luce, un nord per l'interoperabilità di insiemi di servizi web complessi.

Per le attività quotidiane, come implementare AJAX, SOAP è pesante ... Quindi, la necessità di approcci semplici deve eleggere un nuovo framework teorico ... E grandi "lettori di software Web" , poiché Google, Amazon, Yahoo e altri hanno eletto la migliore alternativa, ovvero l'approccio REST. È stato in questo contesto che il concetto di REST è arrivato come un "quadro concorrente" e, oggi (2012), questa alternativa è un di fatto standard per i programmatori.

Fondazioni

In un contesto di Parallel Computing i servizi Web forniscono attività secondarie parallele; e protocolli, come SOAP, garantiscono una buona sincronizzazione e comunicazione. Non "nessuna attività": i servizi Web possono essere classificati come
parallelismo a grana grossa e imbarazzante .

Man mano che l'attività diventa più grande, diventa meno "dibattito sulla complessità" e diventa più rilevante la solidità della comunicazione e la solidità dei contratti.

10
Peter Krauss

Non trascurare XML-RPC. Se stai cercando una soluzione leggera, c'è molto da dire su un protocollo che può essere definito in un paio di pagine di testo e implementato in una quantità minima di codice. XML-RPC è in circolazione da anni ma è passato di moda da un po 'di tempo - ma l'appeal minimalista sembra dargli una sorta di rinascita negli ultimi tempi.

10
Cruachan

È sfumato.

Se devi interfacciare altri sistemi con i tuoi servizi, molti clienti saranno più felici con SOAP, a causa dei livelli di "verifica" che hai con i contratti, WSDL e lo standard SOAP.

Per i sistemi di ogni giorno che chiamano sistemi, penso che SOAP sia un sovraccarico inutile quando una semplice chiamata HTML lo farà.

9
cynicalman

Sto guardando lo stesso, e penso, sono strumenti diversi per problemi diversi.

Lo standard SOAP (Simple Object Access Protocol), un linguaggio XML che definisce un'architettura di messaggio e i formati dei messaggi, viene utilizzato dai servizi Web e contiene una descrizione delle operazioni. WSDL è un linguaggio basato su XML per descrivere i servizi Web e come accedervi. verrà eseguito su SMTP, HTTP, FTP ecc. Richiede il supporto del middleware, un meccanismo ben definito per definire servizi come WSDL + XSD, WS-Policy SOAP restituirà dati basati su XML SOAP fornire standard per sicurezza e affidabilità

Servizi web di rappresentanza State Transfer (RESTful). sono servizi Web di seconda generazione. Servizi Web RESTful, comunicano via HTTP rispetto ai servizi basati su SOAP e non richiedono messaggi XML o definizioni API del servizio WSDL. per REST non è richiesto alcun middleware è necessario solo il supporto HTTP.WADL Standard, REST può restituire XML, testo normale, JSON, HTML ecc

Per molti tipi di client è più semplice utilizzare i servizi Web RESTful, consentendo al lato server di evolversi e ridimensionarsi. I clienti possono scegliere di consumare alcuni o tutti gli aspetti del servizio e combinarli con altri servizi basati sul web.

  1. REST utilizza HTTP standard, quindi sta semplicemente creando client, sviluppando API
  2. REST consente molti formati di dati diversi come XML, testo normale, JSON, HTML dove SOAP consente solo XML.
  3. REST ha prestazioni e scalabilità migliori.
  4. Riposa e può essere memorizzato nella cache e SOAP non può
  5. Gestione degli errori integrata in cui SOAP non ha alcuna gestione degli errori
  6. REST è particolarmente utile PDA e altri dispositivi mobili.

REST è che i servizi sono facili da integrare con i siti Web esistenti.

SOAP ha una serie di protocolli, che forniscono standard di sicurezza e affidabilità, tra le altre cose, e interagiscono con altri client e server WS conformi. SOAP I servizi Web (come JAX-WS) sono utili nella gestione dell'elaborazione e della chiamata asincrone.

Per le API complesse SOAP sarà più utile.

9
kapil das

REST è un'architettura inventata da Roy Fielding e descritta nella sua tesi Architectural Styles and the Design of Network-based Software Architectures . Roy è anche l'autore principale di HTTP - il protocollo che definisce il trasferimento di documenti sul World Wide Web. HTTP è un protocollo RESTful. Quando gli sviluppatori parlano di "utilizzo di REST servizi Web", è probabilmente più preciso dire "utilizzo di HTTP".

SOAP è un protocollo basato su XML che esegue il tunneling all'interno di una richiesta/risposta HTTP, quindi anche se si utilizza SOAP, si utilizza anche REST. Si discute se SOAP aggiunge funzionalità significative all'HTTP di base.

Prima di creare un servizio Web, consiglierei di studiare HTTP. Le probabilità sono le tue esigenze possono essere implementate con funzionalità già definite nelle specifiche, quindi non saranno necessari altri protocolli.

8
Chris Broski

Sto osservando lo stesso problema. Mi sembra che in realtà REST sia veloce, facile e buono per chiamate e risposte leggere e ottimo per il debug (cosa potrebbe esserci di meglio che pompare un URL in un browser e vedere la risposta).

Tuttavia, dove REST sembra cadere, ha a che fare con il fatto che non è uno standard (sebbene sia composto da standard). La maggior parte delle librerie di programmazione ha un modo di ispezionare un WSDL per generare automaticamente il codice client necessario per utilizzare i servizi basati su SOAP. Finora consumare servizi web basati su REST sembra un approccio più ad hoc per scrivere un'interfaccia per abbinare le chiamate possibili. Effettuare una richiesta http manuale quindi analizzare la risposta. Questo di per sé può essere pericoloso.

La bellezza di SOAP è che una volta emesso un WSDL, il business 'può strutturare la loro logica aorund che stabilisce un contratto qualsiasi modifica all'interfaccia cambierà il wsdl. Non c'è spazio per la manovra. È possibile convalidare tutte le richieste rispetto a quel WSDL. Tuttavia, poiché un WSDL non descrive correttamente un servizio REST, non esiste un modo definito per concordare l'interfaccia per la comunicazione.

Dal punto di vista commerciale, ciò sembra lasciare la comunicazione aperta all'interpretazione e al cambiamento, che sembra una cattiva idea.

La prima "risposta" in questo thread sembra dire che SOAP sta per Simple Access-oriented Access Protocol, tuttavia guardando wiki O significa Object non Object-oriented. Sono cose diverse.

So che questo post è molto vecchio ma ho pensato che avrei dovuto rispondere con i miei risultati.

7
Exitos

È una buona domanda ... Non voglio perderti, quindi sono aperto alle risposte degli altri tanto quanto te. Per me, si riduce davvero al costo del sovraccarico e a cosa serve l'API. Preferisco consumare servizi Web durante la creazione di software client, tuttavia non mi piace il peso di SOAP. REST, credo, è più leggero, ma non mi piace lavorare con esso dal punto di vista del cliente.

Sono curioso di sapere cosa pensano gli altri.

6
cranley

Ascolta questo podcast per scoprirlo. Se vuoi conoscere la risposta senza ascoltare, allora OK, il suo RESTO. Ma raccomando davvero di ascoltare.

6
Mark Beckwith

La mia regola generale è che se si desidera che un client Web del browser si connetta direttamente a un servizio, è consigliabile utilizzare REST. Se si desidera trasferire dati strutturati tra i servizi di back-end, utilizzare SOAP.

SOAP può essere una vera seccatura da configurare a volte ed è spesso eccessivo per semplici scambi di dati tra client Web e server. Sfortunatamente, i più semplici esempi di programmazione che ho visto (e imparato da) rafforzano in qualche modo questa percezione.

Detto questo, SOAP brilla davvero quando inizi a combinare più servizi SOAP come parte di un processo più ampio guidato da un flusso di lavoro di dati (pensa al software aziendale). Questo è qualcosa che molti degli esempi di programmazione SOAP non riescono a trasmettere perché una semplice operazione SOAP per fare qualcosa, come recuperare il prezzo di un titolo, è generalmente complicata da ciò che fa stesso, a meno che non sia presentato nel contesto della fornitura di un'API leggibile da una macchina che descriva in dettaglio funzioni specifiche con formati di dati impostati per input e output che, a loro volta, sono scritti da un processo più ampio.

Questo è triste, in un certo senso, in quanto dà a SOAP una cattiva reputazione perché è difficile mostrare i vantaggi di SOAP senza presentarlo nel contesto completo di come il prodotto finale viene usato.

6
Rick Sarvas

In senso con "PHP-universe" PHP il supporto per qualsiasi SOAP avanzato fa schifo alla grande. Finirai per usare qualcosa come http://wso2.com/products/web-services-framework/php/ non appena attraversi i bisogni di base, anche per abilitare WS-Security o WS- RM senza supporto integrato.

Penso che la creazione di buste SOAP sia molto disordinata in PHP, il modo in cui crea spazi dei nomi, xsd: nil, xsd: anytype e servizi in stile antico che usano la codifica SOAP (Dio sa come è diverso) con in SOAP messaggi.

Evita tutto questo casino attenendoti a REST, REST non è niente di veramente grande che lo stiamo usando dall'inizio del WWW. Ci siamo resi conto solo quando questo http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm è uscito il documento che mostra come possiamo usare le funzionalità HTTP per implementare i servizi RESTFul. HTTP è intrinsecamente REST, ciò non significa che il solo utilizzo di HTTP ritorni i tuoi servizi.

SOAP trascura le funzionalità principali di HTTP e considera HTTP solo come un protocollo di trasporto, quindi in teoria è un protocollo di trasporto indipendente (in pratica non è il caso di aver sentito parlare di SOAP header di azione? Se non cercarlo su Google ora!) .

Con l'adattamento di JSON in aumento e HTML5 con javascript che matura REST con JSON è diventato il modo più comune di gestire i servizi. È stato anche definito lo schema JSON che può essere utilizzato per soluzioni di livello aziendale (ancora nelle fasi iniziali) insieme a WADL, se necessario.

Il supporto PHP per REST e JSON è decisamente migliore del supporto integrato SOAP esistente.

Aggiungendo qualche altra parola BUZZ qui SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

dal modo in cui amo SOAP specialmente per le specifiche WS-Security, questa è una buona specifica e se qualcuno che pensa all'adattamento Enterprise JSON deve sicuramente venire con qualcosa di simile per JSON, come la crittografia a livello di campo ecc.

4
shivaspk

SOAP incarna un approccio orientato al servizio ai servizi Web - uno in cui i metodi (o verbi) sono il modo principale di interagire con il servizio. REST adotta un approccio orientato alle risorse in cui l'oggetto (o il nome) è al centro della scena.

4

Un punto rapido: protocollo di trasmissione e orchestrazione;

Uso SOAP su TCP per motivi di velocità, affidabilità e sicurezza, inclusi i servizi orchestrati machine to machine (ESB) e servizi esterni. Modificare la definizione del servizio, l'orchestrazione genera un errore dalla modifica WSDL ed è immediatamente evidente e può essere ricostruito/distribuito.

Non sono sicuro che puoi fare lo stesso con REST - aspetto di essere corretto o ovviamente! Con REST, modifica la definizione del servizio: nulla lo sa fino a quando non ne restituisce 400 (o qualsiasi altra cosa).

3
BlueChippy

Se stai cercando l'interoperabilità tra diversi sistemi e lingue, sceglierei sicuramente REST. Ho avuto molti problemi nel tentativo di far funzionare SOAP tra .NET e Java, ad esempio.

2
neu242

creo un punto di riferimento per scoprire quali sono più veloci! vedo questo risultato:

per 1000 richieste:

  • REST ha impiegato 3 secondi
  • Il sapone ha impiegato 7 secondi

per 10.000 richieste:

  • REST ha impiegato 33 secondi
  • Il sapone ha impiegato 69 secondi

per 1.000.000 di richieste:

  • REST ha impiegato 62 secondi
  • Il sapone ha impiegato 114 secondi
2
Sonador

Una vecchia domanda, ma ancora rilevante oggi .... a causa di così tanti sviluppatori nello spazio aziendale che ancora lo usano.

Il mio lavoro prevede la progettazione e lo sviluppo di soluzioni IoT (Internet of Things). Il che include lo sviluppo di codice per piccoli dispositivi integrati che comunicano con il cloud.

È chiaro che REST è ora ampiamente accettato e utile e praticamente lo standard defacto per il Web, anche Microsoft ha REST supporto incluso in Azure. Se avessi bisogno di affidarmi a SOAP non avrei potuto fare quello che dovevo fare, perché è troppo grande, ingombrante e fastidioso per i piccoli dispositivi integrati.

REST è semplice, pulito e piccolo. Rendendolo ideale per piccoli dispositivi integrati. Grido sempre quando lavoro con uno sviluppatore web che mi invia un WSDL. Dal momento che dovrò iniziare una campagna educativa sul perché questo non funzionerà e perché dovranno imparare il RESTO.

0
Remixed123

1.Dalla mia esperienza. Direi che REST ti dà la possibilità di accedere all'URL che è già stato creato. ad es.> una ricerca di parole in google. Tale URL potrebbe essere utilizzato come servizio Web per REST. In SOAP, è possibile creare il proprio servizio Web e accedervi tramite il client SOAP.

  1. REST supporta testo, JSON, formato XML. Quindi più versatile per la comunicazione tra due applicazioni. Mentre SOAP supporta solo il formato XML per la comunicazione dei messaggi.
0
Shalini Baranwal