Очень часто можно услышать про 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
Мне не нравится, что многие упираются только в эти 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
REST API Tutorial
Learn REST API Design - REST API Tutorial