Differenza tra REST e CRUD

Ho imparato REST e mi sembra molto CRUD (da quello che ho letto su CRUD).

So che sono diversi e mi chiedo se pensare che siano simili significa che non li capisco.

REST è un "superset" di CRUD? Tutto fa CRUD e altro?

Sorprendentemente, non vedo nelle altre risposte ciò che considero la vera differenza tra REST e CRUD: ciò che ognuno gestisce.

CRUD indica le operazioni di base da eseguire in un repository di dati. Gestisci direttamente record o oggetti dati; a parte queste operazioni, i record sono entità passive. In genere sono solo tabelle e record del database.

REST, d'altra parte, opera su rappresentazioni di risorse, ognuna identificata da un URL. In genere non si tratta di oggetti dati, ma astrazioni di oggetti complessi.

Ad esempio, una risorsa può essere il commento di un utente. Ciò significa non solo un record in una tabella 'comment', ma anche i suoi rapporti con la risorsa 'user', il post a cui è allegato il commento, forse un altro commento a cui risponde.

Operare sul commento non è un'operazione di database primitiva, può avere effetti collaterali significativi, come l'invio di un avviso al poster originale o il ricalcolo di alcuni "punti" simili a giochi o l'aggiornamento di alcuni "stream di follower".

Inoltre, una rappresentazione delle risorse include ipertesto (controllare il principio HATEOAS ), consentendo al progettista di esprimere relazioni tra risorse o guidare il client REST nel flusso di lavoro di un'operazione.

In breve, CRUD è un insieme di operazioni primitive (principalmente per database e archivi di dati statici), mentre REST è uno stile API di altissimo livello (principalmente per servizi web e altri sistemi "live").

Il primo manipola i dati di base, l'altro interagisce con un sistema complesso.

Prima di tutto, entrambe sono semplicemente iniziali comuni; non hanno nulla di cui aver paura.

Ora, CRUD è un termine semplice che è stato abbreviato perché è una funzionalità comune in molte applicazioni ed è più facile dire CRUD . Descrive le 4 operazioni di base che è possibile eseguire sui dati (o su una risorsa). Crea, leggi, aggiorna, cancella.

REST tuttavia, è una pratica denominata (proprio come AJAX), non una tecnologia in sé. Incoraggia l'uso di funzionalità che sono state a lungo inerenti al protocollo HTTP, ma raramente utilizzate.

Quando si dispone di un URL (Uniform Resource Locator ) e si punta il browser ad esso dalla riga dell'indirizzo, si sta inviando una richiesta HTTP . Ogni richiesta HTTP contiene informazioni che il server può utilizzare per sapere quale risposta HTTP restituire al client che ha emesso la richiesta.

Ogni richiesta contiene un URL, quindi il server sa a quale risorsa si desidera accedere, ma può anche contenere un metodo . Un metodo descrive cosa fare con quella risorsa.

Ma questo concetto di "metodo" non è stato usato molto spesso.

Di solito, le persone collegano semplicemente alle pagine tramite il metodo GET ed emettono qualsiasi tipo di aggiornamento (eliminazioni, inserzioni, aggiornamenti) tramite il metodo POST.

E per questo motivo non è possibile trattare una risorsa (URL) come una vera risorsa in sé. È necessario disporre di URL separati per l'eliminazione, l'inserimento o l'aggiornamento della stessa risorsa. Per esempio:

http://...com/posts/create- POST request  -> Goes to posts.create() method in the server
http://...com/posts/1/show- GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1/delete - POST request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1/edit- POST request  -> Goes to posts.edit(1) method in the server

Con REST, crei moduli più intelligenti perché utilizzano altri metodi HTTP oltre a POST e programmano il tuo server per essere in grado di distinguere tra metodi , non solo URL. Quindi per esempio:

http://...com/posts - POST request  -> Goes to posts.create() method in the server
http://...com/posts/1 - GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1 - DELETE request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1 - PUT request  -> Goes to posts.edit(1) method in the server

