исследуй
проектируй
Улучшай

По-хорошему, сравнивать или противопостовлять их не то чтобы правильно. Это всё равно, что сравнивать, к примеру, импрессионизм и письмо акварелью.
REST - это архитектурный стиль; SOAP - это формат передачи сообщений.

Синхронное и асинхронное

Взаимдействе - это две стороны: отправитель и получатель.
В случае, когда мы говорим о синхронном характере взаимдействия - отправитель отправил и ожидает ответа от получателя, отправитель заблокирован в этом бизнес процессе, пока он не получит ОК или НЕ ОК со стороны получаетеля.
Когда же мы говорим об асинхронном взаимодействии - отправитель отправляет данные и далее переходит к выполнению следующих задач, он не заблокирован. Важно, в случае асинхронного взаимодействия мы не ждем ни ответа, ни какого бы то ни было подтверждения.

Удаленный вызов

Суть в том, что один сервис вызывает другой сервис удаленно через определенные методы.
Удаленный вызов - это интеграция через http/https через REST, SOAP, gRPC etc.

HTTP - HyperText Transfer Protocol - протокол передачи данных в сети.
HTTPS - HyperText Transfer Protocol Secure расширенный по безопасности протокол передачи данных в сети.
Для защиты передаваемых данных между клиентом и сервером используется SSL/TLS (Secure Sockets Layer / Transport Layer Security)
В основе лежит технология асимметричного шифрования с двумя ключами: публичным и приватным. Публичный - чтобы зашифровать, приватный, чтобы расшифровать.
Больше про шифрования читать здесь.

REST
Важно, что это стиль или набор правил, по которому проектируется взаимодействие. Если приложение реализовано в полном соответствии с парадигмой REST, такое приложение именуется RESTfull.

О чем речь?

• Клиент и сервер отделены. Клиент - это про коды запрсоов, а сервер - это владелец кода доустап к данным.
• Сервер не хранит данные о состоянии клиента.
• Кэшируемость. В данных запроса должно быть указано, нужно ли делать кэширование данных (сохранять в специальном буфере для частых запросов).
• Единообразие интерфейса. Все данные должны запрашиваться через один URL-адрес стандартными протоколами, например, HTTP.
• Многоуровневость системы. В RESTful сервера могут располагаться на разных уровнях, при этом каждый сервер взаимодействует только с ближайшими уровнями и не связан запросами с другими.
• Предоставление кода по запросу. Серверы могут отправлять клиенту код по требованию (например, скрипт для запуска аудио).

Означает ли это, что RESTfull можно считать неким требование к сервису? Я бы так не сказала - это, скорее рекомендация, чего стоит придерживаться, но не правило, которое должно выполняться в 100 из 100 случаях.
Интеграции выполняются на разных уровнях, решают различные задачи, и не всегда RESRfull что-то улучшает.
Иначе говоря, RESTfull ради RESTfull - это больше про потратить кучу денег, которые никак не конвертируются в деньги. Не стоит кодить ради того, чтобы кодить.

В окружении REST у объекта нет состояния, работа ведется через объявленные методы: GET — получение ресурса, POST — создание ресурса, PUT — обновление ресурса, DELETE — удаление ресурса, PATCH - изменение ресурса.

REST запрос состоит из тела, заголовка и параметров. Кроме того, мы говорим об опрециях или действиях с объектом - CRUD - создай (CREATE - POST, PUT), прочитай (READ - GET), обнови (PUT, PATCH) или удали (DELETE - DELETE).

PUT - чтобы целиком обновить объект, PATCH - чтобы частично обновить. Например, у нас есть контакты пользователя. Если мы отправим PUT - то перезапишем всё, что было в объекте на новые значения, если же сформируем PATCH - то можем обновить, например, только значение телефона. PUT - идемпотентен, то есть не будет приводить к созданию новых записей, будет n-кратно коливеству успешно обработанных запросов обновлять один и тот же объект. PATCH же в определенных кейсах неидемпотентен.

gRPC
gRPC - Remote Procedure Calls. Запросы строго типизированы, настрйока через protobuf. Интересно, что в gRPC клиент и сервис могут отменить запрос: установить дедлайн (токсичный термин), по истечении которого запрос отменяется, или отправить cancel() с клиента.
Proto-файлы описываются языком Interface Definition Language (IDL)
Через RPC можно как синхронные взаимодействия организовывать, так и асинхронные.

Ещё одна интересная особенность gRPC - это то, что данные при отправке сжимаются (преобразуются в двоичный формат), и при получении распаковываются обратно. Это легкость, скорость и дешевизна, если сравнивать, допустим с тем же REST

SOAP
SOAP - simple Object Access Protocol («простой протокол доступа к объектам»). Почему простой история умалчивает.
Когда мы находимся в окружении SOAP мы автоматически думаем в формате XML, значит XSD & WSDL как схемы, которые описывают структуру сообщений. Кроме того, в SOAP один запрос - один ответ.
Какие параметры присутсвуют в XSD-схеме:

• - элементы
• - типы
• - индикаторы порядка
• - вариаторы типа
  Элементы в схеме - это база, они могут быть сложными - вложенными друг в друга (type=complexType), для элементов могут быть объявлены ограничители, обязаттельность и т.д.

SOAP может использоваться поверх протоколов SMTP, FTP, HTTP, HTTPS

Итого, один сервис может вызывать другой сервис удаленно по-разному.
Прежде чем выбрать, нужно понимать задачу, на руках совершенно точно должна быть схема бизнес процесса, метрики бизнес процесса.
Мы должны понимать, для решения какой задачи мы ищем решение в виде интеграции, и, что важно, не только в моменте, но и на ближайшее будущее, чтобы не проектировать только MVP (если, разумеется, только MVP и есть цель)