Perché abbiamo bisogno di servizi Web RESTful?

Imparerò i servizi web RESTful (è meglio dire che dovrò farlo perché fa parte del programma CS master).

Ho letto alcune informazioni su Wikipedia e ho anche letto un articolo su REST presso Sun Developer Network e vedo che non è una tecnologia facile, ci sono framework speciali per la creazione di app RESTful, ed è spesso paragonato ai 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’articolo ‘SOAP’ doveva essere presente in ogni buon CV. Ma in pratica è stato usato molto raramente e per raggiungere scopi molto semplici.

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

Puoi darmi qualche esempio di REST da usare 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 alcun argomento concreto che possa farmi mancare la testa nei primi commenti. Fammi pensare che REST sia una tecnologia fantastica!

Mi piacerebbe vedere risposte come questa:

Stavo sviluppando un’altra complessa applicazione HelloWorld e abbiamo bisogno di trasferire molti / minuscoli dati e ho proposto la soluzione REST al mio compagno di lavoro:

– Oh dannazione! Jonny, dovremmo usare REST per implementare questa app!
– Sì, Billy, possiamo usare REST, ma faremmo meglio a usare SOAP. Fidati di me, perché so qualcosa sullo sviluppo di applicazioni HelloWorld.
– Ma SOAP è una tecnologia obsoleta del secolo scorso e possiamo usarne una migliore.
– Billy, sei pronto per passare 3 giorni a sperimentare con REST? Possiamo farlo con SOAP in 2 ore ..
– Sì, sono certo che avremo investito ancora più tempo per raggiungere 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 deve essere utilizzato se è molto importante minimizzare l’accoppiamento tra componenti client e server in un’applicazione distribuita.

Questo potrebbe 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 assicurarti che raggiungere questo basso livello di accoppiamento non è facile . È fondamentale seguire tutti i vincoli di REST per avere successo. Mantenere una connessione prettamente stateless è difficile. Scegliere i giusti tipi di media e stringere i dati nei formati è complicato. Creare i tuoi tipi di media può essere ancora più difficile.

L’adattamento del comportamento di un server ricco all’interfaccia HTTP uniforms può generare confusione ea volte 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 a causa dell’uso coerente del protocollo HTTP. Il servizio dovrebbe essere facilmente rilevabile a causa di hypermedia e il client dovrebbe essere estremamente resistente alle modifiche sul server .

I vantaggi di hypermedia e l’eliminazione dello stato della sessione rendono il bilanciamento del carico semplice e il partizionamento del servizio fattibile . La stretta conformità alle regole HTTP rende la disponibilità di strumenti come debugger e proxy di memorizzazione nella cache di una cosa meravigliosa.

Aggiornare

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

Penso che REST sia diventato di moda perché le persone che tentano di fare progetti di tipo SOA hanno scoperto che usando lo stack SOAP non stanno realizzando i benefici promessi. Le persone continuano a tornare sul web come esempio di semplici metodologie di integrazione. Sfortunatamente, penso che le persone sottovalutino la quantità di pianificazione e lungimiranza che hanno contribuito alla creazione del 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 hai bisogno di fare un aggiornamento del browser quando qualcuno cambia qualche 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 una “descrizione del servizio-lingua” al browser web per dirgli quando va a http://example.org/images/cat che il tipo di ritorno sarà un’immagine jpeg e quando andrai a http://example.org/description/cat il tipo di ritorno sarà text / html?
  • Perché è ansible utilizzare un browser Web per visitare siti che non esistevano al momento del rilascio del browser? Come può il cliente conoscere questi siti?

Potrebbero sembrare domande stupide, ma se conosci la risposta, puoi iniziare a vedere di cosa si tratta REST. Guarda StackOverflow per ulteriori vantaggi di REST. Quando guardo una domanda, posso aggiungere questa pagina ai preferiti o inviare l’url ad un amico e lui può vedere le stesse informazioni. Non deve navigare attraverso il sito per trovare quella domanda.

