REST è un approccio migliore ai servizi Web o SOAP? O sono strumenti diversi per problemi diversi? O è una questione sfumata - vale a dire, è leggermente migliore in alcune arene di un altro, ecc.?

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

Ho creato uno dei primi server SOAP, 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 anche con 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à.

REST è un'architettura, SOAP è un protocollo.

Questo è il primo problema.

È possibile inviare buste SOAP in un'applicazione REST.

Il SOAP stesso è in realtà piuttosto semplice e di base, 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.

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 sui "nomi" e limitando il numero di "verbi" che puoi applicare a quei nomi. Gli unici verbi ammessi sono "get", "put", "post" ed "delete". Ciò differisce dal SOAP in cui molti verbi diversi possono essere applicati a molti nomi diversi (cioè molte funzioni diverse).

Per REST, i quattro verbi si associano alle corrispondenti richieste HTTP, 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'API più complessa che comunica 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.

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 è davvero 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 apolidi.  Se un'operazione deve essere continuata, REST non è l'approccio migliore e SOAP potrebbe adattarsi meglio. Tuttavia, se hai bisogno di operazioni CRUD senza stato (Crea, Leggi, Aggiorna ed Elimina), è REST.

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

Quindi perché dovrei anche prendere in considerazione SOAP? Ancora una volta, SOAP è abbastanza maturo e ben definito e viene fornito con una specifica completa. L'approccio REST è proprio questo, un approccio ed è ampiamente aperto allo sviluppo, quindi se si dispone di quanto segue, SOAP è un'ottima soluzione:

• Elaborazione e invocazione asincroni.  Se l'applicazione richiede un livello garantito di affidabilità e sicurezza, SOAP 1.2 offre standard aggiuntivi per garantire questo tipo di operazione. 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, SOAP 1.2 ha le specifiche aggiuntive nella struttura WS * per supportare tali aspetti (sicurezza, transazioni, coordinamento, ecc.). Comparativamente, l'approccio REST avrebbe costretto gli sviluppatori a costruire questo impianto idraulico personalizzato.

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

SOAP ha attualmente il vantaggio di strumenti migliori in cui genereranno molto codice di boilerplate 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 costruire servizi REST, come Ruby on Rails, e alcuni ti aiutano persino a scrivere client, come ADO.NET Data Services. Ma per la maggior parte manca il supporto degli strumenti.

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 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 ho bisogno di servire AJAX su browser web, o ho bisogno di fare lo streaming, o le mie risposte sono gigantesche, vado a 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.

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 rispetto all'implementazione di un servizio SOAP. E alla fine esce anche molto più disordinato. Ecco i motivi per cui sceglierei SOAP il 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 è fatta a mano e - ottieni - leggendo la documentazione. Inoltre, durante l'implementazione di questi due servizi, è necessario 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 restituisce comunque XML? L'unica differenza è che con REST non conosci i tipi che ogni elemento / attributo rappresenta - sei da solo per implementarlo e speri che un giorno non si verifichi una stringa in un campo che pensavi fosse 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" della busta SOAP. 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?

La maggior parte delle applicazioni che scrivo sono C # lato server o Java o applicazioni desktop in WinForms o WPF. Queste applicazioni tendono a richiedere 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.

Ti consiglierei di andare prima con REST - se stai usando Java guarda JAX-RS e l' implementazione di 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 ci si allontana da parti sbagliate di WSDL, XSD, SOAP, WS-Addressing ecc.

Il modo migliore per giudicare il dibattito REST / SOAP è guardare su internet - praticamente tutti i grandi attori dello spazio web, google, amazon, ebay, twitter e altri - tendono ad usare e preferire le API RESTful rispetto a quelle SOAP.

L'altro buon approccio con REST è che puoi riutilizzare un sacco di codice e infrastruttura tra un'applicazione web e un front-end REST. ad esempio, il rendering di HTML rispetto a XML rispetto a JSON delle tue risorse è normalmente abbastanza semplice con framework come JAX-RS e viste implicite, oltre a essere facile da lavorare con risorse RESTful utilizzando un browser Web

Sono sicuro che Don Box abbia creato SOAP come uno scherzo - 'guarda puoi chiamare i metodi RPC sul web' e oggi geme quando si rende conto di che incubo gonfio di standard web è diventato :-)

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

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, in cui WS- * ha senso (sicurezza, politica, ecc.).

RESTful : una scelta migliore per l'integrazione tra siti Web, con API pubbliche, nella parte superiore del layer (VIEW, ovvero javascripts che effettuano chiamate agli URI).

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?)

Non trascurare XML-RPC. Se stai semplicemente 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.

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 i servizi Web REST con WSDL e utilizzare il protocollo SOAP ... Cioè, se si lavora un po 'di più, tutti gli standard W3C di lo stack del protocollo dei servizi Web può 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 servizio web REST e, se supponiamo che XML esemplificato possa essere avvolto in SOAP, tutta l'implementazione sarà "SOAP-REST" .

