Что читать про интеграцию REST, SOAP, JSON, RMI и т.д для аналитика, который в этом ничего не понимает?

Question

[Amadora]

Коллеги, всем привет. Прошу не закидывать сильно камнями. Надеюсь, что вы поймете и простите. Являюсь системным аналитиком и управляю командой ~12 человек по направлению. К сожалению ИТ-вуз меня миновал и многие вещи, казалось бы очевидные, я не знаю. Наиболее критичными на мой взгляд являются вопросы интеграции. Хотелось бы разобраться в них, но не хотелось попусту тратить время на "не нужное". Может вы сориентируйте более целенаправленно меня.

Мой уровень знаний (своими словами не открывая google):
- Сообщения через SOAPпротокол имеют XML-структуру, но передаются не файлами, а через http. Ответы и запросы можно отследить либо специализированным ПО (SOAP UI например), либо как то отследить в браузере Chrome (не проверял как); Для него нужен в end point WSDL-файл, который валидирует входящее сообщение. Но почему он не нужен в других протоколах?
- Сообщения JSON. Тоже самое, что и SOAP, но имеет другое оформление, отличающееся от классического XML. И вот тут как бы есть ощущение, что я что то упускаю :-) Обмен по HTTP. Можно ли как то отследить сообщения?
- RMI- удаленный вызов java-метода. Можно нажатием кнопки в одном ПО запустить метод выполнения в другом. Но в чем разница между другими процессами? Неужели нельзя сделать тоже самое при использовании SOAP и JSON? Можно как то отследить выполнение команд из-вне?
- REST - видимо это стиль, который можно применять при всех вышеперечисленных протоколах (кроме RMI) верно?
- Socket - что это? О чем это? Чем отличается от всего вышеперечисленного?
- Есть еще обычные и понятные для меня XML-файлы, которые могут иметь абсолютно любую структуру.

Итого:
1. Есть ли что то, что может помочь довольно быстро погрузиться во все это?
2. Есть ли еще какие то стандартные протоколы, которые в целом все должны знать для галочки?
3. Верно понимаю, что с помощью этих протоколов можно передать хоть HD-фильм преобразуя файл в какой то формат а-ля base64?

Comments

[sim3x]

Вики
Прочитайте топики по темам

Все что останется непонятным - задайте вопрос своему ТЛ

Answer 1

[Владимир Дубровин]

Вам не хватает фундаментальных знаний, в данном случае вам сильно помогло бы представление о модели ISO/OSI + основные представления о классах и объектах.

Если вы прочитаете про модель ISO/OSI вам достаточно легко будет понять, что упомянутые сущности относятся к разным уровням. В данном случае можно выделить несколько уровней уровней:

1. Сетевое соединение - способ установить соединение между двумя приложениями (например клиентским и серверным). Сокет является представлением такого соединения на уровне операционной системы и приложения (т.е. этим пняием оперирует разработчик пишущий сетевое приложение).
2. Прикладной протокол - описывает взаимодейтвие клиента и сервера, чаще всего через установленное сетевое соединение (т.е. с програмной точки зрения через сокет). Например, HTTP или SMTP. Т.е. прикладные протоколы находятся над сокетами.

сокеты и сетевые протоколы относятся к модели ISO/OSI

3. Форматы обмена данных. Есть несколько универсальных форматов позволяющих описывать практически любые данные. К ним относятся, например, XML и JSON. JSON является альтернативой XML (он несколько проще и компактней). По JSON и XML есть соответствующие стандарты.
Данные в этих форматах могут храниться или пердаваться поверх прикладных протоколов (например поверх HTTP).

4. Модели данных (классы). Модель данных описывает определенный класс данных. Например, заказ. Она определяет какие свойства есть у заказа (дата, сумма, товар, покупатель, продавец, дата доставки и т.д.). Модели данных бумают универсальные и бывают разработанные под конкретное приложение. Существуют различные стандарты описывающие модели данных и связи между ними - XML schema, JSON-LD. Универсальные модели данных можно найти на schema.og. Разработчики приложения могут создать свою модель данных. Модели данных могут быть описаны как для XML так и для JSON.

