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

    Вам не хватает фундаментальных знаний, в данном случае вам сильно помогло бы представление о модели 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).
    Ответ написан
    Комментировать
  • Что читать про интеграцию REST, SOAP, JSON, RMI и т.д для аналитика, который в этом ничего не понимает?

    @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. Да, можно, но не стоит этого делать, это не самый эффективный способ передачи подобного контента.
    Ответ написан
    Комментировать
  • Какие преимущества имеет Adobe captivate по сравнению с функционалом Axure RP?

    dimonchik2013
    @dimonchik2013
    non progredi est regredi
    у софта разные задачи

    а денег первый месяц не просят
    Ответ написан
    2 комментария