Perché si dovrebbero usare REST invece dei servizi basati su SOAP?[Chiuso]

Question

Oggi ho partecipato a un'interessante demo su REST, tuttavia, non sono riuscito a pensare a un solo motivo (né ne è stato presentato uno) per cui REST sia in ogni caso migliore o più semplice da utilizzare e implementare rispetto a uno stack di servizi basato su SOAP.

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

Answer 1

Meno spese generali (nessuna busta SOAP in cui racchiudere ogni chiamata)

Meno duplicazioni (HTTP rappresenta già operazioni come DELETE, PUT, GET, ecc.che altrimenti dovranno essere rappresentati in una busta SOAP).

Più standardizzato: le operazioni HTTP sono ben comprese e funzionano in modo coerente.Alcune implementazioni SOAP possono diventare complesse.

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

Non è necessario utilizzare XML (beh, in un certo senso non è necessario nemmeno per SOAP, ma non ha quasi senso dato che stai già eseguendo l'analisi della busta).

Le biblioteche hanno reso SOAP (in un certo senso) semplice.Ma stai eliminando molta ridondanza sottostante, come ho notato.sì, in teoria SOAP può superare altri trasporti in modo da evitare di cavalcare su uno strato facendo cose simili, ma in realtà quasi tutto il lavoro SOAP che farai sarà su HTTP.

Answer 2

Riposante i servizi sono molto più semplici da consumare rispetto a SAPONE servizi basati (regolari).Il motivo è 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, ecc...) ed è completamente stateless.D'altra parte si potrebbe sostenere che è meno flessibile in quanto elimina il concetto di busta del messaggio che contiene il contesto della 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:

• Blog sui servizi Web di Amazon:RIPOSO vs SAPONE
• Dare Obasanjo scrive spesso di REST

Answer 3

Presumo che quando dici "servizi web" intendi SOAP e l'insieme di standard WS-*.(Altrimenti, potrei sostenere che i servizi REST Sono "servizi web".)

L'argomento canonico è che i servizi REST sono più vicini alla progettazione del web, ovvero 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 approfonditi i dettagli, scoprirai che entrambi gli approcci hanno punti di forza in diversi scenari.Sono questi i dettagli che ti interessano?

Answer 4

Le spese generali non sono così importanti quanto una buona architettura.

REST non è un protocollo, è un'architettura che incoraggia una buona progettazione scalabile.Viene spesso scelto perché troppa libertà nell'RPC può facilmente portare a una progettazione scadente.

L'altro motivo è il costo prevedibile dei protocolli RESTful su HTTP perché possono sfruttare le tecnologie esistenti (principalmente proxy).Il costo iniziale dell'RPC è piuttosto basso ma tende ad aumentare in modo significativo con l'intensificazione del carico.

Answer 5

REST è indipendente dall'implementazione e molto più trasparente, e questo lo rende ottimo 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 loro dati.Essi non voglio tenere per mano migliaia di sviluppatori alle prime armi che stanno cercando di eseguire il debug della libreria SOAP difettosa del loro linguaggio di scripting preferito.

Rispetto a SOAP e WSDL, che sono migliori per le applicazioni interne, dove si hanno librerie drop-in e persone competenti conosciute su entrambe le estremità.(E forse non devi preoccuparti di cose come il bilanciamento del carico su scala Internet, la memorizzazione nella cache HTTP ecc.) Quindi ottieni API autodocumentate, preserva i tipi ecc.con zero lavoro.

Answer 6

Devo leggere il più eccellente di Roy Fielding tesi sull'argomento.Fa un caso eccellente e lo è stato sicuramente MODO in anticipo sui tempi quando lo scrisse (2000).

Answer 7

Il blog di Steve Vinoski e il suo Articoli Recenti valgono sicuramente la pena di essere esaminati.È un ex guru CORBA, che ha scritto probabilmente il miglior libro sull'argomento con Michi Henning, "Programmazione CORBA® avanzata con C++".Tuttavia, da allora ha notato l'errore del suo approccio client/server e ora giura per REST.

Answer 8

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

Answer 9

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

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

Answer 10

È super semplice e sottile.Potresti farlo con il browser tramite il verbo http:OTTENERE.Non ho trovato che un browser possa eseguire manualmente facilmente richieste POST http generiche

Answer 11

Ecco un punto dati:Amazon offre le sue API sia in formato REST che SOAP e l'85% dell'utilizzo è REST.

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