Сравнительная таблица

	SOAP	REST	gRPC
Протокол	HTTP1.1.	HTTP1.1.	HTTP2 (работает в двух направлениях и за счет этого быстрее HTTP1.1)
Подход	сервисно-ориентированный дизайн. Клиент запрашивает у сервера услугу или функцию, которая может затрагивать ресурсы сервера	объектно-ориентированный дизайн. Клиент запрашивает у сервера создание, совместное использование или модификацию ресурсов	сервисно-ориентированный дизайн. Клиент запрашивает у сервера услугу или функцию, которая может затрагивать ресурсы сервера
Формат передаваемых данных	Запрос: XML Ответ: XML	Запрос: преимущественно JSON (реже XML) Ответ: JSON со всеми данными, найденными на сервере по этой конечной точке	Запрос: бинарный файл — protobuf. Ответ: бинарный файл — protobuf.
Контракт	обязательны WSDL-схемы	необязательно OpenAPI (Swagger), эндпоинты могут быть не задокументированы	обязательно пишется по стандарту Protocol Buffers, компилируется внутренним компилятором protoc, который генерирует необходимый исходный код классов из определений в proto-файле
Документирование	WSDL-схемы сложно писать и поддерживать	в JSON нужно задокументировать содержащиеся в нем поля и их типы. Часто информация может быть неточной, неполной или устаревшей.	четко определенная и самодокументируемая схема. API на Protobuf генерирует код, код не будет рассинхронизирован с документацией. При генерации кода из Protobuf проходит базовая проверка — сгенерированный код не принимает поля неправильного типа.
Вес	XML весит больше аналогичных JSON и base64 и в основном применяется в legacy-системах, которые были разработаны в конце 1990-х — начале 2000-х.	JSON меньше XML, но больше protobuf	меньше JSON
Производительность	Средняя, данные требуют дополнительной сериализации (парсинга)	Средняя, данные требуют дополнительной сериализации (парсинга)	Высокая, данные изначально сериализованы
Связь с сервером		1—1	1—1, 1—N, N—N
Скорость обмена		Средняя, обмен однонаправленный (запрос-ответ)	Высокая, обмен двунаправленный или стриминговый
Как передает данные	использует только HTTP-POST-запросы	создает разовое соединение между двумя точками: создал соединение, отправил и закрыл. Клиент шлет в API сообщения и сразу получает ответ или ждет формирования ответа. Клиенту и серверу не нужно знать о внутренних данных. Использует четыре основных метода HTTP: GET, POST, PUT, DELETE.	создает постоянное соединение — сокет — между двумя точками, по которому передает бинарный файл и вызывает удаленно функцию, передавая в нее параметры. Шлет сообщения в обе стороны: gRPC обеспечивает двунаправленную потоковую передачу данных — и клиент, и сервер могут одновременно посылать и получать несколько запросов и ответов в рамках одного соединения. REST так не умеет. Использует только HTTP-POST-запросы.
Число конечных точек (точек входа в приложение)	1	без ограничений	1
Работа в вебе	без допусилий	без допусилий	с дополнительными усилиями: gRPC работает на HTTP2 и передает бинарный файл, а JS в браузере работает на HTTP1 и взаимодействует только с текстовыми файлами. Поэтому существует gRPC-WEB, который может положить base64 в тело текстового сообщения, а затем JS отдельной библиотекой переводит base64 в JSON. gRPC-WEB — отдельный от gRPC протокол, существует только в браузере и действует как уровень перевода между gRPC и приложением в браузере. Фронтовый кодген не знает, где поле обязательное, а где нет. Все не базовые типы генерируются как optional. Стримы для фронта стали доступны не так давно. Раньше для отправки файла писали rest-точку.
Для какой архитектуры	сложная архитектура, выходящая за рамки CRUD. SOAP используют многие банки.	преимущественно CRUD. Самая популярная архитектура API для веб-сервисов и микросервисных архитектур.	преимущественно CRUD
Мультиязыковая поддержка	Не зависит от языка	Средняя, требуются сторонние сервисы для мультиязыковых систем	Высокая, встроенная автоматическая генерация кода для популярных языковых сред
Достоинства	Не зависит от языка. Встроенная обработка ошибок. Встроенный протокол безопасности. Самодокументируемый.	Клиент отделен от сервера. Нет длительного соединения с отслеживанием состояния → экономия ресурсов. Масштабируемость. Простой в использовании и понимании, большое комьюнити. Есть стандартный список кодов ошибок, но все пользуются им по-своему. Можно внедрять в самых разных форматах без стандартного программного обеспечения. Кэширование на уровне HTTP без дополнительных модулей.	Высокая производительность и низкая нагрузка на сеть. Держит соединение, не надо тратить время на подключение. Можно поставить таймаут клиента и тем самым экономить ресурсы. Строгая спецификация типов данных. Под каждое поле выделяет набор битов по порядку. Стандартизация кодов ошибок, зашитая в protobuf. Сам генерирует исходный код по proto. Самодокументируемый. Не зависит от языка, контракт везде одинаковый. Можно использовать для управления контейнерами в k8s и системами хранения данных.
Недостатки	Тяжелый XML. Сложный набор правил для описания контракта. Долгое обновление сообщений — особенности схемы. Постоянная необходимость в кодировании данных на сервере до передачи по каналам связи и их последующем декодировании на клиенте.	Избыточная нагрузка на сеть. Избыточная или недостаточная выборка данных. Нет документирования и стандартизации. Нет стандарта использования кодов ответов, поэтому часто в успешных кодах могут передаваться ошибки. Постоянная необходимость в кодировании данных на сервере перед передачей по каналам связи и последующем их декодировании на клиенте.	Не работает без gRPC-WEB в браузере. Человек не прочитает сообщение без декодера. Для работы нужно программное обеспечение gRPC как со стороны клиента, так и со стороны сервера.
Когда использовать	финтех и другие долгие массивные проекты со сложной архитектурой, легаси с 90-00 хх гг. или исторически выбранный SOAP, от которого не отказаться. Для нового проекта, возможно, стоит присмотреться к альтернативам.	благодаря простой реализации и отображению структуры данных, удобству чтения с ним легко работать начинающим программистам.	разработан для того, чтобы дать разработчикам возможность создавать высокопроизводительные API для микросервисных архитектур в распределенных центрах обработки данных. В том числе для микросервисных архитектур на нескольких языках программирования, для которых API вряд ли будет меняться со временем. Также он хорошо подходит для внутренних систем, требующих потоковой передачи данных в реальном времени и загрузки больших объемов информации.

Источник: https://habr.com/ru/companies/tinkoff/articles/780024/