Il y a certainement des avantages / inconvénients à utiliser JSON sur REST par rapport à TCP / IP direct avec un protocole binaire et je pense que vous soupçonnez déjà que le protocole binaire sera plus rapide. Je ne peux pas vous dire exactement combien de temps (et cela dépendrait de beaucoup de facteurs), mais je suppose que peut-être 1-2 ordres de différence de grandeur.
À première vue, si quelque chose est 10 à 100 fois plus lent que quelque chose d'autre, vous pourriez avoir une réaction instinctive et opter pour «chose rapide». Cependant, cette différence de vitesse ne concerne que le protocole lui-même. S'il y a un accès à la base de données / fichiers du côté serveur, cela ne sera pas affecté par votre choix de la couche de transfert. Dans certains cas, cela peut rendre la vitesse de votre couche de transfert beaucoup moins importante.
HTTP REST et JSON sont bons pour plusieurs raisons:
- ils sont facilement consommables par n'importe qui. Vous pouvez écrire votre application Web, puis faire demi-tour et publier votre API pour le reste du monde à utiliser. Maintenant, n'importe qui peut atteindre les mêmes points finaux et accéder à vos services
- ils sont facilement déboggables, vous pouvez ouvrir un renifleur de paquets ou simplement vider les demandes entrantes dans des fichiers texte et voir ce qui se passe. Vous ne pouvez pas faire ça avec des protocoles binaires
- ils sont facilement extensibles. Vous pouvez ajouter plus d'attributs et de données ultérieurement et ne pas rompre la compatibilité avec les anciens clients.
- consommable par les clients javascript (je ne suis pas sûr qu'ils aient encore l'analyseur protobuf JS, je ne pense pas qu'il y en ait un)
Protobufs sur TCP / IP:
Si c'était mon choix, j'irais de loin avec HTTP REST et JSON. Il y a une raison pour laquelle tant d'autres entreprises et sites Web ont choisi cette voie. Gardez également à l'esprit qu'à l'avenir, vous pourrez toujours prendre en charge 2 points d'extrémité. Si votre conception est correcte, votre choix de point final doit être complètement découplé de votre logique métier côté serveur ou de la base de données. Donc, si vous réalisez plus tard que vous avez besoin de plus de vitesse pour toutes / certaines demandes, vous devriez pouvoir ajouter des protobufs avec un minimum d'agitation. Mais dès le départ, REST / JSON vous fera décoller plus rapidement et vous mènera plus loin.
En ce qui concerne Netty vs Spring. Je n'ai pas utilisé Netty directement, mais je pense que c'est juste un serveur Web léger où Spring est un cadre qui vous offre beaucoup plus que cela. Il a des couches d'accès aux données, une planification des tâches en arrière-plan et (je pense) un modèle MVC, il est donc beaucoup plus lourd. Lequel choisir? Si vous avez décidé de passer à la méthode HTTP, la question suivante est probablement la norme de votre application Si vous êtes sur le point d'écrire une logique personnalisée folle qui ne correspond pas au moule standard et tout ce dont vous avez besoin est juste une couche de serveur HTTP, allez avec Netty.
Cependant, je soupçonne que votre application n'est pas si spéciale et qu'elle pourrait probablement bénéficier de beaucoup de choses que Spring a à offrir. Mais cela signifie que vous devez structurer votre application autour du cadre de Spring et faire les choses comme ils attendent de vous, ce qui signifierait en savoir plus sur Spring avant de plonger dans votre produit. Les cadres en général sont excellents, car ils vous permettent de décoller plus rapidement, mais l'inconvénient est que vous devez vous adapter à leur moule au lieu de faire votre propre conception, puis vous attendre à ce que le cadre fonctionne simplement.
(*) - dans le passé, il a été souligné que mes messages ne reflètent pas les opinions du monde entier, donc je vais enregistrer et ajouter simplement que j'ai une expérience limitée avec Netty (j'ai déjà utilisé le cadre Play qui est basé sur Netty) ou Spring (j'ai seulement lu à ce sujet). Alors, prenez ce que je dis avec un grain de sel.