StackOverflow utilizza una varietà di servizi OpenId per l’autenticazione, gravatar.com per immagini di avatar, google-analytics e Quantserve per informazioni analitiche. Questo tipo di integrazione multi-azienda è il tipo di cosa che il mondo SOAP sogna solo . Uno dei migliori esempi è il fatto che le librerie jQuery utilizzate per guidare l’interfaccia utente StackOverflow sono recuperate dalla rete di Content Delivery di Google. Il fatto che SO possa indirizzare il client (ovvero il browser Web) per scaricare il codice da un sito di terze parti per migliorare le prestazioni è la prova del basso accoppiamento tra client Web e server.

Questi sono esempi di un’architettura REST al lavoro.

Ora alcuni siti Web / applicazioni infrangono le regole di REST e quindi il browser non funziona come previsto.

  • Il famigerato problema del pulsante back è causato dall’utilizzo dello stato di 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 interrompe 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 correttamente o sono stati ignorati per qualsiasi motivo.
  • L’uso delle sessioni di accesso è la fonte di molte falle nella sicurezza.

Il RESTO è ovunque. È la parte del web che lo fa funzionare bene. Se vuoi creare applicazioni distribuite che possono scalare come il web, essere resilienti a cambiare come il web e promuovere il riutilizzo come il web ha fatto, quindi seguire le stesse regole che hanno fatto quando si costruiscono i browser web.

REST è stato avviato, per quanto ne so, dalla dissertazione di Roy Fielding Architectural Styles e dal Design of Network-based Software Architectures , che merita una lettura se non l’hai guardato.

Nella parte superiore della tesi è una citazione:

Quasi tutti si sentono in pace con la natura: ascoltando le onde dell’oceano contro la riva, da un lago immobile, in un campo di erba, su una brughiera spazzata dal vento. Un giorno, quando avremo imparato di nuovo la via senza tempo, sentiremo la stessa cosa per le nostre città, e sentiremo tanto pace in loro, come oggi camminiamo sull’oceano, o stesi nell’erba alta di un prato.

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

E questo in realtà lo riassume. REST è in molti modi più elegante.

SOAP è un protocollo su HTTP, quindi ignora molte convenzioni HTTP per creare nuove convenzioni in SOAP ed è ridondante in molti modi con HTTP. HTTP, tuttavia, è più che sufficiente per reinserire, cercare, scrivere e cancellare informazioni via 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 capire SOAP per farlo, solo HTTP, che deve essere il più ampiamente compreso e integrato con il protocollo in uso a questo punto.

Da qui :

Vantaggi del REST:

  • Leggero – non un sacco di markup extra xml
  • Risultati leggibili dall’uomo
  • Facile da compilare, nessun kit richiesto

Controlla anche questo :

Per essere onesti, REST non è la soluzione migliore per ogni servizio Web. I dati che devono essere sicuri non devono essere inviati come parametri negli URI. E grandi quantità di dati, come quella degli 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 al SOAP solo quando necessario. Ciò aiuta a mantenere lo sviluppo delle applicazioni semplice e accessibile.

Posso tranquillamente dire che ho speso un sacco di tempo per capire questo come un principiante ma questo è il miglior link per iniziare da 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 “metodi”. Invece, espone “oggetti”. Quindi, quando un client vede questa interfaccia, tutto ciò che vede sono uno o più “oggetti”. “Un object” non ha input e output, perché “non fa nulla”. È un nome, non un verbo. È “una cosa”, non “un’azione”.

Ad esempio, pensa a un servizio web tradizionale che fornisce le condizioni meteorologiche attuali se fornisci una città. Probabilmente ha un metodo web come GetWeatherInfo () che prende una città come input e fornisce dati meteo come output. Per ora è facile per te capire come un cliente consumerà questo servizio web.

Ora immagina, al posto del servizio web di cui sopra, ce n’è 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 per le applicazioni che pendono da esse – sono apparentemente come gas inerti – essi stessi non reagiscono.

Devi pensare – beh, come ti aiuta, come cliente, ad arrivare al clima di Dallas? Ci arriveremo in pochi istanti.

