Pro e contro dell'architettura RESTful [chiuso]

Considerate queste aree, posso dare una panoramica approssimativa, ma non posso trarre le conclusioni per voi. Esistono due aree principali in cui i due protocolli differiscono:

• Formato messaggio
• Scoperta del servizio

Il formato del messaggio è più facile da capire. L'imballaggio SOAP per entrambe le richieste e le risposte è abbastanza 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 penalizzazione della scalabilità del sistema. Quanto dipende dal livello di elaborazione SOAP nello stack.

L'individuazione dei servizi è quella in cui probabilmente avrai più problemi. REST per sua natura fornisce end point prevedibili e il contenuto della richiesta è una semplice richiesta HTTP. Il vantaggio è che non vi è alcun sovraccarico aggiuntivo e gli utenti finali possono indovinare praticamente come fare ciò di cui hanno bisogno una volta che comprendono la struttura dell'URL del proprio sito. Naturalmente, le persone ingenue della sicurezza lo vedranno come una debolezza. Dopotutto, con SOAP, devi utilizzare un WSDL per sapere quali sono gli endpoint. Ovviamente, con SOAP hai ricevuto l'intero formato del messaggio in modo da poter effettuare attacchi più mirati.

Suddiviso in base alle categorie che hai dato:

Sicurezza

Né è intrinsecamente più sicuro dell'altro. Utilizza i buoni principi di sicurezza:

• Cripta 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 oscurità! = sicurezza.

Performance

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

Complessità

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

Dal punto di vista del programmatore, SOAP può vincere se l'IDE o il framework che stai utilizzando fornisce un buon supporto. Essenzialmente, con REST l'onere è su di te per eseguire il lavoro di pre-elaborazione (autenticazione / autorizzazione / ecc.) Mentre con SOAP molto 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 si sentono a disagio. Hanno letto alcuni articoli di settore che denunciano la sicurezza di REST vs. SOAP, ecc. In conclusione, nessuno dei due metodi garantisce la sicurezza. Sta a te assicurarti che l'applicazione sia sicura come deve essere. Ovviamente, un'applicazione web sociale non richiede (o desidera) tanta sicurezza quanto un sistema bancario o governativo. Molti stack SOAP includono processori che puoi collegare per fornire una parvenza di sicurezza, ma è comunque tua responsabilità cercarli e metterli a posto.

1. Sicurezza: utilizza HTTPS. Questo vale per entrambi.
2. Performance: . REST è meno costoso della CPU (meno parsing, marshalling, unwrapping). Inoltre, il caching con REST è un gioco da ragazzi.
3. Complessità: REST richiede molto meno in termini di configurazione, è solo GET / POST dopo tutto. SOAP richiede molta più amministrazione da mantenere (wsdl etc), 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 contenuti / mime-type. Inoltre, SOAP porta un sacco di spese generali, a causa della sua natura di wrapping-of-wrappers e del fatto che è più generale e non limitato a HTTP. SOAP è tentato di usarlo 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ù amichevole per il web.

Al giorno d'oggi, ci sono ottime API REST da usare. Se sei in Java, allora Jax-RS è davvero interessante. Per alcuni, questo è come un porno.

Penso che il più grande vantaggio di REST sia quello di interrompere le architetture RPC. REST espone risorse, non processi. Ciò consente di creare un sistema liberamente associato, in cui le modifiche, i miglioramenti e persino i fallimenti di una parte hanno un impatto (negativo) limitato su altre parti.

Sfortunatamente, un uso improprio di REST è quello di esporre le strutture interne dei dati (nei casi peggiori, è un CRUD del database, ugh). Ciò rende molto difficile da fare in sicurezza. L'uso "giusto" è quello di esporre oggetti di alto livello che sono rilevanti per la parte del sistema che stai gestendo e restituire generosamente codici di stato di errore su qualsiasi 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 restituire un 404 se già cancellato, o "nessun cambiamento" se il client PUTting è lo stesso). Ciò porta a sistemi solidi e meno interdipendenza delle esatte interpretazioni della semantica.

Gli standard WS- * riguardano principalmente l'esecuzione di RPC su SOAP / HTTP. Quindi, tutto il pensiero che è entrato in CORBA e J2EE e i loro predecessori si sono principalmente spostati a fare lo stesso genere di cose in XML. Ciò significa cose come dichiarazioni di tipo e contratti di servizio, scambio di metadati, sicurezza dichiarativa, ecc. Tutta quella roba "impresa". È troppo usato anche in azienda, francamente.

Le persone che costruiscono un'applicazione web su Internet come te, farebbero sicuramente meglio ad usare un'architettura RESTful. Quasi tutte le piattaforme possono consumarlo e farlo in modo semplice e senza preoccuparsi della versione di quale specifica si sta utilizzando e di una miriade di stravaganze nella conversione dei tipi di strumenti, ecc.

Solo il grande vantaggio di SOAP rispetto all'attuale implementazione REST è che SOAP è più facilmente utilizzabile - la maggior parte dei client RESTful mi richiede di capire l'interfaccia e scrivere un client di qualche tipo. Per SOAP, ho solo indicato wsdl.exe e genera classi per me.