Apparentemente, REST è solo un insieme di convenzioni su come usare HTTP . Mi chiedo quale vantaggio offrano queste convenzioni. Qualcuno sa?
Risposte:
Non credo che si otterrà una buona risposta a questo, in parte perché nessuno è d'accordo davvero su ciò che REST è . La pagina di Wikipedia è piena di parole d'ordine e di spiegazioni chiare. La pagina di discussione merita una scrematura solo per vedere quante persone non sono d'accordo su questo. Per quanto posso dire, REST significa questo:
Invece di avere setter e getter URL nome casuale e utilizzare GETper tutti i getter e POSTper tutti i setter, cerchiamo di avere gli URL identificare le risorse, e quindi utilizzare le azioni HTTP GET, POST, PUTe DELETEper fare cose per loro. Quindi invece di
GET /get_article?id=1
POST /delete_article id=1
Lo faresti
GET /articles/1/
DELETE /articles/1/
E quindi POSTe PUTcorrispondono alle operazioni "crea" e "aggiorna" (ma nessuno concorda in quale direzione).
Penso che gli argomenti della cache siano sbagliati, perché le stringhe di query sono generalmente memorizzate nella cache e inoltre non è necessario utilizzarle. Ad esempio, django rende qualcosa del genere molto semplice e non direi che fosse REST:
GET /get_article/1/
POST /delete_article/ id=1
O includi semplicemente il verbo nell'URL:
GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/
In tal caso GETsignifica qualcosa senza effetti collaterali e POSTsignifica qualcosa che modifica i dati sul server. Penso che questo sia forse un po 'più chiaro e più facile, soprattutto perché puoi evitare l'intera cosa PUT-vs- POST. Inoltre, puoi aggiungere più verbi se lo desideri, quindi non sei legato artificialmente a ciò che offre HTTP. Per esempio:
POST /hide/article/1/
POST /show/article/1/
(O qualunque cosa, è difficile pensare ad esempi fino a quando non accadono!)
Quindi, in conclusione, ci sono solo due vantaggi che posso vedere:
synchronize("/articles/1/")o altro. Questo dipende fortemente dal tuo codice.Tuttavia, penso che ci siano alcuni svantaggi piuttosto grandi:
PUTe intorno POST. In inglese significano cose simili ("Ho intenzione di mettere / pubblicare un avviso sul muro.").Quindi, in conclusione, direi: a meno che tu non voglia davvero impegnarti di più, o se il tuo servizio è davvero ben collegato alle operazioni CRUD, salva REST per la seconda versione della tua API.
Ho appena riscontrato un altro problema con REST: non è facile fare più di una cosa in una richiesta o specificare quali parti di un oggetto composto si desidera ottenere. Ciò è particolarmente importante sui dispositivi mobili in cui il tempo di andata e ritorno può essere significativo e le connessioni non sono affidabili. Ad esempio, supponiamo di ricevere post su una sequenza temporale di Facebook. Il modo "puro" di RESTO sarebbe qualcosa di simile
GET /timeline_posts // Returns a list of post IDs.
GET /timeline_posts/1/ // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....
Che è un po 'ridicolo. L'API di Facebook è un ottimo IMO, quindi vediamo cosa fanno:
Per impostazione predefinita, la maggior parte delle proprietà degli oggetti vengono restituite quando si effettua una query. È possibile scegliere i campi (o le connessioni) che si desidera restituire con il parametro di query "campi". Ad esempio, questo URL restituirà solo l'id, il nome e l'immagine di Ben: https://graph.facebook.com/bgolub?fields=id,name,picture
Non ho idea di come faresti una cosa del genere con REST, e se lo facessi se conterebbe comunque come REST. Sicuramente ignorerei chiunque cerchi di dirti che non dovresti farlo (soprattutto se il motivo è "perché non è RIPOSO")!
/user/{id}, quindi non è riposante. Considerare: il tuo browser deve venire preprogrammato sapendo come ottenere l'HTML per una domanda stackoverflow pagina?
In poche parole, REST significa usare HTTP come dovrebbe essere.
Dai un'occhiata alla tesi di Roy Fielding sul REST . Penso che ogni persona che sta facendo lo sviluppo web dovrebbe leggerlo.
Come nota, Roy Fielding è anche uno dei driver chiave dietro il protocollo HTTP.
Per nominare alcuni dei vantaggi:
In poche parole: NESSUNO .
Sentiti libero di sottovalutare, ma continuo a pensare che non ci siano benefici reali su HTTP non REST. Tutte le risposte correnti non sono valide. Argomenti della risposta attualmente più votata:
Con REST hai bisogno di un ulteriore livello di comunicazione per gli script lato server e lato client => in realtà è più complicato dell'uso di HTTP non REST.
La memorizzazione nella cache può essere controllata dalle intestazioni HTTP inviate dal server. REST non aggiunge alcuna funzionalità mancante in non REST.
REST non ti aiuta a organizzare le cose. Essa obbliga l'utilizzo di API supportate dalla libreria sul lato server che si sta utilizzando. È possibile organizzare l'applicazione allo stesso modo (o meglio) quando si utilizza un approccio non REST. Ad esempio, vedere Model-View-Controller o routing MVC .
Per niente vero. Tutto dipende da quanto bene organizzi e documenti la tua candidatura. REST non renderà magicamente migliore la tua applicazione.
IMHO il vantaggio maggiore che REST consente è quello di ridurre l'accoppiamento client / server. È molto più semplice evolvere nel tempo un'interfaccia REST senza rompere i client esistenti.
Ogni risorsa ha riferimenti ad altre risorse, sia nella gerarchia che nei collegamenti, quindi è facile navigare in giro. Questo è un vantaggio per l'essere umano che sviluppa il cliente, salvandolo dalla costante consultazione dei documenti e offrendo suggerimenti. Significa anche che il server può cambiare i nomi delle risorse unilateralmente (purché il software client non esegua l'hardcoding degli URL).
Puoi arricciarti in qualsiasi parte dell'API o utilizzare il browser Web per navigare tra le risorse. Semplifica notevolmente il debug e il test dell'integrazione.
Ti permette di specificare le azioni senza dover dare la caccia al testo corretto. Immagina se i getter e i setter di OOP non fossero standardizzati e alcune persone lo usassero retrievee defineinvece. Dovresti memorizzare il verbo corretto per ogni singolo punto di accesso. Sapere che esiste solo una manciata di verbi disponibili per contrastare quel problema.
Se si GETdispone di una risorsa che non esiste, si può essere sicuri di ottenere un 404errore in un'API RESTful. Contrastalo con un'API non RESTful, che può tornare {error: "Not found"}racchiusa in Dio sa quanti strati. Se hai bisogno di spazio extra per scrivere un messaggio allo sviluppatore dall'altra parte, puoi sempre usare il corpo della risposta.
Immagina due API con la stessa funzionalità, una dopo REST e l'altra no. Ora immagina i seguenti client per quelle API:
Riposante:
GET /products/1052/reviews
POST /products/1052/reviews "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10
HTTP:
GET /reviews?product_id=1052
POST /post_review?product_id=1052 "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10
Ora pensa alle seguenti domande:
Se la prima chiamata di ciascun client ha funzionato, quanto puoi essere sicuro che anche il resto funzionerà?
È stato apportato un importante aggiornamento all'API che potrebbe aver modificato o meno tali punti di accesso. Quanti documenti dovrai rileggere?
Puoi prevedere il ritorno dell'ultima query?
Devi modificare la recensione pubblicata (prima di eliminarla). Puoi farlo senza controllare i documenti?
Consiglio di dare un'occhiata a How I Explained REST di Ryan Tomayko a mia moglie
Estratto dal link waybackmaschine:
Che ne dici di un esempio. Sei un insegnante e vuoi gestire gli studenti:
Se i sistemi sono web-based, quindi c'è probabilmente un URL per ognuno dei nomi coinvolti qui: student, teacher, class, book, room, etc. ... Se ci fosse una rappresentazione leggibile dal computer per ciascun URL, sarebbe banale agganciare nuovi strumenti al sistema perché tutte quelle informazioni sarebbero consumabili in modo standard. ... potresti costruire un sistema a livello nazionale in grado di parlare con ciascuno dei singoli sistemi scolastici per raccogliere i punteggi dei test.
Ciascuno dei sistemi otterrebbe informazioni l'uno dall'altro utilizzando un semplice HTTP GET. Se un sistema deve aggiungere qualcosa a un altro sistema, userebbe un POST HTTP. Se un sistema desidera aggiornare qualcosa in un altro sistema, utilizza un HTTP PUT. L'unica cosa che resta da capire è come dovrebbero apparire i dati.
Suggerirei a tutti coloro che sono alla ricerca di una risposta a questa domanda di passare attraverso questa "presentazione" .
Non riuscivo a capire cosa fosse REST e perché fosse così bello, i suoi pro e contro, le differenze rispetto a SOAP - ma questa presentazione era così brillante e facile da capire, quindi ora è molto più chiaro per me rispetto a prima.
Caching.
Esistono altri vantaggi più approfonditi di REST che ruotano attorno all'abilità evolutiva tramite accoppiamento lento e ipertesto, ma i meccanismi di memorizzazione nella cache sono il motivo principale per cui dovresti preoccuparti di RESTful HTTP.
GET /get_article/19/e POST /update_articlese la memorizzazione nella cache è la tua preoccupazione. È ancora possibile fare tutto con un solo GETed POSTe credo che RESTsignifica "Usa GET, POST, PUTe DELETEsolo." e non solo "Non utilizzare stringhe di query". quindi quello che ho suggerito non sarebbe REST. Inoltre, nessuno può davvero essere d'accordo su ciò che REST è, quindi lo sto mettendo in un secchio con "Web 2.0".
È scritto nella tesi di Fielding . Ma se non vuoi leggere molto:
È possibile fare tutto solo con POST e GET? Sì, è l'approccio migliore? No perchè? perché abbiamo metodi standard. Se ci ripensi, sarebbe possibile fare tutto usando solo GET .. quindi perché dovremmo preoccuparci di usare il POST? A causa degli standard!
Ad esempio, oggi pensando a un modello MVC, è possibile limitare l'applicazione affinché risponda solo a tipi specifici di verbi come POST, GET, PUT e DELETE. Anche se sotto il cofano tutto è emulato in POST e GET, non ha senso avere verbi diversi per azioni diverse?
Il rilevamento è molto più semplice in REST. Abbiamo documenti WADL (simili a WSDL nei servizi Web tradizionali) che ti aiuteranno a pubblicizzare il tuo servizio nel mondo. Puoi anche utilizzare le scoperte UDDI. Con HTTP POST e GET tradizionali, le persone potrebbero non conoscere gli schemi di richiesta messaggi e risposta per chiamarti.
Un vantaggio è che, possiamo elaborare in modo non sequenziale documenti XML e dati XML non comuni da diverse fonti come oggetto InputStream, un URL, un nodo DOM ...
@Timmmm, sulla tua modifica:
GET /timeline_posts // could return the N first posts, with links to fetch the next/previous N posts
Ciò ridurrebbe drasticamente il numero di chiamate
E nulla ti impedisce di progettare un server che accetta parametri HTTP per indicare i valori dei campi che i tuoi clienti potrebbero desiderare ...
Ma questo è un dettaglio.
Molto più importante è il fatto che non hai menzionato enormi vantaggi dello stile architettonico REST (scalabilità molto migliore, dovuta all'apolidia del server; disponibilità molto migliore, dovuta anche all'apolidia del server; uso molto migliore dei servizi standard, come la memorizzazione nella cache per esempio, quando si utilizza uno stile architettonico REST; accoppiamento molto più basso tra client e server, a causa dell'uso di un'interfaccia uniforme; ecc. ecc.)
Per quanto riguarda la tua osservazione
"Non tutte le azioni sono facilmente mappabili su CRUD (creare, leggere / recuperare, aggiornare, eliminare)."
: un RDBMS utilizza anche un approccio CRUD (SELECT / INSERT / DELETE / UPDATE) e c'è sempre un modo per rappresentare e agire su un modello di dati.
Per quanto riguarda la tua frase
"Potresti non avere nemmeno a che fare con risorse del tipo di oggetto"
: un design RESTful è, in sostanza, un design semplice - ma questo NON significa che progettarlo sia semplice. Vedi la differenza? Dovrai pensare molto ai concetti che la tua applicazione rappresenterà e gestirà, cosa devi fare, se preferisci, per rappresentarlo tramite risorse. Ma se lo fai, ti ritroverai con un design più semplice ed efficiente.
Le stringhe di query possono essere ignorate dai motori di ricerca.