Существует много подходов к предоставлению услуг связи: если бы им пришлось документировать все это, они бы потратили больше времени на написание возможных подходов, чем на фактическое общение.
Они, вероятно, решили выбрать один.с самым близким отношением к платформе, но они могут написать о любом возможном, это просто вопрос предпочтений.
Я мог бы назвать несколько из многих, просто чтобы иметь представление:
- Http
- Remoting
- WCF
- Сервисная шина
- Концентратор событий
- AMQP
- MQTT
- gRPC + protobuf
- TCP
- UDP
- Трубы
И многие другие, представьте, что им пришлось документировать все это.
Связь достаточно гибкая, чтобы вы могли реализовать ее с использованием любого механизма связи.
Что касается упомянутых вами, я всегда выбираю HTTP, поскольку он не зависит от платформы и широко применяется на большинстве платформ, не имеет значенияесли есть .Net, Javа, NodeJ, Windows или Linux, они все говорят на одном языке, другие очень тесно связаны с платформой .Net и Windows и заставляют любое другое решение быть также адаптированным к этому.Также есть факт, что некоторые из них являются синхронными, а другие асинхронными, как, например, служебная шина.
Затем, когда возникает проблема с производительностью, я оцениваю другие варианты.