Ricorda, un singolo URL descrive una singola risorsa. Un singolo post è una singola risorsa. Con REST trattate le risorse nel modo in cui dovevano essere trattate. Stai dicendo al server quale risorsa vuoi gestire e come gestirla.

Ci sono molte altre caratteristiche di "RESTful architecture", che puoi leggere su Wikipedia, altri articoli o libri, se sei interessato. D'altro canto, non c'è molto di più nel CRUD stesso.

REST sta per "trasferimento rappresentativo dello stato", il che significa che si tratta di comunicare e modificare lo stato di alcune risorse in un sistema.

REST è piuttosto coinvolto, perché la teoria alla base di REST si basa sull'utilizzo di media, hypermedia e un protocollo sottostante per gestire le informazioni su un sistema remoto.

CRUD, d'altra parte, è un mnemonico per le operazioni comuni necessarie per i dati in un database: Crea Recupera aggiornamento Elimina. Ma non è davvero più profondo di così.

Quindi questa è la risposta alla tua domanda, ma citerò l'errore comune che vedo quando REST e CRUD vengono discussi insieme. Molti sviluppatori vogliono mappare direttamente REST su CRUD, perché REST su HTTP prevede GET PUT POST e DELETE, mentre CRUD prevede CREATE RETRIEVE UPDATE DELETE. È naturale voler mappare i verbi REST direttamente alle operazioni CRUD.

Tuttavia, HTTP utilizza uno stile "crea o aggiorna", mentre CRUD separa creare e aggiornare. Ciò rende impossibile (!) Creare una mappatura pulita e generale tra i due (!)

GET e DELETE sono facili ... GET === RETRIEVE e DELETE === DELETE.

Ma secondo le specifiche HTTP, PUT è in realtà Crea E Aggiorna:

• Usa PUT per creare un oggetto nuovo di zecca quando ne conosci tutto, incluso il suo identificatore

