Per cosa è stato inventato SOAP?

REST non è uno standard, è un'architettura (non definita). Ed è legato a HTTP, che molte persone nel mondo aziendale hanno visto come una limitazione. Quindi pensavano di aver bisogno di uno standard generale appropriato, che funzionasse anche su altri livelli di trasferimento.

E btw SOAP è stato definito prima di REST (almeno secondo Wikipedia: -)

Non ero nella stanza, ma in genere direi che SOAP è stata un'idea molto, molto buona e una risposta molto ragionevole alle altre opzioni RPC che esistevano tra la metà e la fine degli anni '90. Ad esempio CORBA , una bestia che non posso dire di aver dovuto affrontare personalmente, ma la semplice menzione di che può fare in modo che gli uomini adulti si sporcano. Le opzioni oltre CORBA erano in realtà più spaventose in molti casi e c'era poca standardizzazione e molti protocolli di messaggistica personalizzati in corso. I sistemi integrati erano roba molto, molto difficile. C'erano buoni motivi per non fare affidamento su HTTP come trasporto. Alla fine degli anni '90, le velocità tipiche della LAN erano di 10 megabit o meno, le velocità WAN venivano spesso misurate in baud. L'intera infrastruttura di caching del bordo che fa così tanto per REST non esisteva.

Che ci porta a SAPONE - che di per sé non specifica un mezzo di trasporto. Credo che qualcuno sia riuscito a implementare una chiamata SOAP su piccione viaggiatore. O forse una rondine africana. In ogni caso, è molto più semplice implementare l'opzione di messaggistica rispetto a quanto accaduto prima. E se avessi un decente kit di strumenti SOAP, è stato molto, molto più facile da consumare rispetto a qualsiasi altra cosa fosse arrivata prima. E più facile creare strumenti per. Così facile che pensavano di aver bisogno di estendere il protocollo. Ed è qui che entra in gioco WS-*. È qui che le ruote sono cadute da quel camion. . .

SOAP è molto più adatto di un semplice HTTP per lo scambio di strutture di dati complesse. REST è di design praticamente limitato alle operazioni CRUD, mentre SOAP consente chiamate di metodi arbitrari, che possono essere qualcosa che non può essere premuto nello schema REST.

Da Wikipedia :

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. ... SOAP has three major characteristics: Extensibility (security and WS-routing are among the extensions under development), Neutrality (SOAP can be used over any transport protocol such as HTTP, SMTP or even TCP), and Independence (SOAP allows for any programming model).

SOAP non è limitato a HTTP e offre sicurezza immediata.

Se stai usando HTTP e non hai bisogno di sicurezza (il tuo servizio web è aperto al pubblico), allora non hai bisogno di SOAP.

SOAP è un protocollo di messaggistica, creato per lo stesso motivo per cui è stato creato un altro protocollo di messaggistica; standardizzare il modo in cui le informazioni sugli oggetti vengono passate in giro. Come afferma la pagina Wikipedia , è originata da Microsoft e ora è uno standard aperto gestito dal W3C.

La migliore domanda è: perché scegliere tra SOAP o uno schema a base XML o JSON o qualsiasi altra cosa, e la risposta viene giù per usare qualsiasi cosa sia la più semplice / pratica nella tua particolare situazione.

Secondo me SOAP è un altro take a RPC . Dai un'occhiata a come esporti WebService in questi giorni. Una parte contrassegna il metodo come WebService e l'altro recupera solo WSDL e utilizza metodi remoti come se fossero locali. Sono abbastanza consapevole di tutti i problemi SOAP, ma su un qualche livello di astrazione SOAP / WS offre la sua promessa RPC. Naturalmente è possibile creare un'API basata sull'architettura REST, ma sarà comunque necessario che un'altra parte codifichi alcuni bit che in qualche modo sfidano la definizione RPC.