SOAP - Qual è il punto?

Question

Voglio dire, davvero, qual è il punto di SOAP?

I servizi Web sono in circolazione da un po 'di tempo e per un certo periodo è sembrato che i termini "SOAP" e "servizio Web" fossero in gran parte intercambiabili. Tuttavia, SOAP mi è sempre sembrato ingombrante e massicciamente complicato.

Poi è arrivato REST e improvvisamente i servizi web hanno avuto un senso.

Come dice Joel Spolsky, assegnare a un programmatore un URL REST e possono iniziare subito a giocare con il servizio, calcolandolo.

SOAP è offuscato dietro WSDL e XML in modo massicciamente dettagliato e, nonostante sia basato sul Web, non è possibile eseguire operazioni semplici come accedere a un servizio SOAP con un browser Web.

Così l'essenza della mia domanda è:

• Ci sono buoni motivi per scegliere mai SOAP su REST?
• Stai lavorando con SOAP ora? Sarebbe meglio se l'interfaccia fosse REST?
• Mi sbaglio?

Answer 1

Bene ora sembra che il WSI accetti che SOAP non ha più un punto in quanto hanno annunciato che cesseranno di esistere come entità indipendente.

Interessante articolo circa l'annuncio e qualche commento qui: http://blogs.computerworlduk.com/simon-says/2010/11/the-end-of-the-road-for-web-services/index.htm

editati per essere completamente accurata in risposta a John Saunders.

Answer 2

L'argomento è ben discusso in Why is soap considered to be thick.

Answer 3

Il punto di WSDL era il rilevamento automatico. L'idea era che non avresti dovuto scrivere codice client, sarebbe stato generato automaticamente.

BTW. il prossimo passaggio oltre WSDL è Semantic Web Services.

Answer 4

Per come la vedo io, SOAP potrebbe essere più "flessibile", ma come risultato è troppo complicato (hai menzionato il WSDL, che è sempre un ostacolo per me personalmente).

I get REST. È semplice. L'unico lato negativo che potrei vedere è che ti stai limitando a quelle 4 azioni di base contro una singola risorsa, il che potrebbe non corrispondere esattamente al modo in cui visualizzi i tuoi dati.

Answer 5

Mi sbaglio?

"Non sbagli, Walter, sei solo ... :)"

Ci sono buoni motivi per scegliere mai SOAP su REST?

SOAP, a mia conoscenza aderisce a un contratto, quindi può essere controllato tipo.

Answer 6

Come dice Joel Spolsky, assegnare a un programmatore un URL REST e possono iniziare subito a giocare con il servizio, calcolandolo.

Considerando che se il servizio aveva un contratto ben leggibile, leggibile dal computer, il programmatore non avrebbe dovuto perdere tempo a capirlo.

(non che WSDL/SOAP è necessariamente un esempio di buona esecuzione di un contratto ben specificato, ma che era il punto di WSDL)

In origine, SOAP è un semplice protocollo che ha permesso di aggiungere un'intestazione a un messaggio e una mappatura standardizzata delle istanze di oggetti alle strutture XML. Mettere i metadati di gestione nel messaggio ha semplificato il codice client e significava che si potevano semplicemente persistere e accodare i messaggi.

