Riposo contro soap. REST ha prestazioni migliori?

Ho letto alcune domande già pubblicate qui riguardo Soap and Rest e non ho trovato la risposta che sto cercando. Abbiamo un sistema che è stato costruito utilizzando i servizi web Soap. Il sistema non è molto performante ed è in discussione la sostituzione di 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 nell’usare REST invece di Soap? (Stiamo perdendo qualcosa?)

Grazie in anticipo.

Le prestazioni sono un argomento ampio.

Se intendi 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 intendi le prestazioni della rete (ad es. Larghezza di banda), REST ha prestazioni molto migliori. Fondamentalmente, è solo HTTP. Nessun sovraccarico. Quindi, se il servizio viene eseguito su HTTP comunque, non è ansible 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, sarai più performante 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 (dato che hai chiesto “cosa perderai?”):

Le interfacce RESTful tendono ad essere un po ‘più “chiacchierone”, quindi a seconda del dominio e del modo in cui si progettano le risorse, si potrebbe 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)

SOAP richiede che venga analizzato un messaggio XML e tutto ciò che è stato inviato e ricevuto extra .

REST di solito usa 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 super-ottimizzata come XERCES in C ++ o Java, mentre la maggior parte dei parser JSON sono inclusi nel tuo articolo o nella tua interpretazione.

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

Esprimi la domanda come se REST e SOAP 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 mapping 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?

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 falle nella sicurezza ).

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.

Sicuramente non sono 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 tanti kB sul filo.

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

Solo per aggiungere un po ‘alla risposta.

Byte di intestazione Http quando si richiede questa pagina utilizzando il browser Web Chrome: 761
Byte richiesti per il messaggio soap di esempio nell’articolo di Wikipedia : 299

La mia conclusione: non è la dimensione dei 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, è ansible sfruttare i meccanismi forniti da HTTP per la produzione di sistemi scalabili. Il caching e il partizionamento sono gli strumenti nel tuo cinturone.

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 ti permetta di richiedere dati informativi per migliaia di articoli diversi.

Lo sviluppatore SOAP definirebbe un metodo che ti consentirebbe di recuperare le informazioni per uno o più elementi che desideri … in una singola chiamata.

Lo sviluppatore REST sarebbe preoccupato che il suo URI sarebbe diventato troppo lungo, quindi avrebbe definito un metodo GET che avrebbe preso 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 ci sarebbero molti più round trip necessari per il servizio REST per realizzare 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.

In generale, un servizio Web basato su REST è preferito per 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.

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

Il servizio espone dati o business logic? (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? Dobbiamo fare chiamate AJAX? (REST può utilizzare XMLHttpRequest) La chiamata è sincrona o asincrona? La chiamata è statutaria o apolide? (REST è adatto per le operazioni CRUD statless) Quale 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)

Non devi fare la scelta, i moderni framework ti permettono di esporre i dati in quei 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.