API. Транспортные решения во внутренней сети

Молодой проект перекочевал на работу по принципу SOA.
Соответственно, все сервисы проекта общаются с API, как с прослойкой БД.
Вопрос состоит в правильном подборе метода транспорта для API клиента между внутренними сервисами.
В том числе, в приоритете рассматривается скорость самого транспорта и скорость работы кода API клиента (php).
На данном этапе, как временное решение, API клиент использует Guzzle библиотеку, но у нее было обнаружено ряд проблем с производительностью, да и сама библиотека кажется слишком монструозна.
Вообще было рассмотренно ряд идей по улучшению транспорта. Например, один из экзотических - Gearman Worker на HttpMessage сериализации. То есть, возможность усовершенствовать API Сервис для приема разношерстных типов сообщений есть.
Вопрос собственно выплывает следующий - какие библиотеки и комплексные решения для усовершенствования транспорта между сервисами порекомендует уважаемое сообщество? Тут рассмотреть хотелось бы и best-practice и "а у нас вот-так".
Спасибо за внимание.
  • Вопрос задан
  • 2861 просмотр
Пригласить эксперта
Ответы на вопрос 1
Abdusalamov
@Abdusalamov
Front-end разработчик
JSON-RPC (xml-rpc) вполне подходит для этих целей.
Библиотеки для клиента и сервера есть в огромном количестве для многих языков.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы