REST vs JSON-RPC? [chiuso]

Sto cercando di scegliere tra REST e JSON-RPC per lo sviluppo di un'API per un'applicazione Web. Come si confrontano?

Aggiornamento 2015: ho scoperto che REST è più facile da sviluppare e utilizzare per un'API fornita su Web / HTTP, poiché l'API può sfruttare il protocollo HTTP esistente e maturo, compreso sia dal client che dal server. Ad esempio, l'API può utilizzare codici di risposta, intestazioni, query, corpi dei post, memorizzazione nella cache e molte altre funzioni senza alcuno sforzo o impostazione aggiuntiva.

Il problema fondamentale con RPC è l'accoppiamento. I client RPC sono strettamente associati all'implementazione del servizio in diversi modi e diventa molto difficile cambiare l'implementazione del servizio senza interrompere i client:

• I clienti sono tenuti a conoscere i nomi delle procedure;
• L'ordine dei parametri di procedura, i tipi e il conteggio contano. Non è così facile cambiare le firme delle procedure (numero di argomenti, ordine degli argomenti, tipi di argomenti ecc ...) sul lato server senza interrompere le implementazioni del client;
• Lo stile RPC non espone altro che endpoint di procedura + argomenti di procedura. È impossibile per il cliente determinare cosa si può fare dopo.

D'altra parte in stile REST è molto facile guidare i clienti includendo le informazioni di controllo nelle rappresentazioni (intestazioni HTTP + rappresentazione). Per esempio:

• È possibile (e in realtà obbligatorio) incorporare collegamenti annotati con tipi di relazioni di collegamento che trasmettano significati di questi URI;
• Le implementazioni del client non devono dipendere da particolari nomi e argomenti della procedura. Al contrario, i client dipendono dai formati dei messaggi. Ciò crea la possibilità di utilizzare librerie già implementate per particolari formati multimediali (ad esempio Atom, HTML, Collection + JSON, HAL ecc ...)
• È possibile modificare facilmente gli URI senza interrompere i client nella misura in cui dipendono solo da relazioni di collegamento registrate (o specifiche del dominio);
• È possibile incorporare strutture simili a forme nelle rappresentazioni, dando ai clienti la possibilità di esporre queste descrizioni come funzionalità dell'interfaccia utente se l'utente finale è umano;
• Il supporto per la memorizzazione nella cache è un ulteriore vantaggio;
• Codici di stato standardizzati;

Ci sono molte più differenze e vantaggi sul lato REST.

Ho esplorato il problema in dettaglio e ho deciso che il puro REST è troppo limitante, e RPC è il migliore, anche se la maggior parte delle mie app sono app CRUD. Se ti attieni a REST, alla fine ti gratterai la testa chiedendoti come puoi facilmente aggiungere un altro metodo necessario alla tua API per uno scopo speciale. In molti casi, l'unico modo per farlo con REST è creare un altro controller per questo, il che potrebbe complicare indebitamente il programma.

Se decidi su RPC, l'unica differenza è che stai specificando esplicitamente il verbo come parte dell'URI, che è chiaro, coerente, meno difettoso e davvero nessun problema. Soprattutto se crei un'app che va ben oltre il semplice CRUD, RPC è l'unica strada da percorrere. Ho un altro problema con i puristi RESTful: HTTP POST, GET, PUT, DELETE hanno significati definiti in HTTP che sono stati sovvertiti da REST nel significato di altre cose, semplicemente perché si adattano la maggior parte del tempo, ma non tutte le volte.

Nella programmazione, ho scoperto da tempo che provare a usare una cosa per significare due cose qualche volta verrà in giro e ti morderà. Mi piace avere la possibilità di utilizzare POST per quasi tutte le azioni, perché offre la libertà di inviare e ricevere dati come il tuo metodo deve fare. Non puoi adattare il mondo intero a CRUD.

Innanzitutto, HTTP-REST è un'architettura di "trasferimento rappresentativo dello stato". Ciò implica molte cose interessanti:

• La tua API sarà senza stato e quindi molto più facile da progettare (è davvero facile dimenticare una transizione in un automa complesso) e integrarsi con parti di software indipendenti.
• Sarai guidato a progettare metodi di lettura come sicuri , che saranno facili da memorizzare nella cache e da integrare.
• Sarai guidato a progettare metodi di scrittura come metodi idempotenti , che gestiranno molto meglio i timeout.

