Передача представительного состояния (REST) ​​и простой протокол доступа к объектам (SOAP)

Question

Может кто-нибудь объяснить, что такое REST и что такое SOAP на простом английском языке? А как работают веб-сервисы?

Answer 1

Простое объяснение о SOAP и REST

SOAP - «Простой протокол доступа к объектам»

SOAP - это метод передачи сообщений или небольших объемов информации через Интернет. Сообщения SOAP отформатированы в XML и обычно отправляются с использованием HTTP (протокол передачи гипертекста).

---

Остальное - Передача представительского состояния

Отдых - это простой способ отправки и получения данных между клиентом и сервером, и для него не определено слишком много стандартов. Вы можете отправлять и получать данные в формате JSON, XML или даже в виде простого текста. Это легкий вес по сравнению с SOAP.

---

Answer 2

Оба метода используются многими крупными игроками. Это вопрос предпочтений. Я предпочитаю REST, потому что его проще использовать и понимать.

Простой протокол доступа к объектам (SOAP):

• SOAP создает протокол XML поверх HTTP или иногда TCP / IP.
• SOAP описывает функции и типы данных.
• SOAP является преемником XML-RPC и очень похож, но описывает стандартный способ связи.
• Некоторые языки программирования имеют встроенную поддержку SOAP, обычно вы передаете ему URL-адрес веб-службы и можете вызывать функции его веб-службы без необходимости в специальном коде.
• Двоичные данные, которые отправляются, должны быть сначала закодированы в такой формат, как, например, base64.
• Имеет несколько протоколов и технологий, связанных с ним: WSDL, XSD, SOAP, WS-Addressing

Представительный государственный перевод (REST):

• REST не обязательно должен быть через HTTP, но большинство из моих пунктов ниже будут иметь смещение HTTP.
• REST очень легок, говорит, подождите минутку, нам не нужна вся эта сложность, которую создал SOAP.
• Обычно использует нормальные методы HTTP вместо большого формата XML, описывающего все. Например, для получения ресурса вы используете HTTP GET, для размещения ресурса на сервере вы используете HTTP PUT. Для удаления ресурса на сервере вы используете HTTP DELETE.
• REST очень прост в том, что он использует методы HTTP GET, POST и PUT для обновления ресурсов на сервере.
• REST обычно лучше всего использовать с ресурсно-ориентированной архитектурой (ROA). В этом способе мышления все является ресурсом, и вы будете оперировать этими ресурсами.
• Пока ваш язык программирования имеет библиотеку HTTP, и большинство из них имеет, вы можете очень легко использовать протокол REST HTTP.
• Двоичные данные или двоичные ресурсы могут быть просто доставлены по их запросу.

В Google REST против SOAP существует бесконечных дебатов в Google .

Мой любимый вот этот . Обновление 27 ноября 2013 г .: Сайт Пола Прескода, похоже, перешел в автономный режим, и эта статья больше недоступна, хотя копии можно найти на Wayback Machine или в формате PDF на CiteSeerX .

Answer 3

REST

Я понимаю, что основная идея REST чрезвычайно проста. Мы годами пользовались веб-браузерами и видели, насколько просты, гибки, эффективны и т. Д. Веб-сайты. HTML-сайты используют гиперссылки и формы в качестве основного средства взаимодействия с пользователем. Их главная цель - позволить нам, клиентам, знать только те ссылки, которые мы можем использовать в текущем состоянии . А REST просто говорит: «Почему бы не использовать одни и те же принципы для управления компьютером, а не людьми, через наше приложение?» Добавьте к этому мощь инфраструктуры WWW, и вы получите потрясающий инструмент для создания великолепных распределенных приложений.

Другое возможное объяснение - математически мыслящие люди. Каждое приложение в основном представляет собой конечный автомат, в котором действия бизнес-логики являются переходами состояний. Идея REST состоит в том, чтобы отобразить каждый переход на некоторый запрос к ресурсу и предоставить клиентам ссылки, представляющие переходы, доступные в текущем состоянии. Таким образом, он моделирует конечный автомат через представления и ссылки. Вот почему это называется REpresentational State Transfer.

