Qual è il vantaggio dell’utilizzo di REST anziché di HTTP non REST?

Apparentemente, REST è solo un insieme di convenzioni su come usare HTTP . Mi chiedo quale vantaggio forniscano queste convenzioni. Qualcuno sa?

Non credo che otterrete una buona risposta a questo, in parte perché nessuno è d’accordo su cosa sia REST. La pagina di Wikipedia è pesante su parole d’ordine e luce sulla spiegazione. La pagina di discussione merita di essere vista solo per vedere quante persone non sono d’accordo su questo. Per quanto ne so, REST significa questo:

Invece di avere gli URL setter e getter in modo casuale e l’utilizzo di GET per tutti i getter e POST per tutti i setter, proviamo a fare in modo che gli URL identificano le risorse e poi usino le azioni HTTP GET , POST , PUT e DELETE per fare loro roba . Quindi invece di

 GET /get_article?id=1 POST /delete_article id=1 

Lo faresti

 GET /articles/1/ DELETE /articles/1/ 

E poi POST e PUT corrispondono a “creare” e “aggiornare” le operazioni (ma nessuno è d’accordo su quale giro).

Penso che gli argomenti di memorizzazione nella cache siano errati, perché le stringhe di query sono generalmente memorizzate nella cache e inoltre non è necessario utilizzarle. Ad esempio, django rende qualcosa di simile molto facile, e non direi che è stato REST:

 GET /get_article/1/ POST /delete_article/ id=1 

O anche solo includere il verbo nell’URL:

 GET /read/article/1/ POST /delete/article/1/ POST /update/article/1/ POST /create/article/ 

In questo caso GET significa qualcosa senza effetti collaterali e POST significa qualcosa che cambia i dati sul server. Penso che questo sia forse un po ‘più chiaro e semplice, specialmente perché puoi evitare l’intera cosa PUT vs- POST . Inoltre, puoi aggiungere più verbi se lo desideri, in modo da non essere artificialmente legati a ciò che offre l’HTTP. Per esempio:

 POST /hide/article/1/ POST /show/article/1/ 

(O qualsiasi altra cosa, è difficile pensare ad esempi finché non accadono!)

Quindi, in conclusione, ci sono solo due vantaggi che posso vedere:

  1. La tua API Web potrebbe essere più chiara e facile da capire / scoprire.
  2. Quando si sincronizzano i dati con un sito Web, è probabilmente più semplice utilizzare REST perché si può semplicemente dire synchronize("/articles/1/") o qualsiasi altra cosa. Questo dipende molto dal tuo codice.

Tuttavia penso che ci siano alcuni svantaggi piuttosto grossi:

  1. Non tutte le azioni si associano facilmente a CRUD (creazione, lettura / recupero, aggiornamento, eliminazione). Potresti anche non avere a che fare con risorse di tipo object.
  2. È uno sforzo extra per i benefici dubbi.
  3. Confusione su quale giro PUT e POST sono. In inglese significano cose simili (“Sto per mettere / pubblicare un avviso sul muro.”).

Quindi, in conclusione, direi: a meno che tu non voglia veramente fare uno sforzo extra, o se il tuo servizio mappa davvero bene le operazioni CRUD, salva REST per la seconda versione della tua API.


Ho appena trovato un altro problema con REST: non è facile fare più di una cosa in una richiesta o specificare quali parti di un object composto vuoi ottenere. Ciò è particolarmente importante sui dispositivi mobili in cui il round-trip-time può essere significativo e le connessioni non sono affidabili. Ad esempio, supponiamo di ricevere post su una cronologia di Facebook. Il modo “puro” di REST 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/ .... 

Il che è abbastanza ridicolo. L’API di Facebook è un IMO piuttosto grande, quindi vediamo cosa fanno:

Per impostazione predefinita, la maggior parte delle proprietà dell’object viene restituita quando si effettua una query. Puoi scegliere i campi (o le connessioni) che vuoi vengano restituiti con il parametro di ricerca “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 qualcosa del genere con REST, e se lo facessi, sarebbe comunque valido come REST. Certamente ignorerei chiunque cerchi di dirti che non dovresti farlo (specialmente se il motivo è “perché non è REST”)!

In parole povere, REST significa usare HTTP come dovrebbe essere.