Non ho mai avuto bisogno dei dettagli dell'elaborazione dell'intestazione quando ho creato i servizi SOAP nel 2001. Era pre-WSDL, quindi era normale utilizzare GET per ottenere informazioni e query (non è diverso dalla maggior parte delle applicazioni che affermano di essere REST ; REST ha di più in termini di utilizzo dei collegamenti ipertestuali per l'individuazione dei servizi) e POST con un payload SOAP per eseguire azioni. Quelle azioni che hanno creato risorse restituirebbero l'URL della risorsa creata al client e il client potrebbe quindi ottenere la risorsa. Penso che sia il fatto che WSDL ha reso facile pensare solo in termini di RPC piuttosto che di azioni che creano risorse che hanno fatto perdere a SOAP la trama.

Answer 7

Se non avete bisogno le caratteristiche della WS- * serie di protocolli; se non hai bisogno di servizi di auto-descrizione; se il tuo servizio non può essere completamente descritto come risorse, come definito dal protocollo HTTP; se non ti piace dover scrivere XML per ogni interazione con il servizio, e analizzarlo successivamente; allora hai bisogno di SAPONE.

In caso contrario, utilizzare REST.

---

C'è stata qualche domanda sul valore di un servizio auto-descrittivo. La mia immaginazione mi tradisce quando si tratta di immaginare come qualcuno potrebbe non riuscire a capirlo. Questo è su di me. Tuttavia, devo pensare che chiunque abbia mai usato un servizio molto più complicato di "Hello, world" saprebbe perché è utile che qualcun altro scriva il codice che accetta i parametri, crea l'XML da inviare al servizio, invia riceve la risposta, quindi la restituisce agli oggetti.

Ora, suppongo che questo potrebbe non essere necessario quando si utilizza un servizio RESTful; almeno non con un servizio RESTful che non elabora oggetti complessi. Anche con un servizio relativamente semplice come http://www.earthtools.org/webservices.htm (che ho utilizzato come esempio di chiamata a un servizio RESTful), uno trae vantaggio dalla comprensione della struttura dei dati restituiti. Anche il servizio di cui sopra fornisce uno schema XML - sfortunatamente non descrive l'intera risposta. Dato che lo schema deve ancora elaborare manualmente l'XML, oppure utilizzare uno strumento per produrre classi serializzabili dallo schema.

Tutto questo accade quando il servizio è descritto in un WSDL e si utilizza uno strumento come "Aggiungi riferimento servizio" in Visual Studio o il programma svcutil.exe oppure I-forget-what-the- comando-is-a-Eclipse.

Se volete esempi, iniziare con le EarthTools servizi, e andare a qualsiasi altro servizio di messaggistica con più complicato.

BTW, un'altra cosa che richiede auto-descrizione è la descrizione dei modelli di messaggistica e protocolli supportati dal servizio. Forse questo non è richiesto quando le uniche scelte sono i verbi HTTP su HTTP o HTTPS. La vita diventa più complicata se usi WS-Security e gli amici.

Answer 8

Pur facendo qualche ricerca per capire alcune delle risposte qui (in particolare John Saunders') ho trovato questo post http://harmful.cat-v.org/software/xml/soap/simple SOAP è più folle di quanto pensassi ...

Answer 9

Penso agli appelli SOAP al Java e.folla netta che potrebbe essere più familiare con il vecchio CORBA e COM e meno familiarità con le tecnologie Internet.

REST ha anche uno dei principali inconvenienti: non vi sono molte indicazioni su come implementare effettivamente un tale sistema. Troverai variazioni significative sul numero di API RESTful pubbliche che sono state progettate. In effetti molti violano aspetti chiave di REST (come l'utilizzo di GET per la manipolazione o POST per il recupero) e vi sono disaccordi sull'uso fondamentale (POST/GET vs POST/GET/PUT/DELETE).

Answer 10

Trovo che il SOAP si adatti in modo appropriato quando c'è un'alta probabilità che un servizio venga consumato dal software COTS (corporate off the shelf). A causa del contratto ben specificato impiegato da SOAP/WSDL, la maggior parte dei pacchetti COTS ha funzionalità incorporate per il consumo di tali servizi. Ciò può rendere più semplice per BPM/strumenti di workflow ecc. Semplicemente consumare servizi definiti senza personalizzazione. Oltre questo caso di utilizzo del servizio, REST tende ad essere la mia implementazione del servizio web goto per le applicazioni.

Answer 11

SOAP è una specifica di protocollo strutturato basata su XML leggera da utilizzare nell'implementazione dei servizi. È utilizzato per lo scambio di informazioni strutturate in un ambiente decentralizzato e distribuito. SOAP utilizza tecnologie XML per lo scambio di informazioni su qualsiasi protocollo di livello di trasporto. È indipendente da un particolare modello di programmazione e da altre semantiche specifiche dell'implementazione. Ulteriori informazioni su XML SOAP Messaging Framework

Framework di messaggistica XML che è 1) Estensibile: la semplicità rimane uno degli obiettivi principali di progettazione di SOAP. SOAP definisce un framework di comunicazione che consente di aggiungere funzionalità come sicurezza, instradamento e affidabilità in seguito come estensioni a più livelli

2) Interoperabile: SOAP può essere utilizzato su qualsiasi protocollo di trasporto come TCP, HTTP, SMTP. Oggi SOAP fornisce un binding esplicito per HTTP.

3) Indipendente: SOAP consente qualsiasi modello di programmazione e non è legato alla chiamata di procedura remota (RPC). SOAP definisce un modello per l'elaborazione di singoli messaggi unidirezionali. SOAP consente anche un numero qualsiasi di modelli di scambio di messaggi (MEP). Ulteriori informazioni su SOAP