Довольно удивительно, что все ответы сосредоточены либо на формате сообщений, либо на использовании HTTP-глаголов. На самом деле, формат сообщения вообще не имеет значения, REST может использовать любой, при условии, что разработчик сервиса документирует его. HTTP-глаголы только делают службу CRUD, но еще не RESTful. Что действительно превращает службу в службу REST, так это гиперссылки (так называемые элементы управления гипермедиа), встроенные в ответы сервера вместе с данными, и их количество должно быть достаточным, чтобы любой клиент мог выбрать следующее действие из этих ссылок.

К сожалению, довольно сложно найти правильную информацию о REST в Интернете, за исключением тезиса Роя Филдинга . (Он тот, кто получил REST). Я бы порекомендовал книгу «ОТДЫХ на практике» , поскольку в ней дано подробное пошаговое руководство по переходу от SOAP к REST.

SOAP

Это одна из возможных форм стиля архитектуры RPC (удаленного вызова процедур). По сути, это просто технология, которая позволяет клиентам вызывать методы сервера через сервисные границы (сеть, процессы и т. Д.), Как если бы они вызывали локальные методы. Конечно, он отличается от вызова локальных методов скоростью, надежностью и т. Д., Но идея в том, что все просто.

По сравнению

Такие детали, как транспортные протоколы, форматы сообщений, xsd, wsdl и т. Д., Не имеют значения при сравнении любой формы RPC с REST. Основное отличие состоит в том, что служба RPC заново изобретает велосипед, разрабатывая собственный протокол приложения в API RPC с семантикой, известной только ему. Следовательно, все клиенты должны понимать этот протокол перед использованием сервиса, и никакая общая инфраструктура, такая как кэши, не может быть построена из-за проприетарной семантики всех запросов. Кроме того, API-интерфейсы RPC не предлагают, какие действия разрешены в текущем состоянии, это должно быть получено из дополнительной документации. REST, с другой стороны, подразумевает использование унифицированных интерфейсов, позволяющих различным клиентам иметь некоторое представление о семантике API, и гипермедиа элементов управления (ссылки) для выделения доступных опций в каждом состоянии. Таким образом, он позволяет кэшировать ответы для масштабируемых сервисов и легко обнаруживать правильное использование API без дополнительной документации.

В некотором смысле, SOAP (как и любой другой RPC) представляет собой попытку туннелирования через границу службы, рассматривая соединительные среды как черный ящик, способный передавать только сообщения. REST - это решение признать, что Интернет представляет собой огромную распределенную информационную систему, принять мир таким, какой он есть, и научиться владеть им, а не бороться с ним.

SOAP, кажется, отлично подходит для внутренних сетевых API, когда вы управляете как сервером, так и клиентами, и в то время как взаимодействия не слишком сложны. Для разработчиков более естественно использовать его. Однако для общедоступного API, который используется многими независимыми сторонами, является сложным и большим, REST должен подходить лучше. Но это последнее сравнение очень нечеткое.

Обновление

Мой опыт неожиданно показал, что разработка REST сложнее, чем SOAP. По крайней мере, для .NET. Хотя существуют отличные фреймворки, такие как ASP.NET Web API, нет инструментов, которые бы автоматически генерировали прокси на стороне клиента. Ничего подобного «Добавить ссылку на веб-службу» или «Добавить ссылку на службу WCF». Нужно написать весь код сериализации и запроса сервисов вручную. И человек, это много шаблонного кода. Я думаю, что для разработки REST необходимо что-то похожее на WSDL и реализацию инструментов для каждой платформы разработки. На самом деле, кажется, что есть хорошая основа: WADL или WSDL 2.0 , но ни один из стандартов не поддерживается.

Обновление (январь 2016 г.)

Оказывается, что теперь существует широкий набор инструментов для определения REST API. Мои личные предпочтения в настоящее время RAML .

Как работают веб-сервисы

Ну, это слишком широкий вопрос, потому что он зависит от архитектуры и технологии, используемой в конкретном веб-сервисе. Но в целом, веб-сервис - это просто какое-то веб-приложение, которое может принимать запросы от клиентов и возвращать ответы. Он доступен для Интернета, поэтому это сервис web , и он обычно доступен 24/7, поэтому это сервис . Конечно, это решает некоторую проблему (иначе зачем кому-то использовать веб-сервис) для своих клиентов.

Answer 4

Это самое простое объяснение, которое вы когда-либо найдете.

