Riposo contro sapone. REST ha prestazioni migliori?

Question

Ho letto alcune domande già postate in merito a Sapone e Riposo e non ho trovato la risposta che sto cercando. Abbiamo un sistema che è stato creato utilizzando i servizi Web Soap. Il sistema non è molto performante ed è in discussione per sostituire tutti i servizi Web Soap per i servizi Web REST. Qualcuno ha sostenuto che Rest ha prestazioni migliori. Non so se questo è vero. (Questa era la mia prima domanda) Supponendo che questo sia vero, c'è qualche svantaggio usando il REST invece di Sapone? (Stiamo perdendo qualcosa?)

Grazie in anticipo.

Answer 1

Le prestazioni sono un argomento ampio.

Se si intende il carico del server, REST ha prestazioni leggermente migliori perché ha un sovraccarico minimo su HTTP. Solitamente SOAP porta con sé una pila di diversi (generatori) gestori e parser. Ad ogni modo, la differenza di prestazioni in sé non è così grande, ma il servizio RESTful è più facile da scalare visto che non ci sono sessioni lato server.

Se si intende la prestazione della rete (ad esempio larghezza di banda), REST ha prestazioni molto migliori. Fondamentalmente, è solo HTTP. Nessun sovraccarico. Quindi, se il servizio viene eseguito su HTTP comunque, non è possibile ottenere molto più snello di REST. Inoltre, se codifichi le tue rappresentazioni in JSON (al contrario di XML), salvi molti più byte.

In breve, direi di si, sarete più performanti con REST. Inoltre, (secondo me) renderà la tua interfaccia più facile da consumare per i tuoi clienti. Quindi, non solo il tuo server diventa più snello ma anche il client.

Tuttavia, un paio di cose da considerare (in quanto lei ha chiesto 'che cosa si perde?'):

interfacce RESTful tendono ad essere un po 'più "loquace", quindi a seconda del tuo dominio e come si progetta la vostra risorse, potresti finire per fare più richieste HTTP.

SOAP ha un supporto di strumenti molto ampio. Ad esempio, i consulenti lo adorano perché possono usare gli strumenti per definire l'interfaccia e generare il file wsdl e gli sviluppatori lo adorano perché possono usare un altro set di strumenti per generare tutto il codice di rete da quel file wsdl. Inoltre, XML come rappresentazione ha schemi e validatori, che in alcuni casi possono essere un problema chiave. (JSON e REST hanno roba simile in arrivo ma il supporto degli strumenti è molto indietro)

Answer 2

Non sono certo un esperto quando si tratta di SOAP vs REST, ma l'unica differenza di prestazioni che conosco è che SOAP ha un sacco di overhead durante l'invio/ricezione di pacchetti poiché è basato su XML, richiede un'intestazione SOAP, ecc. REST usa l'URL + querystring per fare una richiesta, e quindi non invia molti kB sul filo.

Sono sicuro che ci sono altri ppl qui su SO che può dare risposte migliori e più dettagliate, ma almeno ci ho provato;)

Answer 3

SOAP richiede un messaggio XML per essere analizzato e tutto ciò che < riduculouslylongnamespace: mylongtagname> extra/reduceulouslylongnamespace: mylongtagname> materiale da inviare e ricevere.

REST di solito utilizza qualcosa di molto più conciso e facilmente analizzabile come JSON.

Tuttavia, in pratica la differenza non è eccezionale.

Costruire un DOM da XML in genere eseguiva una parte di codice supervelocemente superottimizzata come XERCES in C++ o Java mentre la maggior parte dei parser JSON sono nel vostro catalogo personale o interpretato.

In un ambiente di rete veloce (LAN o banda larga) non c'è molta differenza tra l'invio di uno o due K contro 10-15 k.

Answer 4

Solo per aggiungere un po 'alla risposta di wuher.

header HTTP byte quando si richiede questa pagina utilizzando il browser web Chrome: 761
byte necessari per il messaggio di esempio sapone in wikipedia articolo: 299

La mia conclusione: Non è la dimensione del byte sul filo che consente a REST di funzionare bene.

È altamente improbabile che la semplice conversione di un servizio SOAP in REST ottenga vantaggi significativi in ​​termini di prestazioni. Il vantaggio REST è che se si seguono i vincoli, è possibile sfruttare i meccanismi forniti da HTTP per la produzione di sistemi scalabili. Il caching e il partizionamento sono gli strumenti nel tuo cinturone.

Answer 5

Esprimi la domanda come se REST e SAPONE fossero in qualche modo intercambiabili in un sistema esistente. Non sono.

Quando si utilizza SOAP (una tecnologia), di solito si dispone di un sistema definito in "metodi", poiché in effetti si ha a che fare con RPC.

Quando si utilizza REST (uno stile architettonico, non una tecnologia), si crea un sistema definito in termini di "risorse" e non in tutti i metodi. Non esiste una mappatura 1: 1 tra SOAP e REST. L'architettura del sistema è fondamentalmente diversa.

