Определенно есть плюсы / минусы использования JSON поверх REST по сравнению с прямым TCP / IP с двоичным протоколом, и я думаю, вы уже подозреваете, что двоичный протокол будет быстрее. Я не могу точно сказать, насколько быстрее (и это будет зависеть от множества факторов), но я бы предположил, что разница может быть на 1-2 порядка.
На первый взгляд, если что-то в 10-100 раз медленнее, чем что-либо другое, у вас может быть реакция коленного рефлекса и вы переходите к «быстрой вещи». Однако эта разница в скорости только в самом протоколе. Если есть доступ к базе данных / файлу на стороне сервера, это не повлияет на ваш выбор уровня передачи. В некоторых случаях это может сделать скорость вашего уровня передачи гораздо менее значимой.
HTTP REST и JSON хороши по ряду причин:
- они легко потребляются кем угодно. Вы можете написать свое веб-приложение, а затем развернуться и опубликовать свой API для использования остальным миром. Теперь любой желающий может попасть в одни и те же конечные точки и получить к вашим услугам
- они легко отлаживаются, вы можете открыть анализатор пакетов или просто сбросить входящие запросы в текстовые файлы и посмотреть, что происходит. Вы не можете сделать это с бинарными протоколами
- они легко расширяются. Вы можете добавить больше атрибутов и данных позже, не нарушая совместимость со старыми клиентами.
- может использоваться клиентами javascript (пока не уверен, что у них есть JS-анализатор protobuf, не верьте, что он есть)
Протобуфы через TCP / IP:
Если бы это был мой выбор, я бы предпочел использовать HTTP REST и JSON. Есть причина, по которой многие другие компании и сайты пошли по этому пути. Также имейте в виду, что в будущем вы всегда можете поддержать 2 конечные точки. Если ваш дизайн верен, ваш выбор конечной точки должен быть полностью отделен от вашей бизнес-логики на стороне сервера или базы данных. Поэтому, если вы потом поймете, что вам нужно больше скорости для всех / некоторых запросов, вы сможете добавить protobufs с минимальными усилиями. Однако REST / JSON сразу же приведут вас в чувство быстрее и продвинут вас дальше.
Насколько нетти против весны идет. Я не использовал Netty напрямую, но считаю, что это всего лишь легкий веб-сервер, так как Spring - это фреймворк, который предоставляет вам гораздо больше, чем просто. У него есть уровни доступа к данным, планирование фоновых заданий и (я думаю) модель MVC, так что она намного тяжелее. Какой выбрать? Если вы решили пойти по пути HTTP, то следующий вопрос, вероятно, насколько стандартно ваше приложение? Если вы собираетесь написать какую-то сумасшедшую настраиваемую логику, которая не соответствует стандартной форме, и все, что вам нужно, это просто уровень сервера HTTP, используйте Netty.
Тем не менее, я подозреваю, что ваше приложение не такое уж особенное, и оно может извлечь пользу из множества вещей, которые может предложить Spring. Но это означает, что вы должны структурировать свое приложение на основе среды Spring и делать то, что они ожидают от вас, что будет означать больше узнать о Spring, прежде чем погрузиться в ваш продукт. Фреймворки в целом великолепны, потому что они снова ускоряют процесс, но недостатком является то, что вы должны вписаться в их форму, а не делать свой собственный дизайн, а затем ожидать, что фреймворк просто сработает.
(*) - в прошлом указывалось, что мои посты не отражают мнения всего мира, поэтому я пойду на запись и просто добавлю, что у меня ограниченный опыт работы с любой из Netty (раньше я пользовался платформой Play) который основан на Netty) или Spring (я только читал об этом). Так что возьми то, что я скажу, с крошкой соли.