В этой статье рассказ повествования между мужем и женой, где муж рассказывает жене о ОТДЫХ в чистом виде. Надо читать!

как я объяснил, отдыхаю моей жене (оригинальная ссылка)
как я объяснил жене (рабочая ссылка 2013-07-19)

Answer 5

SOAP - Простой протокол доступа к объектам - это протокол !

REST - REpresentational State Transfer - это архитектурный стиль !

SOAP - это протокол XML, используемый для передачи сообщений, обычно по HTTP

REST и SOAP являются возможно , а не взаимоисключающими. Архитектура RESTful может использовать HTTP или SOAP или какой-либо другой протокол связи. REST оптимизирован для Интернета и, таким образом, HTTP является идеальным выбором. HTTP также является протоколом only , обсуждаемым в статье Роя Филдинга.

Хотя REST и SOAP явно сильно различаются, этот вопрос освещает тот факт, что REST и HTTP часто используются в тандеме. В первую очередь это связано с простотой HTTP и его очень естественным отображением принципов RESTful.

Основные принципы ОТДЫХА

Связь клиент-сервер

Клиент-серверные архитектуры имеют четкое разделение задач. Все приложения, созданные в стиле RESTful, также должны быть клиент-серверными в принципе.

Stateless

Каждый запрос клиента к серверу требует полного представления его состояния. Сервер должен иметь возможность полностью понимать запрос клиента без использования контекста сервера или состояния сеанса сервера. Отсюда следует, что все состояние должно быть сохранено на клиенте. Мы обсудим представление без гражданства более подробно позже.

Cacheable

Могут использоваться ограничения кэширования, что позволяет помечать данные ответа как кэшируемые или не кэшируемые. Любые данные, помеченные как кэшируемые, могут быть повторно использованы в качестве ответа на тот же последующий запрос.

Единый интерфейс

Все компоненты должны взаимодействовать через единый унифицированный интерфейс. Поскольку взаимодействие всех компонентов происходит через этот интерфейс, взаимодействие с различными сервисами очень просто. Интерфейс такой же! Это также означает, что изменения реализации могут быть сделаны изолированно. Такие изменения не будут влиять на взаимодействие основных компонентов, потому что единый интерфейс всегда неизменен. Одним из недостатков является то, что вы застряли с интерфейсом. Если для конкретного сервиса может быть предоставлена ​​оптимизация путем изменения интерфейса, вам не повезло, поскольку REST запрещает это. С другой стороны, REST оптимизирован для Интернета, поэтому невероятно популярен REST по HTTP!

Приведенные выше понятия представляют собой определяющие характеристики REST и отличают архитектуру REST от других архитектур, таких как веб-сервисы. Полезно отметить, что служба REST является веб-службой, но веб-служба не обязательно является службой REST.

См. Этот блог post on Принципы дизайна REST для более подробной информации о REST и вышеупомянутых пулях.

Answer 6

Мне нравится ответ Брайана Р. Бонди. Я просто хотел добавить, что Википедия дает четкое описание REST . Статья отличает его от SOAP.

REST - это обмен информацией о состоянии, осуществляемый максимально просто.

SOAP - это протокол сообщений, использующий XML.

Одна из основных причин того, что многие люди перешли с SOAP на REST, заключается в том, что стандарты WS- * (называемые WS splat), связанные с веб-сервисами на основе SOAP, чрезвычайно сложны. См. wikipedia для получения списка спецификаций. Каждая из этих спецификаций очень сложна.

РЕДАКТИРОВАТЬ: по некоторым причинам ссылки не отображаются правильно. ОТДЫХ = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS-*

Answer 7

Как веб-сервисы SOAP, так и веб-сервисы REST могут использовать протокол HTTP и другие протоколы (просто упомянуть, что SOAP может быть базовым протоколом REST). Я буду говорить только о протоколах HTTP, связанных с SOAP и REST, потому что они используются чаще всего.

SOAP

SOAP («простой» протокол доступа к объектам) - это протокол (и стандарт W3C ). Он определяет, как создавать, отправлять и обрабатывать SOAP-сообщения.

• SOAP-сообщения - это XML-документы с определенной структурой: они содержат конверт, содержащий заголовок и раздел body. Тело содержит фактические данные, которые мы хотим отправить, в формате XML. Существует два стиля кодирования , но мы обычно выбираем литерал , что означает, что наше приложение или его драйвер SOAP выполняет сериализацию и десериализацию данных XML.