Dai un’occhiata alla tesi di Roy Fielding su REST . Penso che ogni persona che sta facendo sviluppo web dovrebbe leggerlo.

Come nota, Roy Fielding è anche uno dei fattori chiave dietro il protocollo HTTP.

Per citare alcuni degli advandages:

  • Semplice.
  • Puoi fare buon uso della cache HTTP e del server proxy per aiutarti a gestire un carico elevato.
  • Ti aiuta a organizzare anche un’applicazione molto complessa in risorse semplici.
  • Rende facile per i nuovi clienti utilizzare la tua applicazione, anche se non l’hai progettata appositamente per loro (probabilmente, perché non c’erano quando hai creato la tua app).

In poche parole: NONE .

Sentitevi liberi di downvotare, ma continuo a pensare che non ci siano reali benefici rispetto a HTTP non REST. Tutte le risposte correnti non sono valide. Argomenti dalla risposta attualmente più votata:

  • Semplice.
  • Puoi fare buon uso della cache HTTP e del server proxy per aiutarti a gestire un carico elevato.
  • Ti aiuta a organizzare anche un’applicazione molto complessa in risorse semplici.
  • Rende facile per i nuovi clienti utilizzare la tua applicazione, anche se non l’hai progettata appositamente per loro (probabilmente, perché non c’erano quando hai creato la tua app).

1. Semplice

Con REST è necessario un ulteriore livello di comunicazione per gli script lato server e lato client => in realtà è più complicato rispetto all’uso di HTTP non REST.

2. Caching

La memorizzazione nella cache può essere controllata da intestazioni HTTP inviate dal server. REST non aggiunge alcuna funzionalità mancante in non-REST.

3. Organizzazione

REST non ti aiuta a organizzare le cose. Ti obbliga a utilizzare l’API supportata dalla libreria sul lato server che stai utilizzando. È ansible organizzare la propria applicazione nello stesso modo (o migliore) quando si utilizza un approccio non REST. Ad esempio, vedere Model-View-Controller o routing MVC .

4. Facile da usare / implementare

Non è vero affatto. Tutto dipende da quanto bene organizzi e documenti la tua applicazione. REST non magicamente migliorerà la tua applicazione.

IMHO il più grande vantaggio che REST consente è quello di ridurre l’accoppiamento client / server. È molto più semplice evolvere un’interfaccia REST nel tempo senza rompere i client esistenti.

Discoverability

Ogni risorsa ha riferimenti ad altre risorse, sia nella gerarchia che nei collegamenti, quindi è facile da consultare. Questo è un vantaggio per l’umano che sviluppa il cliente, risparmiandolo dal consultare costantemente i documenti e offrire suggerimenti. Significa anche che il server può cambiare unilateralmente i nomi delle risorse (a condizione che il software client non codifichi gli URL).

Compatibilità con altri strumenti

Puoi accedere alla CURL in qualsiasi parte dell’API o utilizzare il browser Web per navigare tra le risorse. Rende molto più facile il debug e l’integrazione dei test.

Nomi dei verbi standardizzati

Ti permette di specificare le azioni senza dover cercare il testo corretto. Immagina se i getter e setter di OOP non fossero standardizzati, e alcune persone usassero retrieve e define invece. Dovresti memorizzare il verbo corretto per ogni singolo punto di accesso. Sapendo che c’è solo una manciata di verbi disponibili, questo problema si risolve.

Stato standardizzato

Se GET una risorsa che non esiste, puoi essere sicuro di ottenere un errore 404 in un’API RESTful. Confrontalo con un’API non RESTful, che può restituire {error: "Not found"} avvolto in Dio sa quanti livelli. Se hai bisogno dello spazio in più per scrivere un messaggio allo sviluppatore dall’altra parte, puoi sempre usare il corpo della risposta.

Esempio

Immagina due API con la stessa funzionalità, una dopo REST e l’altra no. Ora immagina i seguenti client per queste 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 ogni cliente ha funzionato, in che modo puoi essere sicuro che il resto funzioni?

  • C’è stato un aggiornamento importante dell’API che può o non può aver modificato tali punti di accesso. Quanti dei documenti dovresti 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 to My Wan di Ryan Tomayko

Modifica di terze parti

Estratto dal link waybackmaschine:

Che ne dici di un esempio. Sei un insegnante e vuoi gestire gli studenti:

  • in che class sono,
  • che voti stanno ottenendo,
  • contatti di emergenza,
  • informazioni sui libri che insegni, ecc.

