Perché abbiamo bisogno dei servizi Web RESTful?

Imparerò i servizi web RESTful (è meglio dire che dovrò farlo perché fa parte del corso di laurea magistrale CS).

Ho letto alcune informazioni su Wikipedia e ho anche letto un articolo su REST su Sun Developer Network e vedo che non è una tecnologia facile, ci sono framework speciali per la creazione di app RESTful e viene spesso confrontato con i servizi web SOAP e il programmatore dovrebbe capire quando usare SOAP e quando REST potrebbe essere un buon approccio.

Ricordo che molti anni fa SOAP era molto popolare (di moda?) E l'elemento "SOAP" doveva essere presente in ogni buon CV. Ma in pratica era usato molto raramente e per raggiungere scopi molto semplici.

Mi sembra che REST sia un'altra 'ultima parola di moda' (o posso sbagliarmi completamente perché non ho mai visto REST in pratica).

Puoi farmi alcuni esempi in cui REST dovrebbe essere usato e perché non possiamo fare lo stesso senza REST (o perché dovremmo dedicare molto più tempo a fare lo stesso senza REST)?

UPD : Sfortunatamente non riesco a vedere argomenti concreti che possano lasciarmi a bocca aperta nei primi commenti. Fammi pensare che REST sia una tecnologia fantastica!

Mi piacerebbe vedere risposte come questa:

Stavo sviluppando un'altra applicazione HelloWorld complessa e abbiamo bisogno di trasferire molti / piccoli dati e ho proposto la soluzione REST al mio collega:

- Oh dannazione! Jonny, dovremmo sicuramente usare REST per implementare questa app!
- Sì, Billy, possiamo usare REST, ma è meglio usare SOAP. Fidati di me perché so qualcosa sullo sviluppo di applicazioni HelloWorld.
- Ma SOAP è una tecnologia antiquata del secolo scorso e possiamo usarne una migliore.
- Billy, sei pronto a trascorrere 3 giorni per sperimentare con REST? Possiamo farlo con SOAP in 2 ore ..
- Sì, sono sicuro che impiegheremo ancora più tempo per ottenere la stessa sicurezza / prestazioni / / scalabilità / qualsiasi altra cosa con SOAP. Sono sicuro che le applicazioni HelloWorld dovrebbero essere sviluppate solo con REST da ora.

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.

REST è stato avviato, per quanto ne so, dalla dissertazione di Roy Fielding Architectural Styles and the Design of Network-based Software Architectures , che vale la pena leggere se non l'hai guardata.

In cima alla tesi c'è una citazione:

Quasi tutti si sentono in pace con la natura: ascoltano le onde dell'oceano contro la riva, vicino a un lago tranquillo, in un campo d'erba, su una brughiera battuta dal vento. Un giorno, quando avremo imparato di nuovo la via senza tempo, proveremo lo stesso per le nostre città, e ci sentiremo in pace in esse, come ci sentiamo oggi camminando in riva all'oceano o sdraiati sull'erba alta di un prato.

- Christopher Alexander, The Timeless Way of Building (1979)

E questo lo riassume davvero lì. REST è per molti versi più elegante.

SOAP è un protocollo su HTTP, quindi ignora molte convenzioni HTTP per creare nuove convenzioni in SOAP ed è in molti modi ridondante con HTTP. HTTP, tuttavia, è più che sufficiente per recuperare, cercare, scrivere ed eliminare informazioni tramite HTTP, e questo è molto di ciò che è REST. Poiché REST è costruito con HTTP anziché su di esso, significa anche che il software che vuole integrarsi con esso (come un browser web) non ha bisogno di comprendere SOAP per farlo, solo HTTP, che deve essere il massimo ampiamente compreso e integrato con il protocollo in uso a questo punto.

Da qui :

Vantaggi REST:

• Leggero: non molto markup xml aggiuntivo
• Risultati leggibili dall'uomo
• Facile da costruire: non sono necessari toolkit

Controlla anche questo :