• Сообщения SOAP отправляются как сообщения HTTP с подтипом SOAP + XML MIME. Эти HTTP-сообщения могут быть составными, поэтому при желании мы можем прикреплять файлы к SOAP-сообщениям.

• Очевидно, что мы используем архитектуру клиент-сервер, поэтому клиенты SOAP отправляют запросы веб-сериям SOAP, а сервисы отправляют ответы клиентам. Большинство веб-сервисов используют файл WSDL для описания сервиса. Файл WSDL содержит XML-схему (далее XSD) данных, которые мы хотим отправить, и привязку WSDL, которая определяет, как веб-сервис связан с протоколом HTTP. Существует двух стилей связывания : RPC и документ. В соответствии с привязкой стиля RPC тело SOAP содержит представление вызова операции с параметрами (HTTP-запросы) или возвращаемыми значениями (HTTP-ответ). Параметры и возвращаемые значения сверяются с XSD. При привязке к стилю документа тело SOAP содержит документ XML, который проверяется на соответствие XSD. Я думаю, что стиль привязки документа лучше подходит для систем, основанных на событиях, но я никогда не использовал этот стиль привязки. Стиль связывания RPC более распространен, поэтому большинство людей используют SOAP для целей XML / RPC в распределенных приложениях. Веб-службы обычно находят друг друга, запрашивая сервер UDDI . UDDI-серверы - это реестры, в которых хранится местоположение веб-сервисов.

SOAP RPC

Таким образом, на мой взгляд, наиболее распространенный веб-сервис SOAP использует стиль привязки RPC и стиль буквального кодирования и имеет следующие свойства:

• Он сопоставляет URL-адреса с операциями.
• Отправляет сообщения с подтипом SOAP + XML MIME.
• У него может быть хранилище сеансов на стороне сервера, ограничений на это нет.
• Драйверы клиента SOAP используют файл WSDL службы для преобразования операций RPC в методы. Клиентское приложение связывается с веб-сервисом SOAP, вызывая эти методы. Таким образом, большинство клиентов SOAP ломаются из-за изменений интерфейса (результирующие имена методов и / или изменения параметров).
• Можно написать SOAP-клиенты, которые не будут ломаться при изменениях интерфейса, используя RDF, и находить операции по семантике, но семантическая веб-служба очень редка и не обязательно имеет неразрывный клиент Я думаю).

