Ci sono sicuramente vantaggi / svantaggi nell'uso di JSON su REST rispetto al TCP / IP diretto con protocollo binario e penso che tu stia già sospettando che il protocollo binario sarà più veloce. Non posso dirti esattamente quanto più velocemente (e questo dipenderebbe da molti fattori), ma immagino che forse 1-2 ordini di differenza di grandezza.
A prima vista se qualcosa è 10-100 volte più lento di qualcos'altro, potresti avere una reazione istintiva e andare per "cosa veloce". Tuttavia, questa differenza di velocità è solo nel protocollo stesso. Se esiste l'accesso al database / ai file sul lato server, ciò non sarà influenzato dalla scelta del livello di trasferimento. In alcuni casi, la velocità del livello di trasferimento potrebbe essere molto meno significativa.
HTTP REST e JSON sono utili per una serie di motivi:
- sono facilmente consumabili da chiunque. Puoi scrivere la tua app Web, quindi girarti e pubblicare l'API per il resto del mondo. Ora chiunque può raggiungere gli stessi end-point e accedere ai tuoi servizi
- sono facilmente eseguibili il debug, puoi aprire uno sniffer di pacchetti o semplicemente scaricare le richieste in arrivo su file di testo e vedere cosa sta succedendo. Non puoi farlo con i protocolli binari
- sono facilmente estensibili. È possibile aggiungere più attributi e dati in un secondo momento e non interrompere la compatibilità con i vecchi client.
- consumabile dai client javascript (non sono sicuro che abbiano ancora il parser JS protobuf, non credo ce ne sia uno)
Protobuf su TCP / IP:
Se fosse stata una mia scelta, avrei preferito andare con HTTP REST e JSON. C'è una ragione per cui così tante altre aziende e siti web hanno intrapreso questa strada. Inoltre, tieni presente che in futuro potresti sempre supportare 2 punti finali. Se la progettazione è corretta, la scelta dell'endpoint deve essere completamente disaccoppiata dalla logica aziendale o dal database sul lato server. Quindi, se ti rendi conto in seguito che hai bisogno di più velocità per tutte / alcune richieste, dovresti essere in grado di aggiungere protobufs con il minimo sforzo. Tuttavia, REST / JSON ti farà decollare più rapidamente e ti farà avanzare.
Per quanto riguarda Netty vs Spring. Non ho usato Netty direttamente, ma credo che sia solo un server web leggero in cui Spring è un framework che offre molto di più per te. Ha livelli di accesso ai dati, pianificazione dei lavori in background e (credo) un modello MVC, quindi è molto più pesante. Quale scegliere? Se hai deciso di andare via HTTP, la prossima domanda è probabilmente quanto è standard la tua app? Se stai per scrivere una logica personalizzata folle che non si adatta allo stampo standard e tutto ciò che serve è solo un livello server HTTP, vai con Netty.
Tuttavia, sospetto che la tua app non sia così speciale e potrebbe probabilmente beneficiare di molte cose che Spring ha da offrire. Ciò significa che dovresti strutturare la tua app intorno al framework di Spring e fare le cose come si aspettano che tu faccia, il che significherebbe imparare di più su Spring prima di immergerti nel tuo prodotto. I telai in generale sono fantastici perché di nuovo ti fanno decollare più velocemente, ma il rovescio della medaglia è che devi adattarti al loro stampo invece di fare il tuo design e quindi aspettarti che la struttura funzioni.
(*) - in passato è stato sottolineato che i miei post non riflettono le opinioni di tutto il mondo, quindi vado sul disco e aggiungo solo che ho un'esperienza limitata con Netty (ho già usato Play framework prima che si basa su Netty) o Spring (ne ho solo letto). Quindi prendi quello che dico con un granello di sale.