Ci sono sicuramente pro / contro sull'uso di JSON su REST rispetto a quello su TCP / IP con protocollo binario e penso che tu stia già sospettando che il protocollo binario sarà più veloce. Non posso dirvi esattamente quanto più veloce (e questo dipenderebbe da molti fattori), ma suppongo che forse 1-2 ordini 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 c'è accesso al database / file sul lato server, questo non sarà influenzato dalla scelta del livello di trasferimento. In alcuni casi, potrebbe rendere la tua velocità di trasferimento molto meno significativa.
HTTP REST e JSON sono validi per una serie di motivi:
- sono facilmente consumabili da chiunque. Puoi scrivere la tua app Web, quindi tornare indietro e pubblicare la tua API per il resto del mondo da utilizzare. Ora chiunque può raggiungere gli stessi end-point e accedere ai tuoi servizi
- sono facilmente debuggabili, è possibile aprire uno sniffer di pacchetti o semplicemente scaricare le richieste in arrivo in file di testo e vedere cosa sta succedendo. Non puoi farlo con i protocolli binari
- sono facilmente estensibili. Puoi aggiungere più attributi e dati in un secondo momento e non rompere la compatibilità con i vecchi client.
- consumabile dai client javascript (non sono sicuro che abbiano ancora un parser JS protobuf, non credo che ce ne sia uno)
Protobuf su TCP / IP:
Se fosse la mia scelta, mi piacerebbe andare giù con HTTP REST e JSON. C'è una ragione per cui così tante altre società e siti web hanno seguito questa strada. Inoltre, tieni presente che in futuro potresti sempre supportare 2 punti finali. Se il progetto è corretto, la scelta del punto finale dovrebbe essere completamente disaccoppiata dalla logica aziendale sul server o dal database. 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à partire più velocemente e ti spingerà oltre.
Per quanto riguarda Netty vs Spring. Non ho usato Netty direttamente, ma credo che sia solo un server web leggero dove Spring è un framework che fornisce molto di più per te rispetto a quello. Ha livelli di accesso ai dati, pianificazione dei lavori in background e (penso) un modello MVC, quindi è molto più pesante. Quale scegliere? Se hai deciso di andare via HTTP, la prossima domanda è probabilmente come è standard la tua app? Se stai per scrivere una logica pazza personalizzata che non si adatta allo stampo standard e tutto ciò di cui hai bisogno è solo un livello server HTTP, vai con Netty.
Tuttavia, sospetto che l'app non sia così speciale e che probabilmente potrebbe 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 nel modo in cui si aspettano che tu faccia, il che significherebbe imparare di più su Spring prima di immergerti nel tuo prodotto. I framework in generale sono grandiosi perché di nuovo ti fanno decollare più velocemente, ma il rovescio della medaglia è che devi inserirli nello stampo invece di fare il tuo design e quindi aspettarti che il framework 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 usato Play framework prima di cui è basato su Netty) o Spring (ne ho solo letto). Quindi prendi quello che dico con un pizzico di sale.