Очень часто можно услышать про 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
Знаете ли вы, что такое Buzz тестирование?
В нескольких словах - это такой способ тестирования, когда некая программа на вход функции или программы подаёт случайные данные в надежде выловить баги.
На деле всё немного сложнее и подаётся шум не случайным образом. Способ тестирования на самом деле интересный, можно даже сказать эмулирует поведение "типичного пользователя"
Google отдала в open source свой инструмент https://opensource.googleblog.com/2019/02/open-sourcing-clusterfuzz.html По их словам они нашли 16000 багов в хроме с помощью данного подхода.
#testing #dev
В нескольких словах - это такой способ тестирования, когда некая программа на вход функции или программы подаёт случайные данные в надежде выловить баги.
На деле всё немного сложнее и подаётся шум не случайным образом. Способ тестирования на самом деле интересный, можно даже сказать эмулирует поведение "типичного пользователя"
Google отдала в open source свой инструмент https://opensource.googleblog.com/2019/02/open-sourcing-clusterfuzz.html По их словам они нашли 16000 багов в хроме с помощью данного подхода.
#testing #dev
Google Open Source Blog
Open sourcing ClusterFuzz