REST часто выбирают для браузерного фронтенда из-за простой поддержки HTTP/JSON и удобства отладки. Нативный gRPC в браузере обычно требует адаптации, например gRPC-Web и соответствующего шлюза.
Почему фронтенд общается с бэкендом через REST, а не через gRPC?
REST часто выбирают для браузерного фронтенда из-за простой поддержки HTTP/JSON и удобства отладки. Нативный gRPC в браузере обычно требует адаптации, например gRPC-Web и соответствующего шлюза.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
REST часто выбирают для браузерного фронтенда из-за простой поддержки HTTP/JSON и удобства отладки. Нативный gRPC в браузере обычно требует адаптации, например gRPC-Web и соответствующего шлюза.
Выбор не означает, что gRPC непригоден для фронтенда. При строгих protobuf-контрактах, генерации клиентов и подходящей инфраструктуре gRPC-Web может быть хорошим решением, но его возможности и ограничения отличаются от обычного gRPC.
REST удобен для публичных API и типового веб-инструментария; gRPC часто применяют между сервисами. Сравнивать следует требования к стримингу, совместимости, размеру сообщений и эксплуатации, а не утверждать, что один протокол всегда быстрее или лучше.