• NON-SOAP-REST : qualsiasi servizio web REST che non può essere SOAP ... Cioè, "90%" degli esempi REST noti. Alcuni non usano XML (ad esempio 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 il livello REST 2 nei confronti.

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

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

• 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 di standar : tutti i livelli dello stack W3C sono reciprocamente conformi. REST, d'altra parte, non è uno standard W3C o ISO e non ha dettagli normati sulle periferiche di servizio. Così, come ho detto prima @DaveWoldrich (20 voti), @cynicalman (5), @Exitos (0), in un contesto in cui sono NECESSARIE NORME, è necessario il SAPONE.

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

• Robustezza : la sicurezza della struttura e delle testate SOAP. Con la comunicazione metada (con la piena espressività di XML) e la verifica hai una "polizza assicurativa" contro qualsiasi cambiamento o rumore.
  SOAP ha "l'affidabilità transazionale (...) che si occupa degli 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à di Standars (25 voti): come ho detto prima, @DaveWoldrich (20 voti), @cynicalman (5), @Exitos (0), in un contesto in cui sono NECESSARI STANDARD, hai bisogno di SAPONE.

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

CONS

• La struttura SOAP è più complessa (oltre 300 voti): tutte le risposte qui, e le fonti su "SOAP vs REST", manifestano un certo disprezzo per la ridondanza e la complessità di SOAP. Questa è una conseguenza naturale dei requisiti per la verifica formale (vedi sotto) e per la solidità (vedi sopra). "REST NON-SOAP" (e XML-RPC, il creatore di SOAP ) 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 , o quest'altra . Questo punto è mostrato da @toluju (41) e altri.
  PS: poiché JSON non è uno standard IETF , ma possiamo considerare uno standard di fatto per la comunità del software web.

Servizi di modellazione con SOAP

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

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

• Necessità di strumenti (vedere la sezione "PRO"). PS: gli 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 un po 'più di complessità di SOAP, affidabilità e stabilità sono gli investimenti migliori.

• 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 coinvolge HTTP", S. Seely . XML è un problema fondamentale, che offre standard per la crittografia XML , la firma XML e la Canonicalizzazione XML e, solo con SOAP, è possibile incorporare questi meccanismi in un messaggio secondo uno standard ben accettato come WS-Security .

• Hai bisogno di maggiore 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 lo stack W3C utilizza metodi formali e REST è più informale. La descrizione del servizio WSDL (un linguaggio formale ) è una specifica formale delle interfacce dei servizi Web e SOAP è un protocollo affidabile che accetta tutte le possibili prescrizioni WSDL.

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 dello stack del W3C 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", come Google, Amazon, Yahoo e altri hanno eletto la migliore alternativa, ovvero l'approccio REST. È stato in questo contesto che il concetto REST è arrivato come un "quadro concorrente" e, oggi (2012), questa alternativa è di fatto uno 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 "nessun compito": 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.

È sfumato.

Se hai bisogno di avere altri sistemi di interfaccia 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à.

Sto guardando lo stesso, e penso che siano 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 che fornisce standard di 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. Standard WADL, 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 semplice, JSON, HTML dove SOAP consente solo XML.
3. REST ha prestazioni e scalabilità migliori.
4. Riposa e può essere memorizzato nella cache e SOAP no
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, tra le altre cose, standard di sicurezza e affidabilità e interagiscono con altri client e server WS conformi. I servizi Web SOAP (come JAX-WS) sono utili nella gestione dell'elaborazione e dell'invocazione asincrone.

Per SOAP API complesse sarà più utile.

REST è un'architettura inventata da Roy Fielding e descritta nella sua tesi di laurea Architectural Styles e nella progettazione di architetture software basate su rete . 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 dei servizi Web REST", è probabilmente più preciso dire "utilizzo 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 aggiunga 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.

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 consumare un servizio basato su SOAP. Finora i servizi web basati su REST che consumano sembrano 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.

Il bello di SOAP è che, una volta emesso un WSDL, le imprese possono strutturare la loro logica aorund che imposta il contratto e qualsiasi modifica all'interfaccia cambierà il wsdl. Non c'è spazio per la manovra. Puoi 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.

È una buona domanda ... Non voglio guidarti fuori strada, 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.

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

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 insieme 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 troppo complicata per quello che fa da sola a meno che non sia presentata nel contesto della fornitura di una macchina API leggibili che descrivono in dettaglio funzioni specifiche con formati di dati impostati per input e output, a loro volta copiati 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 dell'utilizzo del prodotto finale.

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.

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

Credo 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 i messaggi SOAP.

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 è uscito questo documento http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm che mostra come possiamo usare le funzionalità HTTP per implementare i servizi RESTFul. HTTP è intrinsecamente REST, ciò non significa che l'utilizzo di HTTP rende i tuoi servizi RESTFul.

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 che tu abbia sentito parlare dell'intestazione dell'azione SOAP? Se non cercalo 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 SOAP integrato 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 adoro SOAP soprattutto 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.

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 tu possa fare lo stesso con REST - aspetto che sia corretto o ovviamente! Con REST, modifica la definizione del servizio: nulla lo sa fino a quando non ne restituisce 400 (o qualsiasi altra cosa).

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, per esempio.

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

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 il supporto REST incluso in Azure. Se avessi bisogno di fare affidamento su 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.

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

2. 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.