Se tutto quello che ottieni da un servizio web è un “set di oggetti”, ovviamente hai bisogno di un modo per “agire su di loro”. Gli oggetti stessi non hanno metodi da chiamare, quindi è necessario un insieme di azioni che è ansible applicare su questi oggetti. In altre parole, è necessario “applicare un verbo al nome”. Se vedi un object, diciamo, una mela, che è “un sostantivo”, 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 guidare un televisore.

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”, …

La maggior parte delle risposte “professionali” su REST sembrano provenire da persone che non hanno mai sviluppato un servizio Web o client SOAP che utilizza un ambiente che fornisce strumenti appropriati per l’attività. Si lamentano di problemi che non ho mai incontrato, 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 in qualche altra lingua con supporto di strumenti minimo o nullo, questi sono reclami validi.

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, sarei molto grato se qualcuno pubblicasse un commento contenente un link a un buon esempio di un servizio web REST. Questo dovrebbe essere uno che utilizza più livelli di risorse, 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 uno spin leggermente prosaico alle risposte già date il motivo per cui utilizziamo i servizi REST in cui sono io, se sai che puoi consegnare un business partner a un URL e sapere che riceveranno, 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 gravemente il mal di testa.

Significa anche che sul lato non tecnologico i nostri addetti alle vendite possono vantarsi della nostra versatile API per le persone senza timori di apparire come muppet completi.

A parte i vantaggi tecnici, è facile per una persona non tecnica spiegare, dimostrare e sentirsi fiducioso è una buona cosa. SOAP, anche se altrettanto interessante per i tecnici è molto meno accessibile dai non-techies e quindi non è così facile da “vendere”.

Tendo a notare che le cose che i non-tecnologi riescono a tenere a bada tendono a restare. Quindi dubito del REST in quanto una tecnica è suscettibile di essere tanto sensibile quanto SOAP ai capricci della moda.

Ma tutto ciò che riguarda il non mettere nulla in un servizio REST che dovrebbe essere bloccato è vero anche se solo perché la tecnologia è così facilmente comprensibile da persone che non sono così tecnicamente orientate.

Ecco alcune idee:

  • REST vincola il servizio a utilizzare un’interfaccia uniforms. Non devi perdere tempo a sognare ad occhi aperti (oa discutere) su tutti i possibili modi in cui il tuo servizio potrebbe funzionare: hai diritto a lavorare identificando le risorse del tuo sistema. Risulta essere un grande lavoro in sé, ma per fortuna i problemi tendono ad essere definiti molto meglio.
  • Con le risorse, le loro associazioni e le loro rappresentazioni in mano, c’è davvero molto poco da fare nell’implementazione del tuo servizio perché sono state prese molte decisioni 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 usando un design guidato da 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 stretta banda di contatti. Ciò aiuta i tuoi clienti in un numero inferiore di modifiche che 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 risorse. Questo objective è, IMO, un grande incremento di produttività.

In conclusione, REST rimuove molte delle decisioni di progettazione e implementazione più dispendiose in termini di tempo e contenimento dal stream di lavoro del tuo team. Sposta la tua attenzione dall’implementazione del tuo servizio alla sua progettazione . E lo fa senza impilare gobbledygook sul protocollo HTTP.

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

In molti modi, il World Wide Web stesso, basato su HTTP, può essere visto come un’architettura basata su REST. Le applicazioni REST utilizzano le richieste HTTP per inviare dati (creare e / o aggiornare), leggere dati (ad esempio, creare 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, ecc.). Più avanti vedremo quanto è più semplice il REST.

Nonostante sia semplice, REST è completo; non c’è praticamente nulla che puoi fare nei servizi Web che non può essere fatto con un’architettura RESTful. REST non è uno “standard”. Ad esempio, non ci sarà mai una raccomandazione del W3C per REST. E mentre ci sono i framework di programmazione REST, lavorare con REST è così semplice che spesso è ansible “rollare il proprio” con funzionalità di libreria standard in linguaggi come Perl, Java o C #.