/ telegram

Web Services

Очень часто можно услышать про REST vs SOAP. Большое количество материалов про веб-сервисы ограничиваются SOAP и REST.

Мне не нравится, что многие упираются только в эти 2 подхода, будто других способов связи с сервисом нет. Вы можете с лёгкостью найти и другие решения, и оценить их применимость. Главное нужно критически анализировать разные подходы, а не просто читать обзоры. Нередко авторы статей из интернета не имеют нужных знаний.

REST - используем http протокол с некоторым набором правил (http://www.restapitutorial.com/)

SOAP - протокол (application layer модели OSI) формат сообщений строго описан, используется xml

Что если мы хотим передавать в бинарном виде?

RPC - Remote procedure call, здесь можете встретить информацию про RMI и CORBA, это мёртвые технологии, смотрите подходы новее.

Посмотрите на protobuf от гугла https://developers.google.com/protocol-buffers/ или https://thrift.apache.org/ . Это такие универсальные бинарные форматы сериализации.

gRPC (https://grpc.io/) - это такой RPC фреймворк от гугла, он использует protobuf. Интересное решение, если нужно организовать коммуникацию с минимальными накладными расходами.

MQ - message brokers, этот подход основан на введением в систему специального middle ware. Логика простая, одно приложение что-то добавляет в очередь, другое (или другие) читают эти сообщения и обрабатывают. Сообщения в данном случае могут быть просто объекты, или какие-то команды (тогда получится своего рода rpc). Посмотрите список доступных брокеров http://queues.io/ . Наиболее популярные ActiveMQ, Apache Kafka, RabbitMQ. У каждого свои плюсы и минусы, и нужно выбирать под проект.

Этот пост никак нельзя назвать обзором, просто мотивация смотреть на разные подходы при организации взаимодействия между сервисами. Например можно и сокеты использовать, и найдутся примеры где это будет иметь смысл:) Или использовать разные БД с подписками. Могу сделать полноценный пост по данной теме, пишите в ЛС.

web #services #thinking #dev #programming

Web Services
Share this

Subscribe to Yet another blog