Perché uno dovrebbe usare REST invece dei servizi basati su SOAP? [chiuso]

Oggi ho partecipato a una demo interessante su REST, ma non riuscivo a pensare a un singolo motivo (né è stato presentato) perché REST sia comunque migliore o più semplice da usare e implementare rispetto a uno stack di servizi basato su SOAP.

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

Meno sovraccarico (nessuna busta SOAP 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 implementazioni SOAP possono diventare schizzinose.

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

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

Le biblioteche hanno reso SOAP (tipo di) facile. 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 il lavoro SOAP che tu faccia mai è su HTTP.

I servizi RESTful sono molto più semplici da consumare rispetto ai servizi (regolari) basati su SOAP . La ragione di ciò è che REST si basa su normali richieste HTTP che consentono di dedurre l'intento dal tipo di richiesta (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 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 di Amazon Web Services: REST vs SOAP
• Dare Obasanjo scrive spesso di REST

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

L'argomento canonico è che i servizi REST sono una corrispondenza più stretta con la progettazione del web, ovvero la 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?

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.

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. Essi non vogliono essere 1000s-tenendo la mano gli sviluppatori alle prime armi che stanno cercando di eseguire il debug di loro linguaggio di scripting di libreria SOAP buggy di scelta.

Contro SOAP e WSDL, che sono migliori per le applicazioni interne, in cui si hanno librerie drop-in e persone conosciute da entrambe le parti. (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.

Devo leggere la tesi più eccellente di Roy Fielding sull'argomento. Fa un caso eccellente ed era sicuramente MODO avanti del suo tempo quando lo scrisse (2000).

Il blog di Steve Vinoski e i suoi ultimi articoli meritano sicuramente una visita. È un ex guru di CORBA, che ha probabilmente 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.

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

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.html http://en.wikipedia.org/wiki/Representational_State_Transfer

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

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.