5. API (программные компоненты) использующие модели данных. В частности SOAP и REST API. При этом SOAP является стандартом на подобные API и используется обычно для универсальных интегрируемых между собой компонент, SOAP использует XML. REST API это достаточно условный термин, который может быть применен практически к любому API который принимает или отдает структурированные данные (как поверх XML так и поверх JSON). SOAP ближе к объектной модели данных, REST API ближе к классическому API и используется для простых клиент-серверных приложений.
WSDL просто один из элементов SOAP.
Т.е. SOAP работает поверх XML schema поверх XML поверх HTTP (например) поверх соединения через сокет.

RMI в целом можно отнесети сюда же, но он менее универсальный, т.к. привязан к JAVA и использует внутренние бинарные представления данных а не какой-либо универсальный формат представления данных.

последние три уровня не относятся к модели ISO/OSI, это уже из область прикладной разработки / дизайна.

Вопрос про HD-фильм это вопрос из области можно ли переслать слона по почте. Через сокет можно передавать любые данные, в XML/JSON тоже можно упаковать любые данные, по прикладному протоколу тоже можно пердать любые данные и т.д. Более того, есть DLNA который фактически является REST API поверх XML и поддерживается любым современным телевизиром именно для передачи фильмов, в т.ч. HD. Т.е. создать конкретную реализацию приложений которая будет поддерживать HD фильмы можно, но ожидать что любая реализация SOAP/REST API поволит передавать HD фильмы нельзя, они делаются под определенные задачи.
На практике как правило есть конкретная реализация и ограничения, например на размер POST запроса или размер письма (SOAP может использовать SMTP, не только HTTP).

Answer 2

[galliard]

SOAP может передаваться и файлами, и через http, да хоть на бумаге. Вообще протокол не описывает способ передачи сообщений, а только их структуру. Передавать и получать завернутые в xml данные может любое клиен-серверное ПО, а "специализированное ПО" нужно для того, чтобы зоворачивать эти данные в xml и извлекать их из него. В качестве ПО типа SOAP UI встречается редко, и применяется в основном в целях отладки.

WSDL - это прикладной xml документ, описывающий структуру конкретного апи. В нем написано, куда слать запросы, какие существуют функции, какие у них аргументы, какой ответ они возвращают, какие существуют типы данных и так далее. В принципе, можно и без него. Нужен он для упрощения интеграции при помощи кодогенерации.

Сообщения JSON это любые сообщения в формате json. Могут иметь любую форму и структуру. В отличии от SOAP, где правила составления всех форм и структур четко регламентированы, сообщения JSON могут быть любыми, какими захочет разработчик. Это ускоряет и удешевляет разработку (любая обезьяна, едва научившись кодить, сварганит тебе говноапи за миску дошика) но усложняет интеграцию.

RMI по сути делает то же самое, только с меньшим количеством оберток. В случае использования XML или JSON апи нужно заворачивать данные в xml/json, потом в http, отправлять на http-сервер, который потом предаст их обработчику запроса, который в свою очередь распарсит xml/json, извлечет оттуда данные и вызовет наконец-то нужную функцию, получит ответ, и прокрутит эту цепочку назад чтобы отдать ответ. RMI же сериализует данные в бинарный вид и отправляет сообщение на сервер через сокет, там их десереализует, выполняет нужную функцию, сериализует ответ и отправляет обратно.

Да, REST - это стиль, который обычно не применяют к SOAP и RMI, которые традиционно придерживаются RPC - стиля. Насколько это в принципе возможно я не знаю, поскольку никогда не пробовал и даже не задумывался об этом.

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

Итого:
1. Нет. Нужно вариться в этом котле, понимание будет приходить со временем и постепенно.
2. FTP, HTTP, Web-Socket, TCP, UDP, XML-RPC, gRPC.
3. Да, можно, но не стоит этого делать, это не самый эффективный способ передачи подобного контента.