Secondo, HTTP-REST è pienamente conforme a HTTP (vedi "sicuro" e "idempotente" nella parte precedente), quindi sarai in grado di riutilizzare le librerie HTTP (esistenti per ogni lingua esistente) e i proxy inversi HTTP, che ti daranno la capacità di implementare funzionalità avanzate (cache, autenticazione, compressione, reindirizzamento, riscrittura, registrazione, ecc.) con zero righe di codice.

Ultimo ma non meno importante, l'utilizzo di HTTP come protocollo RPC è un grosso errore secondo il progettista di HTTP 1.1 (e inventore di REST): http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation. htm # sec_6_5_2

Grandi risposte - volevo solo chiarire alcuni dei commenti. JSON-RPC è veloce e facile da consumare, ma come detto risorse e parametri sono strettamente accoppiati e tende a fare affidamento sui verbi (api / deleteUser, api / addUser) utilizzando GET / POST dove -come REST fornisce risorse accoppiate liberamente (api / utenti) che in un'API REST HTTP si basano su diversi metodi HTTP (GET, POST, PUT, PATCH, DELETE). REST è leggermente più difficile da implementare per gli sviluppatori inesperti, ma lo stile è diventato un luogo abbastanza comune ora e offre molta più flessibilità a lungo termine (dando alla tua API una vita più lunga).

Oltre a non avere risorse strettamente accoppiate, REST ti consente anche di evitare di impegnarti in un singolo tipo di contenuto, questo significa che se il tuo cliente deve ricevere i dati in XML, o JSON o persino YAML, se integrato nel tuo sistema potresti restituisce uno di quelli che usano le intestazioni content-type / accetta.

Ciò ti consente di mantenere l'API abbastanza flessibile da supportare nuovi tipi di contenuto O requisiti del client.

