2.09. Веб-сервисы
Веб-сервисы
Происхождение термина «сервис»
Термин «сервис» (от лат. servitium — служба, подчинение) исторически обозначает действие, совершаемое одним субъектом в интересах другого. В контексте вычислительных систем понятие «сервис» унаследовало эту семантику: это программная функциональность, предоставляемая одной программной сущностью (провайдером) по запросу другой (клиента) с соблюдением заранее определённого контракта. Слово «сервер», в свою очередь, происходит от французского servir — «служить», и этимологически укрепляет связь между понятиями «служить» и «предоставлять». В архитектуре распределённых систем сервер — это именно субъект, оказывающий услугу другим участникам взаимодействия.
Таким образом, «веб-сервис» — это строго определённая программная возможность, экспонированная через веб-интерфейс и используемая в парадигме «запрос–ответ» или «публикация–подписка», при этом соблюдается принцип чёткого разграничения ответственности: клиент формулирует потребность, сервис реализует логику её удовлетворения. Важно подчеркнуть: веб-сервис не требует от клиента знания внутреннего устройства реализации — достаточно понимания контракта, который определяет входные и выходные данные, допустимые состояния и возможные ошибки. Это принцип инкапсуляции, перенесённый из объектно-ориентированного программирования в область сетевых взаимодействий.
Определение веб-сервиса как архитектурного паттерна
Веб-сервис — это программный компонент, реализующий конкретную бизнес-функцию или техническую операцию, доступный через стандартные веб-протоколы, прежде всего HTTP/HTTPS, и предоставляющий взаимодействие посредством машиночитаемых сообщений. Такое определение подчеркивает три ключевых аспекта:
- Функциональная обособленность: веб-сервис реализует одну или несколько связанных операций, составляющих логически завершённую задачу — например, проверку баланса счёта, конвертацию валюты, идентификацию пользователя.
- Стандартизация транспорта: веб-сервис использует открытые, широко распространённые сетевые протоколы, в первую очередь HTTP(S), что обеспечивает совместимость с любыми платформами и языками программирования, способными выполнять HTTP-запросы.
- Машиночитаемость контракта: взаимодействие между клиентом и веб-сервисом строится на форматированных данных — XML, JSON или специализированных бинарных форматах, что позволяет автоматизировать вызовы и обработку результатов.
Это отличает веб-сервисы от традиционных веб-сайтов, ориентированных на визуальное представление информации человеку. Веб-сервисы предназначены для программного потребления — они являются «кирпичами», из которых строятся распределённые приложения, составные системы и сложные цифровые экосистемы.
Следует также проводить чёткое разграничение между веб-сервисом как концепцией и веб-API как её реализацией. Любой веб-API — это интерфейс к веб-сервису, но не всякий веб-API подразумевает соблюдение всех формальных признаков веб-сервиса (например, машинно-интерпретируемый контракт в виде WSDL или OpenAPI). В то же время в инженерной практике оба термина часто используются как синонимы, хотя концептуально веб-сервис шире.
Историческое развитие парадигмы веб-сервисов
Идея программного взаимодействия через сеть существовала задолго до появления World Wide Web. Удалённые вызовы процедур (RPC), CORBA, DCOM — всё это были попытки стандартизировать межпроцессное взаимодействие в распределённых системах. Однако эти решения страдали от привязки к платформам, сложности настройки и отсутствия универсального транспорта. Появление HTTP как простого, статус-ориентированного протокола с широкой поддержкой на всех уровнях сетевого стека (от браузеров до файрволов) создало предпосылки для нового подхода.
Первые спецификации веб-сервисов (SOAP, WSDL, UDDI), появившиеся в конце 1990-х — начале 2000-х годов, стремились к максимальной формализации: машинно-интерпретируемый контракт, строгая типизация данных, встроенная поддержка безопасности и транзакций. Однако сложность и избыточность SOAP-стека привели к появлению альтернативного подхода — REST (Representational State Transfer), предложенного Ройем Филдингом в 2000 году как архитектурный стиль, а не протокол. REST-подход опирался на естественные свойства HTTP (методы, коды состояний, заголовки) и стал доминирующим в эпоху мобильных приложений и облачных сервисов.
Таким образом, эволюция веб-сервисов — это путь от жёстко формализованных, самодокументируемых, но громоздких систем к лёгким, гибким и ориентированным на разработчика API, основанным на простых текстовых форматах и принципах REST.
Классификация веб-сервисов
Веб-сервисы можно классифицировать по нескольким критериям. Наиболее значимыми являются:
По архитектурному стилю
-
SOAP-ориентированные веб-сервисы
Основаны на протоколе SOAP (Simple Object Access Protocol) — XML-базированном протоколе обмена сообщениями. Характеризуются:- Использованием WSDL (Web Services Description Language) для описания интерфейса;
- Поддержкой WS-* стандартов (WS-Security, WS-ReliableMessaging, WS-Transaction и др.);
- Строгой типизацией и схемами XSD;
- Поддержкой асинхронных вызовов и сообщений с гарантированной доставкой;
- Высокой степенью формальности и самодокументируемости.
Такие сервисы часто применяются в корпоративных системах, финансовых институтах, государственных структурах, где важны детерминированность, безопасность и соответствие регуляторным требованиям.
-
RESTful-сервисы
Следуют архитектурному стилю REST и используют HTTP как платформу. Характеризуются:- Идентификацией ресурсов через URI;
- Использованием стандартных HTTP-методов (GET, POST, PUT, DELETE и др.);
- Отсутствием состояния на стороне сервера (statelessness);
- Представлением ресурсов в форматах JSON, XML или других (чаще всего JSON);
- Гипермедиа как движущей силой состояния (HATEOAS), хотя на практике этот принцип часто опускается.
RESTful-сервисы доминируют в современной веб- и мобильной разработке благодаря простоте, масштабируемости и удобству для разработчиков.
-
GraphQL-сервисы
Являются относительно новым подходом, предложенным Facebook в 2015 году. В отличие от REST, где клиент запрашивает фиксированные ресурсы по заданным эндпоинтам, GraphQL предоставляет единую точку входа, через которую клиент описывает структуру желаемых данных. Это позволяет:- Избегать избыточной передачи данных (over-fetching);
- Устранять множественные запросы для сбора связанных сущностей (N+1 problem);
- Динамически адаптировать ответ под нужды клиента.
Однако GraphQL требует более сложной серверной логики и тщательного контроля за сложностью запросов (защита от злонамеренных или рекурсивных запросов).
-
gRPC-сервисы
Разработаны Google как высокопроизводительная система удалённых вызовов на основе протокола HTTP/2 и бинарного формата сериализации Protocol Buffers. Характеризуются:- Строгой контрактностью через
.proto-файлы; - Поддержкой потоковой передачи данных;
- Высокой производительностью и низкой задержкой;
- Межъязыковой совместимостью.
gRPC активно используется во внутренней микросервисной архитектуре, особенно в облачных и высоконагруженных системах.
- Строгой контрактностью через
По модели взаимодействия
- Синхронные веб-сервисы: клиент блокируется до получения ответа. Это типично для REST и SOAP.
- Асинхронные веб-сервисы: клиент получает подтверждение приёма запроса, а результат доставляется позже — через callback, webhook, очередь сообщений или событийную шину. Такие модели характерны для интеграций длительных операций (например, обработка видео, генерация отчётов).
По степени детерминированности
- Идемпотентные сервисы: повторный вызов с теми же параметрами не изменяет состояние системы (например, GET-запросы в REST).
- Неидемпотентные сервисы: каждый вызов может приводить к изменению состояния (например, POST-запросы на создание сущности).
По области применения
- Публичные (открытые) веб-сервисы — доступны любому разработчику (например, API Google Maps, OpenWeatherMap);
- Частные (внутренние) веб-сервисы — используются внутри организации или между доверенными партнёрами (например, микросервисы в архитектуре ELMA365);
- Партнёрские веб-сервисы — доступны только авторизованным внешним участникам по соглашению (например, API банка для интеграции с бухгалтерскими системами).