Se i sistemi sono basati sul web, probabilmente c’è un URL per ciascuno dei nomi coinvolti qui: student, teacher, class, book, room, etc . … Se ci fosse una rappresentazione leggibile da una macchina per ogni URL, sarebbe banale inserire nuovi strumenti nel sistema perché tutte queste informazioni sarebbero consumabili in un modo standard. … potresti build un sistema nazionale che è stato in grado di parlare a ciascuno dei singoli sistemi scolastici per raccogliere i punteggi dei test.

Ciascuno dei sistemi otterrebbe informazioni gli uni dagli altri utilizzando un semplice HTTP GET. Se un sistema deve aggiungere qualcosa a un altro sistema, usa un POST HTTP. Se un sistema vuole aggiornare qualcosa in un altro sistema, usa un PUT HTTP. L’unica cosa che rimane da capire è come dovrebbero apparire i dati.

Suggerirei a tutti, chi è alla ricerca di una risposta a questa domanda, passare attraverso questa “presentazione” .

Non riuscivo a capire cos’è REST e perché è così bello, i suoi pro e contro, le differenze da SOAP – ma questo slideshow era così brillante e facile da capire, quindi è molto più chiaro per me ora, rispetto a prima.

Caching.

Ci sono altri benefici più approfonditi del REST che ruotano attorno all’evolvere-evolversi tramite accoppiamento lento e ipertesto, ma i meccanismi di caching sono la ragione principale per cui dovresti preoccuparti di HTTP RESTful.

È scritto nella tesi Fielding . Ma se non vuoi leggere molto:

  • aumento della scalabilità (a causa di vincoli di sistema stateless, cache e livelli)
  • client e server disaccoppiati (a causa di vincoli di interfaccia stateless e uniformi)
    • client riusabili (il client può utilizzare i browser REST generici e la semantica RDF per decidere quale collegamento seguire e come visualizzare i risultati)
    • client non violenti (i client si interrompono solo con modifiche semantiche specifiche dell’applicazione, perché usano la semantica invece di alcune conoscenze specifiche dell’API)
  • Dare ad ogni “risorsa” un ID
  • Collega le cose insieme
  • Usa metodi standard
  • Risorse con rappresentazioni multiple
  • Comunicare statelessly

È ansible fare tutto solo con POST e GET? Sì, è l’approccio migliore? No perchè? perché abbiamo metodi standard. Se ripensi, sarebbe ansible fare tutto usando solo GET .. quindi perché dovremmo preoccuparci di usare il POST? Per via degli standard!

Ad esempio, oggi pensando a un modello MVC, puoi limitare la tua applicazione a rispondere solo a tipi specifici di verbi come POST, GET, PUT e DELETE. Anche se sotto il cofano tutto viene emulato su POST e GET, non ha senso avere verbi diversi per azioni diverse?

La scoperta è molto più facile in REST. Abbiamo documenti WADL (simili a WSDL nei tradizionali servizi web) che ti aiuteranno a pubblicizzare il tuo servizio nel mondo. Puoi anche usare le scoperte UDDI. Con le tradizionali POST HTTP e GET le persone potrebbero non sapere la tua richiesta di messaggi e schemi di risposta per chiamarti.

Un vantaggio è che, possiamo elaborare in modo non sequenziale documenti XML e dati XML unmarshal da fonti diverse come l’object 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 denotare i valori di campo che i tuoi clienti potrebbero desiderare …

Ma questo è un dettaglio.

Molto più importante è il fatto che non hai menzionato gli enormi vantaggi dello stile architettonico REST (molto migliore scalabilità, a causa dell’apolidia del server, disponibilità molto migliore, dovuta anche all’apolidia del server), un uso molto migliore dei servizi standard, come la cache per esempio, quando si utilizza uno stile architettonico REST, accoppiamento molto più basso tra client e server, dovuto all’uso di un’interfaccia uniforms, ecc. ecc.)

Per quanto riguarda la tua osservazione

“Non tutte le azioni si associano facilmente a CRUD (crea, leggi / recupera, aggiorna, cancella).”

: 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 anche non avere a che fare con risorse di tipo object”

: un design RESTful è, per essenza, 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 gestire, ciò che deve essere fatto da esso, 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.