ОТДЫХ * * тысяча пятьдесят-одна REST (передача состояния представления) - это стиль архитектуры, который описан в диссертации 1054 * Роя Филдинга. Это не касается протоколов, как SOAP. Он начинается с стиля нулевой архитектуры, не имеющего ограничений, и определяет ограничения архитектуры REST один за другим. Люди используют термин RESTful для веб-сервисов, которые выполняют все ограничения REST, но, по словам Роя Филдинга, нет таких вещей, как уровни REST . Когда веб-сервис не соответствует каждому ограничению REST, он не является веб-сервисом REST. REST-ограничения Клиент-серверная архитектура - я думаю, что эта часть знакома всем. Клиенты REST связываются с веб-сервисами REST, веб-сервисы поддерживают общие данные - состояние ресурса в дальнейшем - и предоставляют их клиентам. Без гражданства - часть сокращения штата: REST. Клиенты поддерживают состояние клиента (состояние сеанса / приложения), поэтому у служб не должно быть хранилища сеансов. Клиенты передают соответствующую часть состояния клиента при каждом запросе службам, которые отвечают соответствующей частью состояния ресурса (поддерживаемой ими). Поэтому запросы не имеют контекста, они всегда содержат необходимую информацию для их обработки. Например, при базовой аутентификации HTTP имя пользователя и пароль сохраняются клиентом, и он отправляет их при каждом запросе, поэтому проверка подлинности происходит при каждом запросе. Это сильно отличается от обычных веб-приложений, где аутентификация происходит только по логину. Мы можем использовать любой механизм хранения данных на стороне клиента, например, в памяти (javascript), куки, localStorage и т. Д., Чтобы сохранить некоторые части состояния клиента, если мы захотим. Причина ограничения безгражданства в том, что сервер хорошо масштабируется - даже при очень высокой нагрузке (миллионы пользователей) - когда ему не нужно поддерживать сеанс каждого отдельного клиента. Кэш - ответ должен содержать информацию о том, может ли он быть кэширован клиентом или нет. Это еще больше повышает масштабируемость. Единый интерфейс Идентификация ресурсов - ресурс REST аналогичен ресурсу RDF . Согласно Филдингу, если вы можете назвать что-то, то это может быть ресурс, например: «текущая местная погода» может быть ресурсом, или «ваш мобильный телефон» может быть ресурсом, или «конкретный веб-документ» может быть ресурс. Для идентификации ресурса можно использовать идентификаторы ресурса: URL-адреса и URN (например, номер ISBN по книгам ). Один идентификатор должен принадлежать только определенному ресурсу, но у одного ресурса может быть много идентификаторов, которые мы часто используем, например, путем разбивки на страницы с URL-адресами, такими как https://example.com/api/v1/users?offset=50&count=25. URL-адреса имеют некоторые спецификации , например, URL-адреса с одинаковыми путями, но разные запросы не идентичны, или часть пути должна содержать иерархические данные URL, а часть запроса должна содержать неиерархические данные. Это основы того, как создавать URL-адреса с помощью REST. Btw. структура URL имеет значение только для разработчиков сервиса, реальный клиент REST не имеет к этому отношения. Другой часто задаваемый вопрос - это версионирование API, которое является простым, потому что согласно Филдингу единственная постоянная вещь по ресурсу - это семантика. Если семантика изменится, вы можете добавить новый номер версии. Вы можете использовать классическое 3 номерное управление версиями и добавить только основной номер в URL (https://example.com/api/v1/). Таким образом, с изменениями с обратной совместимостью ничего не происходит, с изменениями без обратной совместимости вы будете иметь семантику с обратной совместимостью с новым корнем API https://example.com/api/v2/. Поэтому старые клиенты не сломаются, потому что они могут использовать https://example.com/api/v1/ со старой семантикой. Управление ресурсами с помощью представлений - вы можете манипулировать данными, связанными с ресурсами (состоянием ресурсов), отправляя намеченное представление ресурсов - вместе с методом HTTP и идентификатором ресурса - в службу REST. Например, если вы хотите переименовать пользователя после вступления в брак, вы можете отправить запрос PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}, где {name: "Mrs Smith"} - это JSON-представление предполагаемого состояния ресурса, другими словами: новое имя. Это происходит наоборот, служба отправляет представления ресурсов клиентам для изменения их состояний. Например, если мы хотим прочитать новое имя, мы можем отправить запрос извлечения GET https://example.com/api/v1/users/1?fields="name", что приведет к ответу 200 ok, {name: "Mrs Smith"}. Таким образом, мы можем использовать это представление для изменения состояния клиента, например, мы можем отобразить «Добро пожаловать на нашу страницу, миссис Смит!» сообщение. Ресурс может иметь много представлений в зависимости от идентификатора ресурса (URL) или заголовка accept, который мы отправили с запросом. Например, мы можем отправить изображение миссис Смит (возможно, не ню), если запрашивается image/jpeg. Сообщения с самоописанием - Сообщения должны содержать информацию о том, как их обрабатывать. Например, метод URI и HTTP, заголовок типа содержимого, заголовки кэша, RDF, который описывает значение данных и т. Д. Важно использовать стандартные методы. Важно знать спецификацию методов HTTP. Например, GET означает получение информации, идентифицированной URL-адресом запроса, DELETE - запрос сервера об удалении ресурса, идентифицированного данным URL-адресом, и т. Д. Коды состояния HTTP также имеют, например, спецификацию . 200 означает успех, 201 означает, что новый ресурс был создан, 404 означает, что запрошенный ресурс не был найден на сервере и т. Д. Использование существующих стандартов является важной частью REST. Гипермедиа как движок состояния приложения (далее HATEOAS) - Гипермедиа - это тип мультимедиа, который может содержать гиперссылки. В Интернете мы следуем ссылкам - описанным в формате гипермедиа (обычно HTML) - чтобы достичь цели, вместо того, чтобы вводить URL-адреса в адресную строку. REST следует той же концепции, представления, отправляемые службой, могут содержать гиперссылки. Мы используем эти гиперссылки для отправки запросов в сервис. В ответ мы получаем данные (и, возможно, больше ссылок), которые мы можем использовать для создания нового состояния клиента и т. Д. Так вот почему гипермедиа является двигателем состояния приложения (состояния клиента). Вам, наверное, интересно, как клиенты распознают гиперссылки и следуют за ними? Для людей это довольно просто, мы читаем заголовок ссылки, возможно, заполняем поля ввода, и после этого всего один клик. На машинах мы должны добавить семантику в связи с RDF ( JSON-LD с Hydra ) или с решениями, специфичными для гипермедиа (например, отношения ссылок IANA и MIME-типы, специфичные для поставщика HAL + JSON ). Существует много машиночитаемых XML и гипермедиа форматов JSON , только краткий их список: XHTML ATOM + XML RDF + XML HAL + XML HAL + JSON JSON-LD RDF + JSON Сирена Коллекция + JSON Иногда трудно выбрать ... Многоуровневая система - мы можем использовать несколько слоев между клиентами и сервисами. Никто из них не должен знать обо всех этих дополнительных слоях, просто о слое рядом с ним. Эти уровни могут улучшить масштабируемость за счет применения кэшей и балансировки нагрузки, или они могут применять политики безопасности. Код по запросу. Мы можем отправить обратно код, который расширяет функциональные возможности клиента, например, код JavaScript в браузере. Это единственное необязательное ограничение REST. Веб-сервис REST - отличия веб-сервиса SOAP RPC

