Ho imparato REST e mi sembra molto simile a CRUD (da ciò che ho letto su CRUD).
So che sono diversi e mi chiedo se pensare di essere simili significa che non li capisco.
Il REST è un "superset" di CRUD? Fa tutto ciò che fa CRUD e altro?
Ho imparato REST e mi sembra molto simile a CRUD (da ciò che ho letto su CRUD).
So che sono diversi e mi chiedo se pensare di essere simili significa che non li capisco.
Il REST è un "superset" di CRUD? Fa tutto ciò che 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 si tratta solo di tabelle e record del database.
REST, d'altra parte, opera su rappresentazioni di risorse, ognuna identificata da un URL. Questi in genere non sono oggetti dati, ma complesse astrazioni di oggetti.
Ad esempio, una risorsa può essere un commento di un utente. Ciò significa non solo un record in una tabella "commenti", ma anche le sue relazioni con la risorsa "utente", il post a cui il commento è collegato, forse un altro commento a cui risponde.
Operare sul commento non è un'operazione di database primitiva, può avere effetti collaterali significativi, come sparare un avviso al poster originale, o ricalcolare alcuni "punti" simili a giochi, o aggiornare alcuni "follower".
Inoltre, una rappresentazione delle risorse include l'ipertesto (controlla il principio HATEOAS ), consentendo al progettista di esprimere relazioni tra risorse, o guida il client REST nel flusso di lavoro di un'operazione.
In breve, CRUD è una serie di operazioni primitive (principalmente per database e archivi di dati statici), mentre REST è uno stile di API di alto 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 caratteristica 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, elimina.
REST tuttavia, è una pratica chiamata (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.
Se disponi di un URL (Uniform Localizzatore risorse ) e indirizzi il browser su di esso tramite la riga dell'indirizzo, invierai una richiesta HTTP . Ogni richiesta HTTP contiene informazioni che il server può utilizzare per sapere quale risposta HTTP inviare al client che ha emesso la richiesta.
Ogni richiesta contiene un URL, quindi il server sa a quale risorsa vuoi 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.
Solitamente, le persone si limitano a collegarsi alle pagine tramite il metodo GET e rilasciano qualsiasi tipo di aggiornamento (eliminazioni, inserzioni, aggiornamenti) tramite il metodo POST.
E a causa di ciò non si poteva trattare una risorsa (URL) come una vera risorsa in sé. Dovevi avere URL separati per la cancellazione, l'inserimento o l'aggiornamento della stessa risorsa. Ad 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 in modo da poter 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 che un singolo URL descrive una singola risorsa. Un singolo post è una singola risorsa. Con REST trattate le risorse nel modo in cui sono state pensate per essere trattate. Stai dicendo al server quale risorsa vuoi gestire e come gestirla.
Ci sono molte altre caratteristiche di "architettura RESTful", che puoi leggere su Wikipedia, altri articoli o libri, se sei interessato. Non c'è molto di più per CRUD stesso, d'altra parte.
REST sta per "trasferimento dello stato di rappresentazione", 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 Elimina Elimina. Ma in realtà non c'è niente di più profondo.
Questa è la risposta alla tua domanda, ma citerò l'errore comune che vedo quando REST e CRUD sono discussi insieme. Molti sviluppatori vogliono mappare direttamente REST in CRUD, perché REST su HTTP fornisce GET POST POST e DELETE, mentre CRUD fornisce 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 crea e aggiorna. Ciò rende impossibile (!) Fare una mappatura generale pulita tra i due (!)
GET e DELETE sono facili ... GET === RECUPERA e CANCELLA === ELIMINA.
Ma secondo le specifiche HTTP, PUT è in realtà Crea e aggiorna:
Usa PUT per creare un oggetto nuovo di zecca quando sai tutto su di esso, incluso il suo identificatore
Usa PUT per aggiornare un oggetto (di solito con una rappresentazione completa dell'oggetto)
POST è il verbo "processing" ed è considerato il verbo "append":
Usa il POST per aggiungere un nuovo oggetto a una raccolta, ovvero crea un nuovo oggetto
Il POST viene anche usato quando nessuno degli altri verbi è abbastanza adatto, 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, anche se c'è somiglianza tra REST e CRUD, l'errore che vedo fare la maggior parte delle squadre è di fare un'equivalenza tra i due. Una squadra deve davvero stare attenta quando si definisce un'API REST per non rimanere appesa al mnemonico CRUD, perché REST come pratica ha davvero molta complessità aggiuntiva che non viene mappata in modo pulito in CRUD.
CRUD specifica un set minimo di verbi di archiviazione di base per la lettura e la scrittura di dati: creazione, lettura, aggiornamento ed eliminazione. Quindi, puoi costruire 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 un 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" (arbitrarie, ma queste sono entità nella tua applicazione). REST ha una serie di vincoli che lo rendono interessante (e particolarmente ben abbinato a HTTP).
Un'interfaccia REST può, ma non deve, esporre tutte le operazioni CRUD su una particolare risorsa. Ciò che è disponibile in un'interfaccia REST è arbitrario e potrebbe cambiare a causa delle autorizzazioni del sistema, delle considerazioni sull'interfaccia utente e di quanto fosse caldo il giorno in cui l'interfaccia è stata progettata e creata. Le giornate più calde portano a interfacce più minimaliste, di solito, anche se può essere vero il contrario.
CRUD
REST
REST sta per Representational State Transfer. (A volte viene scritto "ReST")
Si basa su un protocollo di comunicazione memorizzabile in cache, client-server e senza stato 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 come una pagina web per macchine, che possono sfogliare, mentre CRUD è qualcosa come SOAP, che è strongmente accoppiato ai suoi clienti. Queste sono le principali differenze. Ofc. sono simili in superficie, ma CRUD descrive la manipolazione delle 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, allora troverai la maggior parte di esse.
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 comprenderla - basata su esempi di stile CRUD limitati scritti da sviluppatori simili. La stragrande maggioranza degli esempi e dei tutorial riflette una grave mancanza di conoscenza. Mappare le risorse REST alle entità e ai metodi HTTP per le operazioni CRUD di queste entità e utilizzare REST senza collegamenti ipertestuali è solo un sintomo di ciò. Con REST si mappano i collegamenti ipertestuali (compresi i collegamenti con i metodi POST / PUT / DELETE / PATCH) alle 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 di URI, allora questo non è un client REST, ma un CRUD sul client HTTP. Un altro errore comune che un client REST è un'applicazione javascript a pagina singola in esecuzione nel browser. Naturalmente è possibile implementare un client di questo tipo, ma REST è stato pensato principalmente per i client automatici (applicazioni lato server scritte da sviluppatori che non si conoscono nemmeno) e non per client manuali (applicazioni browser controllate dall'utente scritte da voi). Avere un solo client browser potrebbe essere un segnale che non hai davvero bisogno di REST e hai appena sovrastato 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.