REST dovrebbe essere utilizzato se è molto importante ridurre al minimo l'accoppiamento tra i componenti client e server in un'applicazione distribuita.
Questo può essere il caso se il tuo server verrà utilizzato da molti client diversi su cui non hai il controllo. Potrebbe anche essere il caso se si desidera essere in grado di aggiornare il server regolarmente senza dover aggiornare il software client.
Posso assicurarvi che raggiungere questo basso livello di accoppiamento non è facile . È fondamentale seguire tutti i vincoli di REST per avere successo. Mantenere una connessione puramente apolide è difficile. Scegliere i giusti tipi di media e comprimere i dati nei formati è complicato. Creare i tuoi tipi di media può essere ancora più difficile.
Adattare il comportamento del server avanzato all'interfaccia HTTP uniforme può essere fonte di confusione e talvolta appare pedante rispetto all'approccio RPC relativamente semplice.
Nonostante le difficoltà, i vantaggi sono che si dispone di un servizio che uno sviluppatore client dovrebbe essere in grado di comprendere facilmente grazie all'uso coerente del protocollo HTTP. Il servizio dovrebbe essere facilmente individuabile grazie all'ipermedia e il client dovrebbe essere estremamente resistente alle modifiche sul server .
I vantaggi dell'ipermedia e la prevenzione dello stato della sessione rendono il bilanciamento del carico semplice e il partizionamento dei servizi fattibile . La stretta conformità alle regole HTTP rende la disponibilità di strumenti come debugger e proxy di cache una cosa meravigliosa.
Aggiornare
Mi sembra che REST sia un'altra 'ultima parola di moda' (o posso sbagliarmi completamente perché non ho mai visto REST in pratica).
Penso che REST sia diventato di moda perché le persone che tentano di realizzare progetti di tipo SOA hanno scoperto che utilizzando lo stack SOAP non si stanno realizzando i vantaggi che erano stati promessi. Le persone continuano a tornare al Web come esempio di semplici metodologie di integrazione. Sfortunatamente, penso che le persone sottovalutino la quantità di pianificazione e lungimiranza che sono state impiegate per creare il Web e semplificano eccessivamente ciò che deve essere fatto per consentire il tipo di riutilizzo fortuito che si verifica sul Web.
Dici che non hai mai visto REST in pratica, ma questo non può essere vero se usi un browser web. Il browser web è un client REST.
- Perché non è necessario aggiornare il browser quando qualcuno cambia un po 'di html su un sito web?
- Perché posso aggiungere un nuovo set completo di pagine a un sito web e il "client" può ancora accedere a quelle nuove pagine senza un aggiornamento?
- Perché non ho bisogno di fornire un "linguaggio di descrizione del servizio" al browser web per dirgli quando va su http://example.org/images/cat che il tipo di ritorno sarà un'immagine jpeg e quando vai a
http://example.org/description/cat
il tipo di ritorno sarà text / html?
- Perché posso utilizzare un browser web per visitare siti che non esistevano al momento del rilascio del browser? Come può il cliente conoscere questi siti?
Queste possono sembrare domande sciocche, ma se conosci la risposta, puoi iniziare a vedere di cosa tratta REST. Guarda StackOverflow per ulteriori vantaggi di REST. Quando guardo una domanda, posso aggiungere quella pagina ai segnalibri o inviare l'URL a un amico e lui può vedere le stesse informazioni. Non deve navigare nel sito per trovare quella domanda.
StackOverflow utilizza una varietà di servizi OpenId per l'autenticazione, gravatar.com per le immagini avatar, google-analytics e Quantserve per le informazioni analitiche. Questo tipo di integrazione multi-azienda è il tipo di cose che il mondo SOAP sogna solo . Uno dei migliori esempi è il fatto che le librerie jQuery utilizzate per guidare l'interfaccia utente StackOverflow vengono recuperate dalla Content Delivery Network di Google. Il fatto che SO possa indirizzare il client (cioè il tuo browser web) a scaricare codice da un sito di terze parti per migliorare le prestazioni è testimonianza del basso accoppiamento tra client web e server.
Questi sono esempi di un'architettura REST al lavoro.
Ora alcuni siti / applicazioni web infrangono le regole di REST e quindi il browser non funziona come previsto.
- Il famigerato problema del pulsante Indietro
è causato dall'utilizzo dello stato della sessione lato server.
- Il bilanciamento del carico può diventare un problema quando si dispone dello stato della sessione lato server.
- Le applicazioni Flash spesso impediscono all'URL di identificare specificamente una rappresentazione.
- L'altro problema che rompe i browser web è la scarsa conformità agli standard di tipo multimediale. Sentiamo tutto il tempo su come IE6 deve essere ucciso. Il problema è che gli standard non sono stati seguiti adeguatamente o sono stati ignorati per qualsiasi motivo.
- L'utilizzo delle sessioni di accesso è all'origine di molte falle di sicurezza.
IL RIPOSO è ovunque. È la parte del web che lo fa funzionare bene. Se desideri creare applicazioni distribuite in grado di scalare come il Web, essere resiliente al cambiamento come il Web e promuovere il riutilizzo come ha fatto il Web, quindi segui le stesse regole che hanno fatto durante la creazione dei browser Web.