Таким образом, веб-служба REST сильно отличается от веб-службы SOAP (со стилем привязки RPC и литеральным стилем кодирования)

• Он определяет единый интерфейс (вместо протокола).
• Он сопоставляет URL-адреса с ресурсами (а не с операциями).
• Отправляет сообщения с любыми типами MIME (вместо просто SOAP + XML).
• У него связь без сохранения состояния, и поэтому он не может иметь хранилище сеансов на стороне сервера. (SOAP не имеет ограничений по этому поводу)
• Он обслуживает гипермедиа, и клиенты используют ссылки, содержащиеся в этой гипермедиа, для запроса услуги. (SOAP RPC использует привязки операций, описанные в файле WSDL)
• Не нарушается при изменении URL-адреса, только при изменении семантики. (Клиенты SOAP RPC без использования нарушения семантики RDF из-за изменений файла WSDL.)
• Он масштабируется лучше, чем веб-сервис SOAP, из-за его поведения без сохранения состояния.

и так далее ...

Веб-служба SOAP RPC не удовлетворяет всем ограничениям REST:

• клиент-серверная архитектура - всегда
• без гражданства - возможно
• кеш - возможно
• единый интерфейс - никогда
• слоистая система - никогда
• код по запросу (необязательно) - возможно

Answer 8

Хорошо, я начну со второго вопроса: Что такое веб-службы? , по понятным причинам.

WebServices - это, по сути, кусочки логики (которую вы можете смутно называть методом), которая предоставляет определенные функциональные возможности или данные. Клиент, реализующий (технически говоря, потребляющий - это слово) просто должен знать, какие параметры (ы) метод собирается принять и тип данных, которые он собирается возврат (если это вообще так).

Следующая ссылка говорит о REST & SOAP чрезвычайно ясным образом.

ОТДЫХ против SOAP

Если вы также хотите знать, когда выбирать, что (REST или SOAP), тем больше причин для этого!

Answer 9

SOAP и REST относятся к способам взаимодействия различных систем друг с другом.

REST делает это, используя методы, которые напоминают взаимодействие вашего браузера с веб-серверами: использование GET для запроса веб-страницы, POSTing в полях формы и т. Д.

SOAP обеспечивает нечто подобное, но делает все, отправляя блоки XML туда и обратно. Другим ключевым компонентом SOAP является WSDL, который представляет собой документ XML, описывающий, какие функции и элементы данных поддерживаются. WSDL можно использовать для программного "обнаружения" поддерживаемых функций, а также для создания заглушек программного кода.

Answer 10

REST - это стиль архитектуры для проектирования сетевых приложений. Идея состоит в том, что вместо использования сложных механизмов, таких как CORBA, RPC или SOAP, для соединения между машинами, простой HTTP используется для выполнения вызовов между машинами.