The rest или android что

REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ?

Оглавление цикла статей:

REST vs SOAP. Часть 1. Почувствуйте разницу.
REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ?

Зачем все это?

Зачем вообще нужно взаимодействие приложений, тем более написанных на разных платформах? Глупый вопрос, конечно. В мире программирования параллельно существуют и развиваются несколько абсолютно независимых, а местами и враждующих платформ. Кроме того, огромное количество софта уже написано и успешно работает, поэтому переписывать его под каждую новую платформу никто не будет. Возьмем банк для примера. Все in-house программисты банка всегда писали на JAVA, поэтому у банка есть сервис, который уже 5 лет прекрасно работает, недавно появились красивые мобильные приложения на Android, которые стабильно работают почти на всех версиях ОС, и остался даже сайт с апплетом, которых преподаватели в харьковских вузах до сих показывают в качестве примера передовых веб-технологий (jk). А теперь появилась задача разработки десктопного банковского приложения под Windows. Банк заказал WPF-приложение аутсорсинговой компании. Как же организовать общение платформ?

Немного истории

Отвлечемся пока от примера и обратимся к истории. Мне это делать, наверное, сложнее, чем многим из моих коллег, потому что я вступил в секту программистов во времена .Net, когда не обязательно знать протокол HTTP, чтобы писать сайты, а писать полнофункциональные десктопные приложения можно даже ни разу не слышав о WinAPI. Но я попробую сделать такой экскурс. Времена динозавров особо рассматривать не будем (будем считать, что динозавры вымерли с появлением XML в 1998), чтобы не отдаляться от основной темы. Предположим, у нас есть установленное соединение между двумя приложениями, по которому один может посылать байты, а другой будет их получать. Что дальше? Приложения должны договориться, что, к примеру, «1» значит «вышли список всех клиентов», «2|36782» — «вышли список транзакций для клиента 36782». Возможно, примерно так происходило дело в расцвет Мезозойской Эры. Это обязывало разработчиков изобретать новый велосипед для каждого взаимодействия приложений. С развитием интернета (середина 90-х) приложения смогли обмениваться информацией, предоставляя ее в оговоренном виде по оговоренному URL (позже это назовут “REST”). Какие протоколы были и как приложения общались до появления XML-RPC – писать не буду, просто потому что мало что знаю, может быть у кого-нибудь в комментариях пробьются ностальгические чувства.

RPC – это «remote procedure call», понятие очень старое, объединяющие древние, средние и современные протоколы, которые позволяют вызвать метод в другом приложении. XML-RPC – это протокол, появившийся в 1998, вскоре после появления XML. Изначально поддерживался Microsoft, но вскоре Microsoft полностью переключилась на SOAP и поэтому в .Net Framework мы не найдем классов для поддержки этого протокола. Несмотря на это, XML-RPC продолжает жить до сих пор в различных языках (особенно в PHP), видимо, заслужил любовь разработчиков своей простотой. Интересное чувство, когда наконец-то разбираешься в том, о чем уже давно писал в резюме. Это про XML-RPC и мое еще студенческое резюме. 🙂

SOAP также появился в 1998 году стараниями Microsoft. Он был анонсирован как революция в мире ПО. Нельзя сказать, что все пошло по плану Microsoft, было огромное количество критики из-за сложности и тяжеловесности протокола. В то же время были и те, кто считал SOAP настоящим прорывом. Сам же протокол продолжал развиваться и плодиться десятками новых и новых спецификаций, пока в 2003 года W3C не утвердила в качестве рекомендации SOAP 1.2, который и сейчас является последним. Семейство у SOAP получилось внушительное, вот их семейная фотография:

(на фото — WS-Addressing, WS-Enumeration, WS-Eventing, WS-Transfer, WS-Trust, WS-Federation, Web Single Sign-On… А того второго справа вообще не вспомнить, как зовут)

За более десяти лет споры по поводу SOAP не утихли, он по прежнему яростно критикуется за перегруженность, за низкую скорость работы. Однако протокол не умер, скорее даже наоборот, хотя и мир тоже не захватил. Критика протокола во многом справедлива: не используются заложенные в HTTP фичи, длина сообщений больше, чем у REST, от всех этих WS-Federation и WS-AtomicTransaction часто нету никакой пользы.

Но я хочу заострить внимание на другом – как же быстро можно разрабатывать распределенные приложения, используя семейство протоколов SOAP! Это ли не революция, которую нам обещал Microsoft? По-моему, это именно она. Где еще можно порасставлять аттрибуты в коде, нажать кнопку Publish на сервисе, нажать кнопку Generate Proxy на клиенте и вызывать код, как будто он находится в том же проекте? Поэтому на передний план выходит вопрос о том, в каких языках и средах программирования такая сказка возможна. Попробую свести эти данные в таблицу:

А как же REST, неужели он не нужен?

