Pro e contro dell'architettura RESTful [chiuso]

La discussione più comune che ho visto sui pro e contro di REST tende a inquadrare quella discussione relativa a SOAP. Neanche io ho esperienza. Sono attualmente di fronte a una decisione che la mia mancanza di 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 conservati 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 esigere che entrambi i componenti risiedano sullo stesso host. Quali sono le principali implicazioni dello sviluppo dell'architettura RESTful, in particolare per quanto riguarda la sua capacità nelle seguenti aree:

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, ma piuttosto una panoramica delle applicazioni REST rispetto alle applicazioni in cui tutti i componenti risiedono su un host. (grazie per quelle risposte però!)

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. Il packaging 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 end point 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 dopo aver compreso 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. Naturalmente, 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.

Prestazione

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 utilizza 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 l'IDE o il framework in uso 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.

La mia preferenza

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 stack SOAP includono processori che è possibile collegare per fornire una parvenza di sicurezza, ma è comunque responsabilità dell'utente cercarli e metterli in atto.

1. Sicurezza: utilizzare HTTPS. Questo vale per entrambi.
2. Performance: . REST è meno costoso della CPU (meno analisi, marshalling, non-wrapping). 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 l'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 costi generali, grazie alla sua natura avvolgente e al fatto che è più generale e non limitato a HTTP. SOAP è tentato da usare se il tuo IDE lo supporta correttamente e non vuoi imparare HTTP. Ma per me, REST è molto più facile da usare e molto più web friendly.

Oggi ci sono ottime API REST da usare. Se ti piace Java, allora Jax-RS è davvero fantastico. Per alcune persone, questo è come il porno.

Penso che il più grande vantaggio di REST sia rompere dalle architetture RPC. REST espone risorse, non processi. Ciò consente di creare un sistema liberamente vincolato, in cui modifiche, miglioramenti e persino guasti di una parte hanno un impatto limitato (negativo) 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 rende molto difficile farlo in sicurezza. L'uso "corretto" è 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 OTTIENI, ma anche PUT e DELETE dovrebbero essere esattamente lo stesso risultato se applicati una o più volte (sei libero di restituire un 404 se già cancellato, o "nessuna modifica" se il client sta mettendo lo stesso). Ciò porta a sistemi robusti e meno interdipendenza delle interpretazioni esatte della semantica.

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.

L'unico grande vantaggio di SOAP rispetto alle attuali implementazioni REST è che SOAP è più facilmente utilizzabile: la maggior parte dei client RESTful mi richiede di comprendere l'interfaccia e scrivere un client di qualche tipo. Per SOAP, indico semplicemente wsdl.exe e genera classi per me.