REST vs RPC per lo sviluppo mobile

7

Come molti sanno, lo sviluppo mobile è alle stelle in questi giorni e, credo, influisce su ciò che codifichiamo. Per essere precisi, sono interessato allo sviluppo di servizi Web per un'applicazione mobile.

Vedo due possibili architetture: RPC e REST. Ho sviluppato entrambi i servizi REST e RPC e quello che ho osservato è che i servizi RPC sono molto più facili da codificare, specialmente in linguaggi come PHP. Il problema con esso sembra essere la scalabilità: il lato server può facilmente trasformarsi in un pasticcio quando sono presenti molte procedure.

REST, d'altro canto, sembra essere molto più strutturato, il lato server diventa relativamente facile da mantenere ma ha il potenziale di spezzare i dati in più risorse, il che è dannoso per le applicazioni mobili (per molteplici ragioni).

Da quanto ho sperimentato, RPC sembra un po 'meglio nella maggior parte dei casi:

  • Entrambi, lato client e lato server, sono interessati a ridurre al minimo il numero di procedure disponibili e le chiamate effettuate.
  • Le seguenti regole architettoniche non contrastano con le ottimizzazioni altrimenti possibili.

Non mi aspetto che qualcuno mi spieghi cosa sono REST e RPC, il web ne è pieno. Voglio che le persone che hanno esperienza nello sviluppo di app mobili esprimano le loro opinioni sull'utilizzo di queste due architetture sul lato server. I suggerimenti sono anche benvenuti (chi non ama i suggerimenti, eh?).

    
posta Pijusn 22.04.2013 - 19:39
fonte

2 risposte

5

C'è poca differenza, RPC tende ad essere più protocolli binari di REST, ma non deve essere così. Anche RPC tende ad essere implementato come un singolo punto di procedura per chiamata, ma anche in questo caso non è necessario: è possibile implementare una singola procedura RPC che accetta un verbo stile REST come primo argomento. RPC a volte ha un approccio semi / stateful, ma di nuovo non deve essere il caso se si passa un "cookie" ad ogni chiamata.

Al giorno d'oggi tutto si riduce al supporto dello sviluppo e ci sono più API REST per i linguaggi basati sul Web, e quindi le persone usano REST. Se stai considerando una visione di sviluppo più incentrata sull'utente, probabilmente starai meglio con un meccanismo RPC, sfruttando la flessibilità per fornire un protocollo binario più compresso, quindi implementarlo come preferisci: procedura singola che si dirige verso una routine basata su un id o 'verbo' ed è completamente senza stato passando un id. Tutto questo può essere implementato per sembrare molto simile a REST ma con un overhead significativamente inferiore.

Ci sono diversi sistemi RPC, prova i buffer dei protocolli o parsimonia per la tua app mobile.

    
risposta data 22.04.2013 - 20:09
fonte
4

Potresti dare un'occhiata a questo articolo di Netflix sulla loro riprogettazione dell'API: link

TL; DR:

  • REST in generale genera API chatty: se un'operazione richiede di manipolare più risorse, avrai bisogno di più chiamate (es. slow!)
  • Un'API non si adatta bene a consumatori diversi, motivo per cui Netflix sta spostando parte del codice client sul server: ogni utente può fornire il proprio livello adattatore / orchestrazione sul server per ottimizzare l'accesso API ai diversi consumatori.

Nota personale:

  • Si prega di non associare RPC con i protocolli obsoleti SOAP / CORBA / RMI di vecchia generazione. Ad esempio JSON-RPC è un protocollo molto semplice, elegante e agile per fare RPC che dovresti assolutamente prendere in considerazione.
  • REST è perfetto per le API CRUD. Tuttavia, se la tua API è molto orientata all'azione, potresti trovarla scomoda per mapparla su verbi / endpoint REST.
risposta data 13.09.2016 - 11:56
fonte

Leggi altre domande sui tag