Несмотря на все лестные слова с адрес в адрес SOAP, я ни в коем случае не собираюсь сказать, что REST подход не нужен. Термин REST появился в 2000, т.е. всего лишь на два года позже первой версии SOAP. Сам же подход появился намного раньше, в 2000 же он просто был осознан, задокументирован и название сменилось с длинного «я тебе даю такую-ту инфу там-то» на непонятное «REST». Происхождение названия и принципы REST подробно обсуждались в первой части статьи. Здесь я заострю внимание на том, где REST лучше использовать и почему:

1. В сервисах, которые будут использоваться из javascript. Тут и говорить нечего, javascript хорошо работает с json, поэтому именно его и надо предоставлять.
2. В сервисах, которые будут использоваться из языков, в которых нет возможности сгенерировать прокси клиента. Это Objective-C, например. Не нужно парсить вручную SOAP-конверт, это незачем.
3. Когда существуют очень высокие требования к производительности. Это, как правило, очень интенсивно используемые API, вроде Twitter API или Google API.

А когда же использовать SOAP:

1. Когда взаимодействие происходит между платформами, под которые существуют инструменты для ускорения разработки с использованием SOAP. Например, правильно писать SOAP-сервис на JAVA, который будет использоваться из .Net и Flex.
2. Когда можно извлечь пользу из всех накруток SOAP. Достоверных сведений о том, что кто-то сумел это сделать, у меня нет. Понятный пример придумать не могу.

Таким образом, у меня все свелось к тому, что использовать SOAP надо там, где он поддерживается, в противном случае использовать REST. Это в разы сократит время разработки клиентов веб-сервиса и внесения изменений в них, позволит вместо детального разбора кода и добавления туда новых полей просто нажать кнопку «Update Service Reference».

Скорость разработки REST и SOAP сервисов в .Net одинакова. В WCF вообще можно превратить SOAP-сервис в RESTful и наоборот путем нехитрых и не трудоемких махинаций с конфигурацией, поэтому, говоря об ускорении скорости разработки, я имею ввиду клиентскую часть, которая может разрабатываться как одновременно с серверной частью, так и намного позже и совсем другой компанией. Польза от использования SOAP увеличивается, если сервис принимает и возвращает большие и сложные структуры данных.

Дни SOAP сочтены?

Сейчас REST и SOAP оба успешно используются, однако может произойти так, что SOAP действительно исчезнет, как пишут его критики. Такое, по моему мнению, возможно, если для RESTful сервисов начнет использоваться WSDL или подобный протокол, который позволит генерировать клиентские прокси. Поползновения такие были, протокол назывался WADL, однако на данный момент ничего такого не существует. Конечно, для такого сценария потребуется желание и приличные усилия хотя бы одного из основных игроков в мире IT, но я бы не стал исключать такой вариант. И будет у нас тогда лучшее из двух миров – простота и бенефиты от архитектуры сети и автоматизация взаимодействия приложений с помощью клиентских прокси.

Пример

Все уже забыли о примере из начала статьи? Он взят из жизни. Напомню, там разрабатывается WPF приложение, которое должно получать данные из существующего сервиса, написанного на JAVA. В каком формате он мог бы нам отдавать данные чтобы все выглядело бы красиво в соответствии с этой статьей? Правильно, в SOAP. А он отдает json. Надеюсь, ни у кого не возникло мысли «какой json, это в смысле REST?». Конечно REST! REST может возвращать данные в простом XML, json или любом другом запрошенном формате, даже в формате «как Вася попросил», если вам конечно удастся сделать этот формат одним рекомендуемых стандартов W3C или хотя бы договориться с разработчиками сервиса, чтобы они знали, что делать с этим:

Content-Type: application/as-Vasya-asked; charset=utf-8

Мы отвлеклись от дела. Ну возвращает сервис данные в json, и чем это нам грозит? А вот чем: прокси клиента сгенерить не сможем, придется вручную посылать запросы и парсить ответы. Придется использовать HttpWebRequest или надстройки над ним. А был бы SOAP – деньги заказчика были бы сэкономлены.

Заключение

Надеюсь, мне удалось обрисовать достаточно целостную картину взаимодействия приложений вне зависимости от языка и платформы. Хотел добавить, что описанные три подхода (REST, XML-RPC, SOAP) – это не все возможные варианты. Например, игрушки для соцсетей (пишутся на Flex) часто устанавливают прямое соединение через сокеты с серверной частью, написанной на C#. За счет этого получается выигрыш в скорости вместе с необходимостью изобретать мопед для каждого нового приложения. Где-то это уже было…
Вполне возможно, что я упустил что-то важное, особенно если это не касается .Net, буду рад узнать об этом.

Источник

ziginsider

17 августа 2017

Что такое REST?

