Che cos'è REST? Leggermente confuso [chiuso]

Supponevo che REST fosse un servizio web, ma sembra che io sia errato nel pensare questo - quindi, cos'è REST?

Ho letto Wikipedia, ma non riesco ancora a avvolgerlo. Perché molti luoghi si riferiscono alle API come API REST?

REST non è un servizio web specifico ma un concetto di progettazione (architettura) per la gestione delle informazioni sullo stato. Il documento fondamentale su questo era la tesi di Roy Thomas Fielding (2000), "Stili architettonici e la progettazione di architetture software basate su rete" ( disponibile online presso l'Università della California, Irvine).

Prima leggi il post di Ryan Tomayko. Come ho spiegato REST a mia moglie ; è un ottimo punto di partenza. Quindi leggi la tesi di Fielding. Non è così avanzato, né è lungo (sei capitoli, 180 pagine)! (So ​​che a scuola piacciono i ragazzi).

EDIT: sento inutile cercare di spiegare REST. Ha così tanti concetti come la scalabilità, la visibilità (apolide) ecc. Che il lettore deve comprendere e la migliore fonte per capire che sono la tesi vera e propria. È molto più di POST / GET ecc.

REST è un modello di progettazione software generalmente utilizzato per le applicazioni Web. In parole povere questo significa che è un'idea comunemente usata usata in molti progetti diversi. È l'acronimo di REpresentational State Transfer . L'idea di base di REST è trattare gli oggetti sul lato server (come nelle righe in una tabella di database) come risorse che possono essere create o distrutte.

Il modo più semplice di pensare a REST è come un modo di formattare gli URL delle tue applicazioni web. Ad esempio, se la tua risorsa è stata chiamata "post", allora:

/posts Sarebbe come un utente avrebbe accesso a TUTTI i post, per la visualizzazione.

/posts/:id Sarebbe come un utente accederebbe e visualizzerebbe un singolo post, recuperato in base al suo ID univoco.

/posts/new Sarebbe come visualizzare un modulo per la creazione di un nuovo post.

L'invio di una richiesta POST /userssarebbe come creare effettivamente un nuovo post a livello di database.

L'invio di una richiesta PUT /users/:idsarebbe come aggiornare gli attributi di un determinato post, identificato nuovamente da un ID univoco.

L'invio di una richiesta DELETE /users/:idsarebbe come eliminare un determinato post, identificato nuovamente da un ID univoco.

A quanto ho capito, il modello REST è stato principalmente reso popolare (per le app Web) dal framework Ruby on Rails, che pone una grande enfasi sulle rotte RESTful. Potrei sbagliarmi però.

Potrei non essere il più qualificato per parlarne, ma è così che l'ho imparato (in particolare per lo sviluppo di Rails).

Quando qualcuno fa riferimento a un "API REST", in genere ciò che intendono è un API che utilizza gli URL RESTful per il recupero dei dati.

RESTè uno stile architettonico e un progetto per architetture software basate su rete.

RESTi concetti sono indicati come risorse. Una rappresentazione di una risorsa deve essere apolide. È rappresentato tramite un tipo di supporto. Alcuni esempi di tipi di supporto comprendono XML, JSONe RDF. Le risorse sono manipolate dai componenti. I componenti richiedono e manipolano le risorse tramite un'interfaccia uniforme standard. Nel caso di HTTP, questa interfaccia è costituito da OPS HTTP standard ad esempio GET, PUT, POST, DELETE.

RESTviene generalmente utilizzato HTTP, principalmente a causa della semplicità di HTTP e della sua mappatura molto naturale ai principi RESTful. REST tuttavia non è legato ad alcun protocollo specifico.

Principi fondamentali di REST

Comunicazione client-server

Le architetture client-server hanno una netta separazione di preoccupazioni. Tutte le applicazioni costruite nello stile RESTful devono anche essere client-server in linea di principio.

apolide

Ogni richiesta client al server richiede che il suo stato sia completamente rappresentato. Il server deve essere in grado di comprendere completamente la richiesta del client senza utilizzare alcun contesto o stato della sessione del server. Ne consegue che tutto lo stato deve essere mantenuto sul client. Discuteremo la rappresentazione senza stato in modo più dettagliato in seguito.

cacheable

È possibile utilizzare i vincoli della cache, consentendo così di contrassegnare i dati di risposta come memorizzabili nella cache o non memorizzabili nella cache. Tutti i dati contrassegnati come memorizzabili nella cache possono essere riutilizzati come risposta alla stessa richiesta successiva.

Interfaccia uniforme

Tutti i componenti devono interagire attraverso un'unica interfaccia uniforme. Poiché tutte le interazioni tra componenti si verificano tramite questa interfaccia, l'interazione con servizi diversi è molto semplice. L'interfaccia è la stessa! Questo significa anche che le modifiche all'implementazione possono essere fatte isolatamente. Tali modifiche non influiranno sull'interazione dei componenti fondamentali poiché l'interfaccia uniforme è sempre invariata. Uno svantaggio è che sei bloccato con l'interfaccia. Se è possibile fornire un'ottimizzazione a un servizio specifico modificando l'interfaccia, si è sfortunati poiché REST lo proibisce. Il lato positivo, tuttavia, REST è ottimizzato per il web, quindi incredibile popolarità di REST su HTTP!

I concetti di cui sopra rappresentano le caratteristiche distintive di REST e differenziano l'architettura REST da altre architetture come i servizi web. È utile notare che un servizio REST è un servizio Web, ma un servizio Web non è necessariamente un servizio REST.

Vedi questo post sul blog su REST Design Principals per maggiori dettagli su REST e sui principi sopra.

È l'acronimo di Representational State Transfer e può significare molte cose, ma di solito quando parli di API e applicazioni, stai parlando di REST come un modo per fare servizi web o ottenere programmi per parlare sul web.

REST è fondamentalmente un modo di comunicare tra i sistemi e fa molto di ciò che SOPC è stato progettato per fare, ma mentre SOAP generalmente stabilisce una connessione, autentica e quindi fa cose su quella connessione, REST funziona più o meno allo stesso modo in cui funziona il web . Hai un URL e quando richiedi tale URL ricevi qualcosa in cambio. È qui che le cose iniziano a diventare confuse perché le persone descrivono il Web come la più grande applicazione REST e mentre questo è tecnicamente corretto, non aiuta davvero a spiegare di cosa si tratta.

In breve, REST ti consente di far parlare due applicazioni su Internet usando strumenti simili a quelli che utilizza un browser web. Questo è molto più semplice di SOAP e molto di ciò che fa REST è: "Ehi, le cose non devono essere così complesse".

Vale la pena leggere:

• Come ho spiegato REST a My Wife (ora disponibile qui)
• Stili architettonici e progettazione di architetture software basate su rete

http://en.wikipedia.org/wiki/Representational_State_Transfer

L'idea di base è che invece di avere una connessione in corso al server, fai una richiesta, ottieni alcuni dati, li mostri a un utente, ma forse non tutti, e quindi quando l'utente fa qualcosa che richiede più dati, o per passare alcuni al server, il client avvia una modifica a un nuovo stato.