При создании / адаптации сервисов для работы в архитектуре SOA предоставляемые интерфейсы могут быть любыми, если только у потребителей есть возможность обрабатывать ответ.
Чтобы дать более краткий ответ, я буду интерпретировать REST как интерфейс HTTP, который может выполнять операции CRUD, возможно, отвечая на запросы с помощью объекта XML или JSON.
SOAP склонен к более сложным операциям на стороне службы, библиотеки и соответствующие XML-документы SOAP привносят сложность в систему.
Если все, что вам требуется, это представление ресурсов, к которым можно получить доступ с помощью простых операций CRUD, то стоит рассмотреть возможность реализации интерфейса REST, чтобы уменьшить сложность, даже если служба будет работать параллельно с сервисами с интерфейсами SOAP. Все, что требуется, - это то, что потребитель службы может иметь дело с ответами в стиле RESTful, а также выступать в качестве клиента SOAP.
Существуют аргументы в пользу согласованности во всей службе для улучшения удобства обслуживания и простоты разработки, но это не является необходимостью и должно быть включено только в процесс принятия решения.
Когда шина обмена сообщениями включена в проект, с гетерогенными службами можно работать еще эффективнее, вставляя в процесс стандартные преобразования (XSLT, пользовательские), которые могут преобразовывать ответ от служб в стандартный формат, понимаемый системой как все.