Per essere onesti, REST non è la soluzione migliore per ogni servizio Web. I dati che devono essere protetti non devono essere inviati come parametri negli URI. E grandi quantità di dati, come quella negli ordini di acquisto dettagliati, possono diventare rapidamente ingombranti o addirittura fuori limite all'interno di un URI. In questi casi, SOAP è davvero una soluzione solida. Ma è importante provare prima REST e ricorrere a SOAP solo quando necessario. Ciò aiuta a mantenere lo sviluppo di applicazioni semplice e accessibile.

Posso tranquillamente dire di aver speso molto tempo per capirlo come principiante, ma questo è il miglior collegamento per iniziare con REST da zero! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

Solo per tirarti dentro

Pensa a cosa sia un "servizio web tradizionale". È un'interfaccia con "metodi" esposti. I client conoscono il nome, l'input e l'output dei metodi e quindi possono chiamarli.

Ora immagina un'interfaccia che non esponga i "metodi". Invece, espone "oggetti". Quindi, quando un client vede questa interfaccia, tutto ciò che vede sono uno o più "oggetti". "Un oggetto" non ha input e output - perché "non fa nulla". È un sostantivo, non un verbo. È "una cosa", non "un'azione".

Ad esempio, pensa a un servizio web tradizionale che fornisce le condizioni meteorologiche attuali se gli fornisci una città. Probabilmente ha un metodo web come GetWeatherInfo () che prende una città come input e fornisce dati meteorologici come output. Finora è facile per te capire come un client utilizzerà questo servizio web.

Ora immagina, al posto del suddetto servizio web, ce ne sia uno nuovo che espone le città come oggetti. Quindi, quando lo guardi come un cliente, invece di GetWeatherInfo (), vedi New York, Dallas, Los Angeles, Londra e così via. E queste città non hanno metodi specifici di applicazione che pendono da loro - sono apparentemente come gas inerti - loro stesse non reagiscono.

Stai pensando: beh, in che modo questo ti aiuta, come cliente, ad affrontare il clima di Dallas? Ci arriveremo tra pochi istanti.

Se tutto ciò che ottieni da un servizio web è un "insieme di oggetti", ovviamente hai bisogno di un modo per "agire su di essi". Gli oggetti stessi non hanno metodi da chiamare, quindi è necessario un insieme di azioni che è possibile applicare a questi oggetti. In altre parole, devi "applicare un verbo al sostantivo". Se vedi un oggetto, ad esempio, una mela, che è "un nome", puoi applicare "un verbo" come mangiare, ad esso. Ma non tutti i verbi possono essere applicati a tutti i nomi. Ad esempio, puoi guidare una macchina, ma non puoi guidare una televisione.

Quindi, se un servizio web espone solo oggetti e ti viene chiesto - beh, progettiamo ora alcune azioni o verbi standard che "tutti i client possono applicare a tutti gli oggetti che vedono", ...

Ecco alcune idee:

• REST vincola il tuo servizio a utilizzare un'interfaccia uniforme. Non devi perdere tempo a sognare ad occhi aperti (o litigare) su tutti i possibili modi in cui il tuo servizio potrebbe funzionare - hai il diritto di lavorare identificando le risorse nel tuo sistema. Si rivela già di per sé un grande lavoro, ma fortunatamente i problemi tendono ad essere definiti molto meglio.
• Con le risorse, le loro associazioni e le loro rappresentazioni in mano, c'è davvero poco da fare per implementare il tuo servizio perché molte decisioni sono state prese per te.
• Il tuo sistema assomiglierà molto agli altri sistemi RESTful; le curve di apprendimento per compagni di squadra, partner e clienti saranno ridotte.
• Avrai un vocabolario comune per discutere i problemi di progettazione con altri sviluppatori e anche con quelli meno tecnicamente orientati (come i clienti).
• Come dice Darrel, poiché stai utilizzando un design basato sull'ipertesto , il tuo servizio restringe l'ambito dell'accoppiamento a una sola cosa: i tipi di media. Questo ti aiuta come sviluppatore perché le modifiche al tuo sistema sono contenute in una ristretta fascia di contatti. Questo aiuta i tuoi clienti in quanto un minor numero di modifiche interromperà il loro codice.
• Quasi tutti i problemi che potresti avere nell'implementazione di REST possono essere risolti esponendo una nuova risorsa o ripensando il tuo modello di risorsa. Questo obiettivo è, IMO, un grande aumento della produttività.