REST — (сокр. от англ. Representational State Transfer — «передача состояния представления») архитектурный стиль взаимодействия компонентов распределённого приложения в сети по модели клиент-сервер. Был разработан в диссертации Роя Филдинга в 200 году, как альтернатива SOAP, когда запрос клиента несет в себе исчерпывающую информацио о желаемом ответе сервера и сервер не обязан сохранять сессию взаимодействия с клиентом.

Особенности архитектурного стиля:

• Каждая сущность должна иметь уникальный идентификатор – URI.
• Сущности должны быть связаны между собой.
• Для чтения и изменения данных должны использоваться стандартные методы.
• Должна быть поддержка нескольких типов ресурсов.
• Взаимодействие должно осуществляться без состояния.

Стандартные методы таковы:

• GET – получение данных без их изменения. Это наиболее популярный и легкий метод. Он только возвращает данные, а не изменяет их, поэтому на клиенте вам не нужно заботиться о том, что вы можете повредить данные.
• POST – метод, подразумевающий вставку новых записей.
• PUT – метод, подразумевающий изменение существующих записей.
• PATCH – метод, подразумевающий изменение идентификатора существующих записей.
• DELETE – метод, подразумевающий удаление записей.

Что такое REST-API?

REST API – это набор удаленных вызовов стандартных методов, возвращающих данные в определенном формате.

Где используется стиль REST в Android?

1) См. реализации различных библиотек REST-клиентов, например: Retrofit, Volley, RoboSpice… См. статью Volley vs Retrofit

Задачи, которые требуется решить при реализации REST-клиента

Перечислим, какие основные задачи придется решать при реализации REST-клиента на Android согласно паттернам Virgil Dobjanschi (Это так называемые паттерны A/B/C, которые описывают способы реализации REST-клиента под Android. Подробней о паттернах на русском можно глянуть здесь (лекция 2) или здесь):

• Управление сервисом: запуск, остановка.
• Передача результатов из сервиса в активити.
• Кэшировать результатов в sqlite.
• Фиксирование статуса данных sqlite перед и после выполнения REST-запроса.
• Запись информации о проводимых REST-операциях в sqlite.
• Парсинг полученных данных.
• Конструирование REST-запроса на основе URI и набора параметров.
• Выполнение сетевых запросов к REST-серверу.
• Чистка базы данных от устаревших данных.
• В случае неудачи REST-запроса, пытаться повторить запрос (например, экспоненциально увеличивая время между запросами).
• Возможность отложенного запуска REST-запроса через SyncAdapter.

Некоторые важные моменты для реализации REST-клиента под Android, согласно паттернам A/B/C

• Данные, полученные от REST-сервера, всегда сохраняются в sqlite. Напрямую в Activity они никогда не передаются. Вместо этого в Activity передается уведомление о том, что данные загружены в sqlite и их можно оттуда загрузить (вариант — Activity получает уведомление об обновлении данных в Content Provider через Content Observer).
• При выполнении операций insert, delete, update данные в sqlite обновляются дважды: первый раз до отправки REST-запроса, второй раз — после получения результата. Первая операций выставляет информационные флаги, сигнализирующие о типе операции, проводимой над данными, и о статусе операции.
• REST-методы следует всегда выполнять в отдельном потоке.
• Следует использовать Apache HTTP client, а не Java URL connection.
• Форматы данных в порядке предпочтения: какой-либо бинарный формат (например, AMF3), затем JSON, затем XML.
• Желательно включать gzip. GZip на Android реализован “нативно”, библиотека быстрая. В некоторых случаях можно получить коэффициент сжатия 5:1 и даже 10:1, в зависимости от количества получаемых данных. Использование GZip ускоряет загрузку данных и экономит батарею.
• Если используете Sqlite — используйте транзакции.
• Если программе требуется скачать 10-20 картинок, не стоит запускать 10-20 параллельных закачек. Запускайте 1-3, а остальные ставьте в очередь.
• Activity регистрирует binder callback (т.е. ResultReceiver), для получения ответа от сервиса. Этот callback нужно обязательно удалить при вызове onPause у Activity, иначе можно налететь на ANR.
• Длительные операции всегда следует запускать из сервиса. Сервис обязательно следует останавливать после того, как требуемые операции выполнены.
• Необходимо минимизировать сетевой трафик.
• Следует разбивать данные на страницы (конечно, если REST Api предоставляют такую возможность).
• Для некритичной по времени синхронизации данных между клиентом и сервером рекомендуется использовать SyncAdapter.

Алгоритм фомирования запроса к серверу

В общем случае, при выполнении запроса к REST-серверу, требуется выполнить ряд операций:

• сформировать URL
• задать HTTP-заголовки
• выбрать тип HTTP-запроса
• сформировать тело HTTP-запроса, т.е. преобразовать Java объект в JSON
• выполнить запрос, воспользовавшись HTTP-клиентом
• распарсить результаты запроса — преобразовать полученный JSON в Java объект

Источник