it-swarm.it

Pro e contro dell'architettura RESTful

La discussione più comune che ho visto in merito ai pro e contro di REST tende a inquadrare quella discussione relativa al SOAP. Non ho alcuna esperienza in entrambi. Sono attualmente di fronte a una decisione che la mia mancanza l'esperienza mi sta rendendo difficile da valutare. Sto iniziando a sviluppare un'applicazione che ha diversi componenti, principalmente un aspetto amministrativo che consente al proprietario di amministrare diversi siti, e un'interfaccia utente rivolta al pubblico che consente all'utente di interagire con i dati contenuti sull'host. Devo valutare le implicazioni di consentire a quest'ultima parte di essere ospitata ovunque e comunicare con la prima tramite un'architettura RESTful o di esigere che entrambi i componenti risiedano sullo stesso host. Quali sono le implicazioni chiave dello sviluppo dell'architettura RESTful, in particolare per quanto riguarda la sua capacità nei seguenti settori:

1: Sicurezza 2: Prestazioni 3: Complessità dell'interfaccia

EDIT: guardando alcune delle risposte a questa domanda - dovrei chiarire. Non sto cercando un confronto con SOAP - piuttosto una panoramica di REST applicazioni vs applicazioni in cui tutti i componenti risiedono su un host. (Grazie per le risposte anche se!)

20
sunwukung

Date queste aree, posso fornire una panoramica generale, ma non posso trarre le tue conclusioni per te. Esistono due aree principali in cui i due protocolli differiscono:

  • Formato del messaggio
  • Rilevazione del servizio

Il formato del messaggio è più facile da capire. La confezione di SOAP sia per le richieste che per le risposte è piuttosto pesante. C'è la busta SOAP che contiene sia un'intestazione che una sezione del corpo. L'intestazione può essere utilizzata da diversi filtri nella catena di richieste per eseguire una sorta di identificazione, autorizzazione, ecc. Tuttavia, XML è costoso da analizzare, il che comporta una certa penalità per la scalabilità del sistema. Quanto dipende dal livello di elaborazione SOAP nel tuo stack.

Il servizio di rilevamento è dove probabilmente avrai più contese. REST per sua stessa natura fornisce punti finali prevedibili e il contenuto della richiesta è una semplice richiesta HTTP. Il vantaggio è che non ci sono costi aggiuntivi aggiuntivi e gli utenti finali possono praticamente indovinare come fare ciò di cui hanno bisogno una volta capita la struttura dell'URL del tuo sito. Ovviamente, le persone ingenue attente alla sicurezza lo vedranno come un punto debole. Dopotutto, con SOAP, devi consumare un WSDL per sapere quali sono gli endpoint. Ovviamente, con SOAP ti è stato dato l'intero formato del messaggio in modo da poter effettuare attacchi più mirati.

Suddiviso per le categorie che hai dato:

Sicurezza

Nessuno dei due è intrinsecamente più sicuro dell'altro. Utilizzare buoni principi di sicurezza:

  • Crittografa le comunicazioni
  • Assicurati di autenticare e autorizzare gli utenti prima dell'elaborazione
  • Buone abitudini di codifica per evitare attacchi diretti
  • E questa è solo la breve lista.

Ricorda l'oscurità! = Sicurezza.

Performance

Sia le prestazioni non elaborate che la scalabilità andranno a REST a causa della richiesta che segue semplici protocolli HTTP. La maggior parte degli stack SOAP utilizzano l'analisi SAX (analisi basata sugli eventi) che migliora notevolmente la scalabilità degli stack SOAP, ma si verifica un impatto misurabile sull'overhead. SOAP ha il normale sovraccarico di elaborazione HTTP oltre al sovraccarico di analisi XML. REST ha solo il sovraccarico di elaborazione HTTP.

Complessità

Dal punto di vista del sistema, REST vince. Ci sono meno parti mobili, una catena di richiesta più snella, ecc. Ciò significa che è più facile renderlo affidabile.

Dal punto di vista del programmatore, SOAP può vincere se il IDE o il framework che stai utilizzando fornisce un buon supporto. In sostanza, con REST spetta a te eseguire il lavoro di preelaborazione (autenticazione/autorizzazione/ecc.) Mentre con SOAP gran parte di ciò può essere realizzato con una catena di elaborazione collegabile.