In conclusione, REST rimuove molte delle decisioni di progettazione e implementazione più dispendiose in termini di tempo e controversie dal flusso di lavoro del tuo team. Si sposta l'attenzione dal attuazione vostro servizio per la progettazione di esso. E lo fa senza impilare gobbledygook sul protocollo HTTP.

La maggior parte delle risposte "professionali" su REST sembrano provenire da persone che non hanno mai sviluppato un servizio Web o client SOAP utilizzando un ambiente che fornisce strumenti appropriati per l'attività. Si lamentano di problemi che semplicemente non ho mai riscontrato, utilizzando Visual Studio .NET e Rational Web Developer di IBM. Suppongo che se devi sviluppare servizi web o client in un linguaggio di scripting, o qualche altro linguaggio con poco o nessun supporto per gli strumenti, queste sono lamentele valide.

Devo anche ammettere che molti dei punti "pro" sembrano cose che potrebbero effettivamente essere vere, ma che non ho mai visto un esempio che illustri il loro valore. In particolare, apprezzerei molto se qualcuno pubblicasse un commento contenente un collegamento a un buon esempio di servizio web REST. Questo dovrebbe essere uno che utilizza più livelli di risorsa, possibilmente in una gerarchia, e che utilizza correttamente i tipi di media. Forse se guardo un buon esempio, capirò, nel qual caso tornerò qui e lo ammetterò.

Per aggiungere una svolta leggermente prosaica alle risposte già fornite, il motivo per cui utilizziamo i servizi REST dove mi trovo è che se sai che puoi consegnare un URL a un partner commerciale e sapere che riceverà, in cambio, una lastra di XML ben strutturata non importa se stanno lavorando in .Net xx, PHP, Python, Java, Ruby o Dio sa cosa riduce drasticamente il mal di testa.

Significa anche che sul lato non tecnico i nostri addetti alle vendite possono vantarsi della nostra versatile API alle persone senza timori di sembrare dei muppet completi.

A parte i vantaggi tecnici, tutto ciò che è facile per un non tecnico da spiegare, dimostrare e di cui si sente sicuro è una buona cosa. SOAP, anche se altrettanto interessante per i tecnici è molto meno accessibile dai non tecnici e quindi non è così facile da "vendere".

Tendo a notare che le cose che i non tecnici possono ottenere la loro testa tendono a rimanere attaccate. Quindi dubito che REST come tecnica possa essere suscettibile come SOAP ai capricci della moda.

Ma tutto ciò che riguarda il non mettere nulla in un servizio REST che dovrebbe essere bloccato è doppiamente vero se non altro perché la tecnologia è così facilmente comprensibile da persone che non hanno una mentalità tecnica.

REST è uno stile di architettura per la progettazione di applicazioni in rete. L'idea è che, invece di utilizzare meccanismi complessi come CORBA, RPC o SOAP per connettersi tra macchine, viene utilizzato HTTP semplice per effettuare chiamate tra macchine.

In molti modi, il World Wide Web stesso, basato su HTTP, può essere visto come un'architettura basata su REST. Le applicazioni RESTful utilizzano richieste HTTP per inviare dati (creare e / o aggiornare), leggere dati (ad esempio, eseguire query) ed eliminare dati. Pertanto, REST utilizza HTTP per tutte e quattro le operazioni CRUD (Crea / Leggi / Aggiorna / Elimina).

REST è un'alternativa leggera a meccanismi come RPC (Remote Procedure Calls) e Web Services (SOAP, WSDL, et al.). Successivamente, vedremo quanto sia più semplice REST.

Nonostante sia semplice, REST è completo di tutte le funzionalità; non c'è praticamente nulla che puoi fare nei servizi Web che non possa essere fatto con un'architettura RESTful. REST non è uno "standard". Ad esempio, non ci sarà mai una raccomandazione W3C per REST. E sebbene esistano framework di programmazione REST, lavorare con REST è così semplice che spesso è possibile "eseguire il proprio" con funzionalità di libreria standard in linguaggi come Perl, Java o C #.