Ma ciò che veramente separa REST da JSON-RPC è che segue una serie di vincoli attentamente studiati, garantendo flessibilità architettonica. Questi vincoli includono la garanzia che il client e il server siano in grado di evolversi indipendentemente l'uno dall'altro (è possibile apportare modifiche senza incasinare l'applicazione del client), le chiamate sono apolidi (lo stato è rappresentato tramite hypermedia), viene fornita un'interfaccia uniforme per le interazioni, l'API è sviluppata su un sistema a più livelli e la risposta è memorizzabile nella cache dal client. C'è anche un vincolo opzionale per fornire il codice su richiesta.

Tuttavia, con tutto ciò detto, la maggior parte delle API non sono RESTful (secondo Fielding) in quanto non incorporano hypermedia (collegamenti ipertestuali incorporati nella risposta che aiutano a navigare nell'API). La maggior parte delle API scoprirai che sono simili a REST in quanto seguono la maggior parte dei concetti di REST, ma ignorano questo vincolo. Tuttavia, sempre più API lo stanno implementando e sta diventando sempre più una pratica di flusso principale.

Questo ti dà anche una certa flessibilità poiché le API guidate dall'hypermedia (come Stormpath) indirizzano il client agli URI (il che significa che se qualcosa cambia, in alcuni casi puoi modificare l'URI senza impatto negativo), dove -come con gli URI RPC è necessario statico. Con RPC, dovrai anche documentare ampiamente questi diversi URI e spiegare come funzionano l'uno rispetto all'altro.

In generale, direi che REST è la strada da percorrere se vuoi costruire un'API estensibile e flessibile che durerà a lungo. Per questo motivo, direi che è la strada da percorrere per il 99% delle volte.

Buona fortuna, Mike

IMO, il punto chiave è l'azione rispetto all'orientamento delle risorse. REST è orientato alle risorse e si adatta bene alle operazioni CRUD e, data la sua semantica nota, fornisce una certa prevedibilità a un primo utente, ma quando implementato da metodi o procedure ti costringe a fornire una traduzione artificiale al mondo incentrato sulle risorse. D'altra parte RPC si adatta perfettamente alle API orientate all'azione, in cui si espongono servizi, non insiemi di risorse compatibili con CRUD.

Senza dubbio REST è più popolare, questo sicuramente aggiunge alcuni punti se si desidera esporre l'API a terzi.

In caso contrario (ad esempio in caso di creazione di un front-end AJAX in una SPA), la mia scelta è RPC. In particolare JSON-RPC, combinato con JSON Schema come linguaggio di descrizione, e trasportato su HTTP o Websocket a seconda del caso d'uso.

JSON-RPC è una specifica semplice ed elegante che definisce i payload JSON di richiesta e risposta da utilizzare in RPC sincrono o asincrono.

JSON Schema è una bozza di specifica che definisce un formato basato su JSON volto a descrivere i dati JSON. Descrivendo i messaggi di input e output del servizio utilizzando JSON Schema è possibile avere una complessità arbitraria nella struttura dei messaggi senza compromettere l'usabilità e l'integrazione del servizio può essere automatizzata.

La scelta del protocollo di trasporto (HTTP vs websocket) dipende da diversi fattori, essendo il più importante se sono necessarie funzionalità HTTP (memorizzazione nella cache, riconvalida, sicurezza, idempotenza, tipo di contenuto, multipart, ...) o se l'applicazione deve scambiare messaggi ad alto rendimento.

Fino ad ora è la mia opinione personale sulla questione, ma ora qualcosa che può essere davvero utile per quegli sviluppatori Java che leggono queste righe, il framework su cui ho lavorato durante l'ultimo anno, nato dalla stessa domanda che ti stai ponendo ora :

http://rpc.brutusin.org

Puoi vedere una demo live qui, che mostra il browser del repository integrato per i test funzionali (grazie allo schema JSON) e una serie di servizi di esempio:

http://demo.rpc.brutusin.org

Spero che aiuti l'accoppiamento!

Nacho

Se il servizio funziona bene solo con i modelli e il modello GET / POST / PUT / DELETE, utilizzare REST puro.

Sono d'accordo che HTTP è originariamente progettato per applicazioni senza stato.

Ma per le applicazioni moderne, più complesse (!) In tempo reale (web) in cui vorrai usare Websocket (che spesso implicano statualità), perché non usare entrambe? JSON-RPC su Websocket è molto leggero, quindi hai i seguenti vantaggi:

• Aggiornamenti istantanei su ogni client (definire la propria chiamata RPC da server a client per l'aggiornamento dei modelli)
• Facile da aggiungere complessità (prova a fare un clone Etherpad con solo REST)
• Se lo fai nel modo giusto (aggiungi RPC solo come extra per il tempo reale), la maggior parte è ancora utilizzabile con solo REST (tranne se la funzione principale è una chat o qualcosa del genere)

Poiché si sta progettando solo l'API lato server, iniziare con la definizione dei modelli REST e successivamente aggiungere il supporto JSON-RPC in base alle esigenze, mantenendo il numero minimo di chiamate RPC.

(e scusate per l'abuso di parentesi)

Sono stato un grande fan di REST in passato e ha molti vantaggi rispetto a RPC su carta. È possibile presentare al client diversi tipi di contenuto, memorizzazione nella cache, riutilizzo dei codici di stato HTTP, guidare il client attraverso l'API e incorporare la documentazione nell'API se non si spiega in gran parte comunque.

Ma la mia esperienza è stata che in pratica questo non regge e invece fai molto lavoro inutile per ottenere tutto nel modo giusto. Inoltre, i codici di stato HTTP spesso non si associano esattamente alla logica del tuo dominio e il loro utilizzo nel tuo contesto spesso sembra un po 'forzato. Ma la cosa peggiore di REST secondo me è che spendi molto tempo per progettare le tue risorse e le interazioni che consentono. E ogni volta che fai alcune importanti aggiunte alla tua API, speri di trovare una buona soluzione per aggiungere le nuove funzionalità e non ti sei già progettato in un angolo.

Questo mi sembra spesso una perdita di tempo perché la maggior parte delle volte ho già un'idea perfettamente chiara e ovvia su come modellare un'API come una serie di chiamate di procedure remote. E se ho fatto tutto questo sforzo per modellare il mio problema all'interno dei vincoli di REST, il problema successivo è come chiamarlo dal client? I nostri programmi si basano su procedure di chiamata, quindi la creazione di una buona libreria client RPC è semplice, la creazione di una buona libreria client REST non è così tanto e nella maggior parte dei casi ti limiterai a mappare dall'API REST sul server a una serie di procedure nel tuo client biblioteca.

Per questo motivo, oggi RPC mi sembra molto più semplice e naturale. Quello che mi manca davvero è un framework coerente che semplifica la scrittura di servizi RPC auto-descrittivi e interoperabili. Pertanto ho creato il mio progetto per sperimentare nuovi modi per rendere RPC più semplice per me e forse anche qualcun altro lo trova utile: https://github.com/aheck/reflectrpc

Secondo il modello di maturità di Richardson , la domanda non è REST vs. RPC , ma quanto REST ?

In questa prospettiva, la conformità allo standard REST può essere classificata in 4 livelli.

• livello 0: pensare in termini di azioni e parametri. Come spiega l'articolo, questo è essenzialmente equivalente a JSON-RPC (l'articolo lo spiega per XML-RPC, ma gli stessi argomenti valgono per entrambi).
• livello 1: pensare in termini di risorse. Tutto ciò che è rilevante per una risorsa appartiene allo stesso URL
• livello 2: utilizzare i verbi HTTP
• livello 3: HATEOAS

Secondo il creatore dello standard REST, solo i servizi di livello 3 possono essere chiamati RESTful. Tuttavia, questa è una metrica di conformità , non di qualità. Se si desidera semplicemente chiamare una funzione remota che esegue un calcolo, probabilmente non ha senso avere collegamenti hypermedia pertinenti nella risposta, né differenziazione del comportamento basata sul verbo HTTP utilizzato. Quindi, tale chiamata tende intrinsecamente ad essere più simile a RPC. Tuttavia, un livello di conformità inferiore non significa necessariamente statualità o maggiore accoppiamento. Probabilmente, invece di pensare a REST vs. RPC , dovresti usare più REST possibile, ma non di più. Non torcere la tua applicazione solo per adattarla agli standard di conformità RESTful.

Perché JSON RPC:

In caso di API REST, dobbiamo definire un controller per ogni funzionalità / metodo di cui potremmo aver bisogno. Di conseguenza, se abbiamo 10 metodi che vogliamo accessibili a un client, dobbiamo scrivere 10 controller per interfacciare la richiesta del client a un metodo particolare.

Un altro fattore è, anche se abbiamo controller diversi per ciascun metodo / funzionalità, il client deve ricordare se utilizzare POST o GET. Questo complica ulteriormente le cose. Inoltre, per inviare i dati, è necessario impostare il tipo di contenuto della richiesta se si utilizza POST.

Nel caso di JSON RPC, le cose sono notevolmente semplificate perché la maggior parte dei server JSONRPC funzionano con metodi POST HTTP e il tipo di contenuto è sempre application / json. Ciò toglie il carico di ricordare di utilizzare il metodo HTTP corretto e le impostazioni del contenuto sul lato client.

Non è necessario creare controller separati per diversi metodi / funzionalità che il server vuole esporre a un client.

Perché RESTO:

Hai URL separati per diverse funzionalità che il server vuole esporre sul lato client. Di conseguenza, puoi incorporare questi URL.

La maggior parte di questi punti sono discutibili e dipendono completamente dal bisogno di una persona.

Penso, come sempre, dipende ...

REST ha l'enorme vantaggio di un ampio supporto pubblico e questo significa molti strumenti e libri. Se devi creare un'API utilizzata da un gran numero di consumatori di diverse organizzazioni, è la strada da percorrere per un solo motivo: è popolare. Come protocollo è ovviamente un fallimento totale poiché ci sono troppi modi completamente diversi di associare un comando a un URL / verbo / risposta.

Pertanto, quando scrivi un'app Web a pagina singola che deve parlare con un backend, penso che REST sia troppo complesso. In questa situazione non devi preoccuparti della compatibilità a lungo termine poiché l'app e l'API possono evolversi insieme.

Una volta ho iniziato con REST per un'app Web a pagina singola, ma i comandi precisi tra l'app Web e il server mi hanno fatto impazzire rapidamente. Devo codificarlo come parametro di percorso? Nel corpo? Un parametro di query? Un'intestazione? Dopo aver progettato l'URL / Verb / Response, ho dovuto codificare questo pasticcio in Javascript, il decodificatore in Java e quindi chiamare il metodo effettivo. Sebbene ci siano molti strumenti per farlo, è davvero difficile non ottenere alcuna semantica HTTP nel tuo codice di dominio, il che è davvero una cattiva pratica. (Coesione)

Prova a creare un file Swagger / OpenAPI per un sito medio complesso e confrontalo con una singola interfaccia Java che descriva le procedure remote in quel file. L'aumento della complessità è sbalorditivo.

Sono quindi passato da REST a JSON-RPC per la webapp a pagina singola. aI ho sviluppato una piccola libreria che codificava un'interfaccia Java sul server e la inviava al browser. Nel browser questo ha creato un proxy per il codice dell'applicazione che ha restituito una promessa per ciascuna funzione.

Ancora una volta, REST ha il suo posto solo perché è famoso e quindi ben supportato. È anche importante riconoscere la filosofia delle risorse apolidi e il modello gerarchico sottostanti. Tuttavia, questi principi possono essere altrettanto facilmente utilizzati in un modello RPC. JSON RPC funziona su HTTP, quindi presenta gli stessi vantaggi di REST in quest'area. La differenza è che quando inevitabilmente ti imbatti in queste funzioni che non corrispondono bene a questi principi non sei costretto a fare molto lavoro inutile.

REST è strettamente associato a HTTP, quindi se si espone l'API solo su HTTP, REST è più appropriato per la maggior parte (ma non tutte) le situazioni. Tuttavia, se è necessario esporre l'API su altri trasporti come messaggistica o socket Web, REST non è applicabile.

Sarebbe meglio scegliere JSON-RPC tra REST e JSON-RPC per sviluppare un'API per un'applicazione Web più facile da capire. JSON-RPC è preferito perché la sua mappatura su chiamate e comunicazioni di metodi può essere facilmente compresa.

La scelta dell'approccio più adatto dipende dai vincoli o dall'obiettivo principale. Ad esempio, per quanto riguarda le prestazioni è una caratteristica importante, è consigliabile scegliere JSON-RPC (ad esempio, High Performance Computing). Tuttavia, se l'obiettivo principale è quello di essere agnostici al fine di offrire un'interfaccia generica da dedurre da altri, è consigliabile optare per il REST. Se è necessario raggiungere entrambi gli obiettivi, è consigliabile includere entrambi i protocolli.

Il fatto che divide effettivamente REST da JSON-RPC è che segue una serie di vincoli attentamente pensati che confermano la flessibilità architettonica. I vincoli assumono nel garantire che il client e il server siano in grado di crescere indipendentemente l'uno dall'altro (le modifiche possono essere apportate senza interferire con l'applicazione del client), le chiamate sono apolidi (lo stato è considerato ipermediale), un'uniforme l'interfaccia è offerta per le interazioni, l'API è avanzata su un sistema a strati (Hall, 2010). JSON-RPC è rapido e facile da consumare, tuttavia, poiché le risorse menzionate e i parametri sono strettamente accoppiati e probabilmente dipenderà dai verbi (api / addUser, api / deleteUser) utilizzando GET / POST mentre REST offre risorse vagamente accoppiate (api / utenti) in un HTTP. L'API REST dipende da diversi metodi HTTP come GET, PUT, POST, DELETE, PATCH.

JSON (indicato come JavaScript Object Notation) essendo un formato di interscambio di dati leggero, è facile da leggere e da scrivere per gli umani. È facile per le macchine analizzare e generare. JSON è un formato di testo che è completamente indipendente dalla lingua ma pratica convenzioni che sono familiari ai programmatori della famiglia di lingue, costituite da C #, C, C ++, Java, Perl, JavaScript, Python e numerosi altri. Tali proprietà rendono JSON un linguaggio di scambio dati perfetto e una scelta migliore da optare.

Domanda sbagliata: impone un manichean che non esiste!

È possibile utilizzare JSON-RPC con "meno verbo" (nessun metodo ) e preservare la standardizzazione minima necessaria per ID sendo, parametri, codici di errore e messaggi di avviso . Lo standard JSON-RPC non dice "non puoi essere REST", ma solo come impacchettare le informazioni di base.

"REST JSON-RPC" esiste ! è REST con "best practice", per un minimo imballaggio delle informazioni, con contratti semplici e solidi.

Esempio

(da questa risposta e contesto didattico)

Quando si ha a che fare con REST, generalmente aiuta iniziare pensando in termini di risorse. In questo caso, la risorsa non è solo "conto bancario" ma è una transazione di quel conto bancario ... Ma JSON-RPC non obbliga il parametro "metodo", tutti sono codificati dal "percorso" dell'endpoint.

• REST Deposito con POST /Bank/Account/John/Transactionrichiesta JSON {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}.
  La risposta JSON può essere qualcosa di simile{"jsonrpc": "2.0", "result": "sucess", "id": 12}

• REST Prelevare con POST /Bank/Account/John/Transaction... simile.

• ... GET /Bank/Account/John/Transaction/12345@13... Ciò potrebbe restituire un record JSON di quella transazione esatta (ad esempio, i tuoi utenti in genere desiderano un record di debiti e crediti sul proprio account). Qualcosa come {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. La convenzione sulla richiesta (REST) ​​GET può includere la codifica dell'id con "@id", quindi non è necessario inviare alcun JSON, ma comunque utilizzare JSON-RPC nel pacchetto di risposta.

Se richiedi risorse, l'API RESTful è migliore in base alla progettazione. Se richiedi alcuni dati complicati con molti parametri e metodi complicati diversi dal semplice CRUD, allora RPC è la strada giusta da percorrere.

Uso vdata per il protocollo RPC: http://vdata.dekuan.org/

1, PHP e JavaScript sono entrambi a posto. 2, la chiamata di condivisione delle risorse tra le origini (CORS) è ancora a posto.