Preferenze

Sono molto a mio agio con le richieste HTTP e so come funziona il web. Di conseguenza, l'approccio REST è più preferibile per me. Tuttavia, so che alcuni dei miei clienti non si sentono a proprio agio con questo. Hanno letto alcuni articoli del settore che denunciano la sicurezza di REST vs. SOAP, ecc. In conclusione, nessuno dei due approcci garantisce la sicurezza. Sta a te assicurarti che l'applicazione sia sicura come deve essere. Ovviamente, un'applicazione di social web non richiede (o desidera) la stessa sicurezza di un sistema bancario o governativo. Molti SOAP stack includono processori che è possibile collegare per fornire una parvenza di sicurezza, ma è comunque responsabilità dell'utente cercarli e metterli in atto.

13
Berin Loritsch
  1. Sicurezza: Usa HTTPS. Questo vale per entrambi.
  2. Performance: . REST è meno costoso della CPU (meno analisi, marshalling, scartamento). Inoltre, la memorizzazione nella cache con REST è un gioco da ragazzi.
  3. Complessità: REST richiede molto meno in termini di installazione, dopo tutto è solo GET/POST. SOAP richiede molta più amministrazione da mantenere (wsdl ecc.), Ma è un po 'più semplice se il tuo IDE lo supporta.

Penso che SOAP sia troppo gonfio quando puoi fare la stessa cosa con REST e alcuni tipi di contenuto/mime. Inoltre, SOAP porta un sacco di overhead, a causa della sua natura avvolgente e del fatto che è più generale e non limitato a HTTP. SOAP è allettante da usare se il tuo IDE lo supporta correttamente e non vuoi imparare l'HTTP. Ma per me, REST è molto più facile da usare e molto più web friendly.

Al giorno d'oggi, ci sono ottime REST da usare. Se sei in Java, allora Jax-RS è davvero bello. Per alcune persone, questo è come il porno .

12
Martin Wickman

Penso che il più grande vantaggio di REST sia quello di rompere dalle architetture RPC. REST espone risorse, non processi. Ciò ti consente di creare un sistema liberamente vincolato, dove cambiamenti, miglioramenti e persino guasti di una parte hanno un impatto (negativo) limitato su altre parti.

Sfortunatamente, un uso improprio comune di REST è quello di esporre le tue strutture di dati interne (nei casi peggiori, è un CRUD del tuo database, ugh). Questo lo rende molto difficile farlo in sicurezza. L'uso "giusto" è quello di esporre oggetti di alto livello rilevanti per la parte del sistema che si sta gestendo e restituire liberamente codici di stato di errore in caso di incoerenza.

Un'altra parte spesso trascurata di REST è l'idempotenza della maggior parte dei verbi. Non solo GET, ma anche PUT e DELETE dovrebbero essere esattamente lo stesso risultato se applicati una o più volte (sei libero di restituendo un 404 se già eliminato, o "nessuna modifica" se il client STA PUTANDO lo stesso). Ciò porta a sistemi robusti e meno interdipendenza delle interpretazioni esatte della semantica.

8
Javier

Gli standard WS- * riguardano principalmente l'esecuzione di RPC su SOAP/HTTP. Quindi, tutto il pensiero che è andato su CORBA e J2EE e sui loro predecessori si è principalmente spostato a fare lo stesso tipo di cose in XML. Ciò significa cose come dichiarazioni di tipo e contratti di servizio, scambio di metadati, sicurezza dichiarativa, ecc. Tutto ciò che è roba "aziendale". È troppo utilizzato anche nell'impresa, francamente.

Le persone che costruiscono un'applicazione web come te, quasi certamente starebbero meglio usando un'architettura RESTful. Quasi ogni piattaforma può consumarlo e farlo in modo semplice e senza preoccuparsi di quale versione di quale specifica si sta utilizzando e una miriade di stranezze di conversione del tipo specifico di strumento ecc.

3
Jeremy

L'unico grande vantaggio di SOAP rispetto all'attuale REST è che SOAP è più facilmente attrezzato - la maggior parte dei client RESTful richiedono per capire l'interfaccia e scrivere un client di qualche tipo. Per SOAP, indico semplicemente wsdl.exe e genera classi per me.

0
Wyatt Barnett