it-swarm.it

Perché si dovrebbe usare REST invece di SOAP servizi basati?

Ho partecipato a una demo interessante su REST oggi, tuttavia, non riuscivo a pensare a un singolo motivo (né è stato presentato uno) perché REST è comunque migliore o più semplice da usare e implementare rispetto a uno SOAP.

Quali sono alcuni dei motivi per cui qualcuno nel "mondo reale" usa REST invece dei SOAP servizi basati?

150
AngryHacker

Meno spese generali (no SOAP busta per avvolgere ogni chiamata)

Meno duplicazione (HTTP rappresenta già operazioni come DELETE, PUT, GET, ecc. Che devono essere altrimenti rappresentate in una busta SOAP).

Più standardizzati: le operazioni HTTP sono ben comprese e funzionano in modo coerente. Alcune SOAP possono diventare schizzinose.

Più leggibile e testabile dall'uomo (più difficile da testare SOAP con solo un browser).

Non è necessario utilizzare XML (beh, in un certo senso non è necessario per SOAP, ma non ha senso dato che stai già analizzando la busta).

Le biblioteche hanno reso SOAP (tipo di) semplice. Ma stai sottraendo molta ridondanza sotto come ho notato. Sì in teoria SOAP può andare oltre altri trasporti in modo da evitare di cavalcare uno strato facendo cose simili, ma in realtà quasi tutto SOAP il lavoro che farai mai è su HTTP.

I servizi RESTful sono molto più semplici da consumare rispetto a [~ # ~] soap [~ # ~] servizi (regolari) basati. La ragione di ciò è che REST si basa su normali richieste HTTP che consentono di dedurre l'intento dal tipo di richiesta effettuata (GET = retrive, POST = write, DELETE = remove, etc ...) ed è completamente apolide. D'altra parte si potrebbe sostenere che è meno flessibile in quanto elimina il concetto di una busta di messaggio che contiene il contesto di richiesta.

Nella mia esperienza SOAP è stato preferito per i servizi all'interno dell'azienda e REST è stato preferito per i servizi esposti come API pubbliche.

Con strumenti come WCF nel framework .NET è molto banale implementare un servizio come REST o SOAP.

Alcune letture rilevanti:

36
Eric Schoonover

Suppongo che quando dici "servizi web" intendi SOAP e il set di standard WS- *. (Altrimenti, potrei sostenere che REST services are "web services".)

L'argomento canonico è che i servizi REST sono più vicini alla progettazione del web, cioè alla progettazione di HTTP e dell'infrastruttura associata. Pertanto, l'utilizzo di un servizio REST sarà più compatibile con gli strumenti e le tecniche web esistenti.

Naturalmente, una volta approfondito i dettagli, scopri che entrambi gli approcci hanno punti di forza in diversi scenari. Sono quelle specifiche che ti interessano?

13
Bruce

Il sovraccarico non è così importante come una buona architettura.

REST non è un protocollo, è un'architettura che incoraggia un buon design scalabile. Viene spesso scelto perché troppa libertà in RPC può facilmente portare a un design scadente.

L'altro motivo è il costo prevedibile dei protocolli RESTful su HTTP perché può sfruttare le tecnologie esistenti (principalmente i proxy). Il costo iniziale di RPC è piuttosto basso ma tende ad aumentare significativamente con l'intensificazione del carico.

10
Piotr Czapla

Devo leggere il più eccellente di Roy Fielding tesi sull'argomento. Fa un caso eccellente ed è stato sicuramente [~ # ~] molto [~ # ~] in anticipo sui tempi quando lo scrisse (2000).

7
Piko

REST è indipendente dall'implementazione e molto più trasparente, e questo lo rende ideale per le API pubbliche, in particolare per i grandi siti Web come Flickr, Amazon o Digg che utilizzano le loro API come strumenti di marketing e vogliono davvero che le persone consumino i propri dati. non vogliono essere in possesso di migliaia di sviluppatori alle prime armi che stanno cercando di eseguire il debug del loro linguaggio di scripting con il buggy SOAP.

Versus SOAP e WSDL, che sono migliori per le applicazioni interne, in cui hai librerie drop-in e conosciute persone indizi su entrambe le estremità. (E forse non devi preoccuparti di cose come Internet bilanciamento del carico, memorizzazione nella cache HTTP, ecc.) Quindi si ottengono API autodocumentate, preservano i tipi e così via con zero lavori.

7
joelhardi

blog di Steve Vinoski e i suoi ltimi articoli sono sicuramente degni di nota. È un ex guru di CORBA, che probabilmente ha scritto il miglior libro sull'argomento con Michi Henning, "Advanced CORBA® Programming with C++" . Tuttavia, da allora ha visto l'errore dei suoi modi client/server e ora giura per REST.

6
Jason Etheridge

REST consente alle operazioni non mutanti (che generalmente utilizzano il verbo GET) di essere memorizzato nella cache. Cioè, memorizzato nella cache dal client e/o memorizzato nella cache dai proxy. Questa può essere una grande vittoria!

5
David

REST è fondamentalmente solo un modo per implementare i servizi web. È solo un modo per utilizzare correttamente HTTP per interrogare i servizi Web che si sta tentando di colpire.

http://www.xfront.com/REST-Web-Services.htmlhttp://en.wikipedia.org/wiki/Representational_State_Transfer

3
Eric Holscher

Ecco un punto dati: Amazon offre le sue API in entrambi i formati REST e SOAP e l'85% dell'utilizzo è REST.

REST è più facile da implementare, più facile da capire e prestazioni più elevate.

0
pbreitenbach

È super semplice e sottile. Puoi farlo con il browser tramite il verbo http: GET. Non ho trovato un browser in grado di eseguire manualmente http POST facilmente)

0
Ray Lu