2011-09-22 1 views
8

Disclaimer: Sono davvero confuso tra servizi basati su REST e SOAP.
Dopo aver letto molte esercitazioni (che sembrano contraddittorie tra loro) sul servizio web basato su REST, mi chiedevo se possiamo/dovremmo usare SOAP per inviare/ricevere messaggi nel servizio web basato su REST?
Ho provato seguenti link
1) http://www.ibm.com/developerworks/webservices/library/ws-restful/Messaggi SOAP in servizio web basato su REST

2) http://rest.elkstein.org/2008/02/how-simple-is-rest.html

risposta

16

per "servizi SOAP based" suppongo che voi siate che significa WS-I Basic Profile servizi web. La distinzione è importante perché SOAP può essere utilizzato con REST e con i servizi Web BP WS-I. Lasciatemi spiegare.

SOAP è un formato di messaggistica basato su XML per lo scambio di dati. Soap definisce anche un mezzo per effettuare chiamate a procedure remote. SOAP è uno standard aperto dal W3C. SOAP è agnostico sullo strato di trasporto sottostante. Spesso HTTP viene utilizzato come livello di trasporto, ma può tranquillamente funzionare su SMTP e TCP e anche su altri trasporti.

REST è uno stile architettonico (non uno standard), quindi fare attenzione a non confrontare REST e SOAP direttamente perché non si confrontano le mele con le mele. REST prende HTTP e usa è il modo in cui è stato pensato per essere utilizzato, con tutte le sue sottigliezze e la ricchezza. Lo stile architettonico REST può essere utilizzato per trasferire dati in qualsiasi formato, non impone alcun formato di dati particolare. Quindi SOAP è un formato di serializzazione perfettamente valido per un servizio Web in stile REST. Ma molte persone usano JSON, XML, testo semplice e molti altri formati con REST. Puoi anche scambiare felicemente dati binari su REST, come i file di immagine. La cosa bella è che devi scegliere il formato dati che ha più senso per la tua applicazione.

Si noti che dal momento che REST è un modello, non uno standard, vi è un sacco di dibattito su cosa significhi essere veramente RESTful. Esiste un concetto chiamato Richardson Maturity Model che espone una serie di passi verso l'ideale REST. Confrontando con il modello di Richardson possiamo vedere esattamente come RESTful è una particolare implementazione REST. I servizi Web WS-I BP sono al livello 0 su questa scala (cioè non molto RESTful a tutti, solo usando HTTP come un livello di trasporto stupido).

Direi questo sulla scelta dei servizi web REST vs WS-I Basic Profile - dipende dal pubblico. Se si sta sviluppando un'interfaccia di tipo B2B all'interno di un'azienda, è più comune vedere i servizi Web WSI-BP. Poiché esiste uno standard sottostante e grazie al supporto maturo dei fornitori di aziende (come IBM, Oracle, SAP, Microsoft) e a causa del livello di supporto del framework, in particolare in .NET e Java, WSI-BP ha molto senso quando è necessario ottenere qualcosa in modo rapido e si desidera semplificare la connessione dei client in un ambiente aziendale e i dati scambiati sono dati aziendali ben serializzati come SOAP.

D'altro canto, se si espongono servizi Web a un pubblico più vasto, direi che c'è stata una tendenza da WSI-BP e verso lo stile RESTful. Poiché REST presuppone solo che il client supporti HTTP, è possibile interoperare con il pubblico più ampio possibile. REST ti offre anche la scalabilità del Web stesso, con il supporto per il caching di risorse ecc. Che lo rende in grado di scalare su un vasto pubblico molto meglio dei servizi web WSI-BP.

+1

Che risposta deliziosamente sana. –

+0

In effetti, ottima risposta. –

+0

@saille: Grazie amico. Ora le cose sembrano essere più facili. – xyz