Введение
Периодически, сталкиваясь с различными веб-сервисами, я задаюсь вопросом: «Зачем было так все усложнять?». Мы много внимания уделяем процессам разработки, чистоте кода, тестам и методологиям. Пишем комментарии и создаем документации. Но при этом слишком мало внимания уделяем основообразующим внешним системным интерфейсам – веб-сервисам.
Все нижесказанное можно относить к веб-сервисам различных видов, но в основе своей я буду говорить о веб-сервисах SOAP.
Использование
В современном мире веб-сервисы используются повсеместно. Каждый день кто-то отрывает для всего мира свое API. Публикует документацию и ждет притока посетителей.
По сервисам пользователи узнают погоду, получают информацию о пробках, читают свежие новости и узнают о событиях. Все социальные проекты, такие как facebook, twitter, vk, google, открывают доступ по веб-сервисам своим пользователям. Сразу же появляется множество удобных программ-клиентов. Кто бы мог подумать, что человек сможет поделиться своими переживаниями и мыслями в любом месте и в любое время.
Все больше государственных служб обзаводятся такими же сервисами. По ним можно оплачивать штрафы, получать ценную информацию, писать заявления и получать услуги.
Сервисы все сильнее связывают информационные системы, которые нас окружают.
Разнообразие
Технологии, на основе которых реализуются сервисы, очень разнообразны. Здесь и Rest-сервисы, Soap, криптография, различные протоколы передачи данных, технологии сжатия данных, синхронная\асинхронная передача данных, гарантированная доставка.
Все это усугубляется разными версиями технологий и сервисов. Чтобы создать совместимые системы, надо приложить много усилий.
Кто в лес, а кто…
А вот как использовать все это многообразие? Тут мнения расходятся. Но можно смело утверждать, что множество сервисов, на самом деле, таковыми не являются. Проще всего проверить это с помощью ряда утверждений:
Это веб-сервис, если:
- Для него можно создать самодостаточные классы автоматизированными средствами в большинстве популярных языков (java, .net, python, ruby, c++ и пр.);
- Для него не нужна дополнительная документация;
- Чтобы им воспользоваться не нужно дополнительных манипуляций (открыть порт по telnet, загрузить к себе схемы и пр.)
- Используются только общепринятые технологии
- Весь интерфейс сервиса описан в нем самом (wsdl, xsd). Никаких any-type. Все типы точно определены
- Определены все типы с помощью пространств имен
- Для сжатия данных используется MTOM.
- Используются стандартные заголовки гарантированной доставки, авторизации и пр.
- Кодировка UTF и никакой кириллицы и прочих символов в описаниях типов
Это не сервис, если:
- Для использования сервиса необходима дополнительная информация
- Wsdl и xsd не описывают полностью интерфейс сервиса.
- Используются any-type
- Маршрутизация сообщений выполняется с помощью soap-action
- Для сжатия данных используется zip
- Вложения группируются и упаковываются в один элемент
- Неверно определены или не определены пространства имен
- Для сервиса невозможно создать классы автоматизированными средствами
- Для использования сервиса необходимо писать дополнительный код (упаковка данных и пр.)
- При запросах передается дублирующаяся информация (записать ФИО в трех четырех местах запроса)
- В запросах необходимо заполнять необязательные атрибуты (системные атрибуты и пр.), которые не нужны с точки зрения получения информации («отправьте в этом атрибуте вот это, иначе наша система не поймет запрос»).
- Используются форматы, которые не поддерживаются большинством клиентов
- Для получения информации надо делать несколько запросов в рамках одного поставщика («сначала отсюда получаем вот эту строку, а затем делаем запрос вот сюда…»)
- На запросы в один сервис могут быть получены различные ответы (различные форматы ответов)
- Сервис имеет сложнейшую структуру, которая используется для всех запросов. Лучше иметь 10 простых точек входа, чем одну универсальную.
- Имеются атрибуты двойственного назначения
- Системная информация передается в теле(body) сообщения, а не заголовке(header). Тело сообщения должно содержать только данные запроса.
- Используются нестандартные заголовки для аутентификации, маршрутизации, гарантированной доставки.
Единая точка входа
Хорошо спроектированный сервис – самодостаточен. Он сам описывает свой, однозначно интерпретируемый, интерфейс. Для него просто создать классы и можно сразу начать пользоваться. В коде клиента выполняется только заполнение атрибутов запроса, никаких дополнительных манипуляций. Структура данных сервиса проста и понятна.
Все так же как в коде. Минимальный уровень вложенности, самодокументируемость, система логичных имен элементов и типов (SampleRequest в ответе выглядит шокирующе…).
Все сервисы, которые не соответствуют этим требованиям можно назвать только имитациями. Конечно, они похожи, но если сервис никто не может использовать, то это проблема поставщика данных.
Сжатие или оптимизация
Тут уже все придумано. Передаем base64. Многовато? Тогда используем MTOM. Все равно много? По веб сервисам не передают гигабайты, очнитесь! Передавайте ссылки на быстрые файловые хранилища. Когда клиенту понадобятся ваши фото, документы, архивы и другая медиа-информация – он ее скачает. Не нужна ему дополнительная нагрузка в 20 мегабайт на запрос. По сервисам передается текстовая информация, все остальное передавать не разумно.
Если компания не использует свой продукт, то он ничего не стоит
Если поставщик сервиса сам им не пользуется, если использует какие-либо особенные регламенты взаимодействия, если в регламенте вводит для себя некоторые привилегии — то этим сервисом по определению пользоваться невозможно. Поставщик создал непонятный сервис, что сам не может с ним работать. На такие сервисы без грусти не взглянешь…
Заключение
Где я нашел такие сервисы? Да они повсеместно! Даже у крупных игроков есть непонятные технические решения. Лишь имея грамотно построенные сервисы, можно добиться высокой степени интегрированности и стабильности множества разнородных систем.
