Ho un servizio web che accetta parametri JSON e ho URL specifici per metodi, ad esempio:
http://IP:PORT/API/getAllData?p={JSON}
Questo non è sicuramente REST in quanto non è apolide. Prende in considerazione i cookie e ha una propria sessione.
È RPC? Qual è la differenza tra RPC e REST?
Risposte:
Non puoi fare una netta separazione tra REST o RPC semplicemente guardando ciò che hai pubblicato.
Un vincolo di REST è che deve essere senza stato. Se hai una sessione, hai lo stato, quindi non puoi chiamare il tuo servizio RESTful.
Il fatto che tu abbia un'azione nel tuo URL (cioè getAllData) è un'indicazione verso RPC. In REST si scambiano le rappresentazioni e l'operazione che si esegue è dettata dai verbi HTTP. Inoltre, in REST, la negoziazione del contenuto non viene eseguita con un file?p={JSON} parametro.
Non so se il tuo servizio è RPC, ma non è RESTful. Puoi conoscere la differenza online, ecco un articolo per iniziare: Sfatare i miti di RPC e REST . Conosci meglio cosa c'è all'interno del tuo servizio, quindi confronta le sue funzioni con ciò che è RPC e trai le tue conclusioni.
Considera il seguente esempio di API HTTP che modellano gli ordini effettuati in un ristorante.
Effettuare un ordine:
Recupero di un ordine:
Aggiornamento di un ordine:
Esempio tratto da sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc
Come altri hanno già detto, una differenza fondamentale è che REST è incentrato sui nomi e RPC è incentrato sui verbi. Volevo solo includere questa chiara tabella di esempi che dimostrano che:
--------------------------- + ---------------------- --------------- + -------------------------- Operazione | RPC (operazione) | REST (risorsa) --------------------------- + ---------------------- --------------- + -------------------------- Iscriviti | POST / registrazione | POST / persone --------------------------- + ---------------------- --------------- + -------------------------- Dimissioni | POST / dimettersi | CANCELLA / persone / 1234 --------------------------- + ---------------------- --------------- + -------------------------- Leggi persona | GET / readPerson? Personid = 1234 | GET / persone / 1234 --------------------------- + ---------------------- --------------- + -------------------------- Leggere l'elenco degli elementi della persona | GET / readUsersItemsList? Userid = 1234 | GET / persone / 1234 / articoli --------------------------- + ---------------------- --------------- + -------------------------- Aggiungi elemento all'elenco delle persone | POST / addItemToUsersItemsList | POST / persone / 1234 / articoli --------------------------- + ---------------------- --------------- + -------------------------- Aggiorna articolo | POST / modifyItem | PUT / articoli / 456 --------------------------- + ---------------------- --------------- + -------------------------- Elimina elemento | POST / removeItem? ItemId = 456 | CANCELLA / articoli / 456 --------------------------- + ---------------------- --------------- + --------------------------
Appunti
GET /persons/1234), mentre RPC tende a utilizzare parametri di query per gli input delle funzioni GET /readPerson?personid=1234).GET /persons?height=tall).POST /signupo POST /persons, si includono dati che descrivono la nuova persona).È RPC che utilizza http . Una corretta implementazione di REST dovrebbe essere diversa da RPC. Avere una logica per elaborare i dati, come un metodo / funzione, è RPC. getAllData () è un metodo intelligente. REST non può avere intelligenza, dovrebbero essere dati di dumping che possono essere interrogati da un'intelligenza esterna .
La maggior parte delle implementazioni che ho visto in questi giorni sono RPC, ma molti la chiamano erroneamente REST. REST con HTTP è il salvatore e SOAP con XML il cattivo. Quindi la tua confusione è giustificata e hai ragione, non è RIPOSO.
Il protocollo HTTP non esegue un'implementazione di REST. Sia REST (GET, POST, PUT, PATCH, DELETE) che RPC (GET + POST) possono essere sviluppati tramite HTTP (ad esempio: tramite un progetto API web in visual studio).
Bene, ma allora cos'è REST? Il modello di maturità di Richardson è riportato di seguito (riepilogato). Solo il livello 3 è RIPOSO.
ad esempio: livello 3 (HATEOAS):
Il collegamento afferma che questo oggetto può essere aggiornato in questo modo e aggiunto in questo modo.
Link afferma che questo oggetto può essere letto solo ed è così che lo facciamo.
Chiaramente, l'invio di dati non è sufficiente per diventare REST, ma va menzionato anche come interrogare i dati. Ma poi di nuovo, perché i 4 passaggi? Perché non può essere solo il passaggio 4 e chiamarlo REST? Richardson ci ha appena fornito un approccio graduale per arrivarci, tutto qui.
Hai costruito siti web che possono essere usati dagli esseri umani. Ma puoi anche costruire siti web utilizzabili dalle macchine? È qui che risiede il futuro e RESTful Web Services mostra come farlo.
PS: REST è molto popolare così come i test automatici, ma quando si tratta di esempi del mondo reale ... beh ..
REST è descritto al meglio per lavorare con le risorse, mentre RPC è più incentrato sulle azioni.
REST sta per Representational State Transfer. È un modo semplice per organizzare le interazioni tra sistemi indipendenti. Le applicazioni RESTful utilizzano comunemente richieste HTTP per inviare dati (creare e / o aggiornare), leggere dati (ad esempio, eseguire query) ed eliminare dati. Pertanto, REST può utilizzare HTTP per tutte e quattro le operazioni CRUD (Crea / Leggi / Aggiorna / Elimina).
RPC è fondamentalmente utilizzato per comunicare tra i diversi moduli per soddisfare le richieste degli utenti. Ad esempio, in openstack come il modo in cui nova, glance e neutron lavorano insieme all'avvio di una macchina virtuale.
Direi così:
La mia entità detiene / possiede i dati? Quindi RPC: ecco una copia di alcuni dei miei dati, manipola la copia dei dati che ti mando e restituiscimi una copia del tuo risultato.
L'entità chiamata detiene / possiede i dati? Quindi REST: o (1) mostrami una copia di alcuni dei tuoi dati o (2) manipola alcuni dei tuoi dati.
In definitiva si tratta di quale "lato" dell'azione possiede / detiene i dati. E sì, puoi usare la verbosità REST per parlare con un sistema basato su RPC, ma continuerai a svolgere attività RPC quando lo fai.
Esempio 1: ho un oggetto che sta comunicando a un archivio di database relazionale (o qualsiasi altro tipo di archivio dati) tramite un DAO. Ha senso utilizzare lo stile REST per l'interazione tra il mio oggetto e l'oggetto di accesso ai dati che può esistere come API. La mia entità non possiede / detiene i dati, il database relazionale (o l'archivio dati non relazionale) lo fa.
Esempio 2: devo fare molti calcoli complessi. Non voglio caricare un mucchio di metodi matematici nel mio oggetto, voglio solo passare alcuni valori a qualcos'altro che può fare tutti i tipi di matematica e ottenere un risultato. Quindi lo stile RPC ha senso, perché l'oggetto / entità matematico esporrà al mio oggetto un intero gruppo di operazioni. Nota che questi metodi potrebbero essere tutti esposti come API individuali e potrei chiamarli con GET. Posso anche affermare che questo è RESTful perché sto chiamando tramite HTTP GET ma in realtà sotto le coperte è RPC. La mia entità possiede / detiene i dati, l'entità remota sta solo eseguendo manipolazioni sulle copie dei dati che le ho inviato.
Ci sono un sacco di buone risposte qui. Vorrei comunque rimandarti a questo blog di Google in quanto fa un ottimo lavoro nel discutere le differenze tra RPC e REST e cattura qualcosa che non ho letto in nessuna delle risposte qui.
Vorrei citare un paragrafo dallo stesso collegamento che mi ha colpito:
REST stesso è una descrizione dei principi di progettazione che sono alla base di HTTP e del world-wide web. Ma poiché HTTP è l'unica API REST commercialmente importante, possiamo per lo più evitare di discutere di REST e concentrarci solo su HTTP. Questa sostituzione è utile perché c'è molta confusione e variabilità in ciò che la gente pensa che REST significhi nel contesto delle API, ma c'è molta più chiarezza e accordo su cosa sia HTTP stesso. Il modello HTTP è il perfetto inverso del modello RPC: nel modello RPC, le unità indirizzabili sono procedure e le entità del dominio del problema sono nascoste dietro le procedure. Nel modello HTTP, le unità indirizzabili sono le entità stesse ei comportamenti del sistema sono nascosti dietro le entità come effetti collaterali della loro creazione, aggiornamento o eliminazione.
Ecco come li capisco e li uso in diversi casi d'uso:
Esempio: gestione del ristorante
caso d'uso per REST : gestione degli ordini
- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123
Per la gestione delle risorse, REST è pulito. Un endpoint con azioni predefinite. Può essere visto come un modo per esporre un DB (Sql o NoSql) o istanze di classe al mondo.
Esempio di implementazione:
class order:
on_get(self, req, resp): doThis.
on_patch(self, req, resp): doThat.
Esempio di framework: Falcon per python.
caso d'uso per RPC : gestione delle operazioni
- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123
Per lavori analitici, operativi, non reattivi, non rappresentativi e basati sull'azione, RPC funziona meglio ed è molto naturale pensare funzionale.
Esempio di implementazione:
@route('/operation/cook/<orderId>')
def cook(orderId): doThis.
@route('/operation/serve/<orderId>')
def serve(orderId): doThat.
Esempio di framework: Flask per python