• Usa PUT per aggiornare un oggetto (di solito con una rappresentazione completa dell'oggetto)

POST è il verbo "elaborazione" ed è considerato il verbo "append":

• Utilizzare POST per aggiungere un nuovo oggetto a una raccolta, ovvero creare un nuovo oggetto

• Il POST viene utilizzato anche quando nessuno degli altri verbi si adatta perfettamente, poiché la specifica HTTP lo definisce come il verbo "elaborazione dati"

• Se il tuo team si blocca su POST, ricorda che l'intero WWW è stato creato su GET e POST;)

Quindi, mentre c'è somiglianza tra REST e CRUD, l'errore che vedo fare la maggior parte dei team è quello di fare un'equivalenza tra i due. Un team deve davvero fare attenzione quando si definisce un'API REST per non rimanere troppo impiccato sul mnemonico CRUD, perché REST come pratica ha davvero molta complessità aggiuntiva che non è mappata in modo chiaro su CRUD.

CRUD specifica un set minimo di verbi di archiviazione di base per la lettura e la scrittura dei dati: crea, leggi, aggiorna ed elimina. Quindi, è possibile creare altre operazioni aggregandole. Queste sono generalmente considerate operazioni di database, ma ciò che è considerato un database è arbitrario (ad esempio, potrebbe essere un DBMS relazionale, ma potrebbe anche essere file YAML).

REST è uno "stile architettonico" che di solito include operazioni CRUD e altre operazioni di livello superiore, tutte da eseguire su alcuni concetti di "risorse" (arbitrari, ma si tratta di entità nell'applicazione). REST ha una serie di vincoli che lo rendono interessante (e particolarmente ben accoppiato con HTTP).

Un'interfaccia REST può, ma non è necessario, esporre tutte le operazioni CRUD su una particolare risorsa. Ciò che è disponibile in un'interfaccia REST è arbitrario e può cambiare a causa di autorizzazioni di sistema, considerazioni sull'interfaccia utente e quanto era caldo il giorno in cui l'interfaccia è stata progettata e creata. I giorni più caldi portano a interfacce più minimaliste, di solito, anche se può essere vero il contrario.

CRUD

• CRUD è di quattro tipi base di comandi SQL: Crea, Leggi, Aggiorna ed Elimina
• La maggior parte delle applicazioni ha una sorta di funzionalità CRUD
• Un'applicazione CRUD è quella che utilizza i moduli per ottenere dati da e verso un database

RIPOSO

• REST è l'acronimo di Representational State Transfer (talvolta è scritto "ReST")

• Si basa su un protocollo di comunicazione memorizzabile nella cache senza client, server-server e in quasi tutti i casi viene utilizzato il protocollo HTTP

• REST è uno stile di architettura per la progettazione di applicazioni in rete

REST è qualcosa di simile a una pagina Web per macchine che possono navigare, mentre CRUD è qualcosa come SOAP, che è fortemente accoppiato ai suoi clienti. Queste sono le principali differenze. Ofc. sono simili in superficie, ma CRUD descrive la manipolazione di entità di base, mentre REST può descrivere l'interfaccia di qualsiasi applicazione. Un'altra differenza che REST può utilizzare più i 4 metodi HTTP. Sarebbe una risposta molto lunga se volessi raccogliere tutte le differenze, se controlli le domande su REST vs SOAP, ne troverai la maggior parte.

Penso che confondere REST con CRUD sia un errore molto comune e la causa è che gli sviluppatori non hanno il tempo di leggere approfonditamente REST. Vogliono solo usare la tecnologia - senza capirla - basata su esempi di stile CRUD limitati scritti da sviluppatori simili. La stragrande maggioranza degli esempi e delle esercitazioni riflette una grave mancanza di conoscenza. Mappare risorse REST su entità e metodi HTTP su operazioni CRUD di queste entità e usare REST senza collegamenti ipertestuali è solo un sintomo di ciò. Tramite REST si mappano collegamenti ipertestuali (compresi i collegamenti con i metodi POST / PUT / DELETE / PATCH) alle proprie operazioni e si identifica l'operazione sul lato client controllando la relazione di collegamento (solitamente specifica dell'API). Se un client REST non sa cosa sia una relazione di collegamento e conosce solo i metodi HTTP e forse alcuni modelli URI, quindi quello non è un client REST, ma un CRUD su client HTTP. Un altro errore comune che un client REST è un'applicazione javascript a pagina singola in esecuzione nel browser. Ovviamente puoi implementare un tale client, ma REST era pensato principalmente per client automatici (applicazioni lato server scritte da sviluppatori che non conosci nemmeno) e non per client manuali (applicazioni browser controllate dall'utente scritte da te). Avere un solo client browser potrebbe essere un segno del fatto che non hai davvero bisogno di REST e hai semplicemente ingegnerizzato troppo il progetto. In questi casi un'API CRUD è una soluzione praticabile e gli sviluppatori chiamano queste API CRUD come REST, perché non conoscono la differenza. Ovviamente puoi implementare un tale client, ma REST era pensato principalmente per client automatici (applicazioni lato server scritte da sviluppatori che non conosci nemmeno) e non per client manuali (applicazioni browser controllate dall'utente scritte da te). Avere un solo client browser potrebbe essere un segno del fatto che non hai davvero bisogno di REST e hai semplicemente ingegnerizzato troppo il progetto. In questi casi un'API CRUD è una soluzione praticabile e gli sviluppatori chiamano queste API CRUD come REST, perché non conoscono la differenza. Ovviamente puoi implementare un tale client, ma REST era pensato principalmente per client automatici (applicazioni lato server scritte da sviluppatori che non conosci nemmeno) e non per client manuali (applicazioni browser controllate dall'utente scritte da te). Avere un solo client browser potrebbe essere un segno del fatto che non hai davvero bisogno di REST e hai semplicemente ingegnerizzato troppo il progetto. In questi casi un'API CRUD è una soluzione praticabile e gli sviluppatori chiamano queste API CRUD come REST, perché non conoscono la differenza.