O stai semplicemente parlando di "RPC via URI", che spesso viene confuso con REST?

Answer 6

Tutto dipende. REST non ha una (buona) risposta per la situazione in cui i dati della richiesta potrebbero diventare grandi. Sento questo punto se a volte trascurato quando hyping REST.

Immaginiamo un servizio che consente di richiedere dati informativi per migliaia di articoli diversi.

Lo sviluppatore SOAP definirebbe un metodo che consente di recuperare le informazioni per uno o più elementi desiderati ... in una singola chiamata.

Lo sviluppatore REST si preoccuperebbe del fatto che il suo URI sarebbe diventato troppo lungo in modo da definire un metodo GET che prendesse un singolo elemento come parametro. Dovresti quindi chiamare più volte, una volta per ogni articolo, per ottenere i tuoi dati. Pulito e facile da capire ... ma.

In questo caso, per il servizio REST occorrono molti più viaggi di andata e ritorno per eseguire ciò che può essere fatto con una singola chiamata sul servizio SOAP.

Sì, so che esistono soluzioni alternative per la gestione dei dati di richieste di grandi dimensioni nello scenario REST. Ad esempio, puoi inserire le cose nel corpo della tua richiesta. Ma poi dovrai definire con cura (sia lato server che lato client) come questo deve essere interpretato. In queste situazioni inizi a sentire il dolore che REST non è realmente uno standard (come SOAP) ma più di un modo di fare le cose.

Per situazioni in cui viene scambiata solo una quantità relativamente limitata di dati, REST è una scelta molto buona. Alla fine della giornata questa è la maggior parte dei casi d'uso.

Answer 7

Una cosa che le altre risposte sembrano ignorare è il supporto REST per la memorizzazione nella cache e altri vantaggi di HTTP. Mentre SOAP utilizza HTTP, non sfrutta l'infrastruttura di supporto di HTTP. Il binding SOAP 1.1 definisce solo l'uso del verbo POST. Questo problema è stato risolto con la versione 1.2 con l'introduzione dei binding GET, tuttavia questo potrebbe essere un problema se si utilizza la versione precedente o non si utilizzano i binding appropriati.

La sicurezza è un'altra preoccupazione chiave per le prestazioni. Le applicazioni REST in genere utilizzano TLS o altri meccanismi di sicurezza del livello sessione. TLS è molto più veloce rispetto all'utilizzo di meccanismi di sicurezza a livello di applicazione come WS Security (WS Security soffre anche di security flaws).

Tuttavia, penso che questi siano per lo più problemi minori quando si confrontano i servizi basati su SOAP e REST. Puoi trovare soluzioni pratiche per i problemi di prestazioni di SOAP o REST. La mia opinione personale è che né SOAP, né REST (per REST voglio dire servizi REST basati su HTTP) sono appropriati per servizi che richiedono un throughput elevato e bassa latenza. Per quei tipi di servizi, probabilmente si vuole andare con qualcosa come Apache Thrift, 0MQ, o la miriade di altri protocolli RPC binari.

Answer 8

In generale, un servizio Web basato su REST è preferito a causa della sua semplicità, prestazioni, scalabilità e supporto per più formati di dati. SOAP è favorito laddove il servizio richiede un supporto completo per la sicurezza e l'affidabilità delle transazioni.

La risposta dipende in realtà dai requisiti funzionali e non funzionali. Chiedere le domande elencate di seguito ti aiuterà a scegliere.

Rif: http://java-success.blogspot.ca/2012/02/java-web-services-interview-questions.html

funziona il servizio esporre dati o logica di business? (REST è una scelta migliore per esporre i dati, SOAP WS potrebbe essere una scelta migliore per la logica). I consumatori e i fornitori di servizi richiedono un contratto formale? (SOAP ha un contratto formale tramite WSDL) Abbiamo bisogno di supportare più formati di dati? Abbiamo bisogno di effettuare chiamate AJAX? (REST può utilizzare XMLHttpRequest) La chiamata è sincrona o asincrona? La chiamata è statica o stateless? (REST è adatto per le operazioni CRUD statless) Che livello di sicurezza è richiesto? (SOAP WS offre un migliore supporto per la sicurezza) Quale livello di supporto per le transazioni è richiesto? (SOAP WS offre un supporto migliore per la gestione delle transazioni) Abbiamo una larghezza di banda limitata? (SOAP è più dettagliato) Cosa c'è di meglio per gli sviluppatori che costruiranno clienti per il servizio? (REST è più facile da implementare, testare e mantenere)

Answer 9

Non è necessario effettuare la scelta, i framework moderni consentono di esporre i dati in tali formati con una modifica minima. Seguire i requisiti aziendali e caricare il test dell'implementazione specifica per comprendere il throughput, non esiste una risposta corretta a questa domanda senza il test di carico corretto di un sistema specifico.