Перейти к основному содержимому

Веб-сервисы

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Всем

Веб-сервисы​

Веб-сервис - это программа, которая живёт на сервере и отвечает на запросы других программ через интернет. Мы её не видим (нет никакой кнопки или картинки), но наше приложение с ней разговаривает.

Когда мы приходим к автомату с кофе, нажимаем на кнопку "Латте", мы - клиент. Автомат (веб-сервис) получает запрос, варит кофе, и выдаёт нам стаканчик (ответ). Да, внутри автомат - это сложная штука с водонагревателем, кофемолкой, насосом. Но нам плевать, как он устроен, мы знаем лишь, что если нажать кнопку и кинуть монетку, то получим кофе.

Веб-сервис как раз такая "услуга". Наша программа отправляет запрос на URL, веб-сервис получает запрос и что-то там считает, лезет в базу, отправляет письмо, может даже общается с другими программами. Но наша, запросившая программа, получает лишь от веб-сервиса ответ (обычно в формате JSON, потому что он лёгкий и быстрый).

Без веб-сервисов нам было бы тяжко. Именно благодаря им:

  • наш сайт может узнать погоду через API Яндекса;
  • наше приложение может отправить платёж через сервис;
  • наш бот в Telegram может вызвать веб-сервис с курсами валют;
  • разные программы внутри компании обмениваются данными через внутренние веб-сервисы.

Любому бэкенд-разработчику ПРИДЁТСЯ работать с веб-сервисами.

Пример:

  1. Мы открыли приложение, нажали кнопку, а оно отправило запрос:
GET https://api.weather.example/v1/forecast?city=Moscow
  1. Веб-сервис погоды получает запрос, лезет в свою базу, собирает данные;
  2. Присылает ответ:
{
  "city": "Moscow",
  "temp": -5,
  "condition": "облачно"
}
  1. Приложение показывает на экране: Москва, -5°, облачно.

Один сайт может использовать кучу веб-сервисов внутри себя. Например, когда мы заходим в интернет-магазин, он вызывает сервис корзины, сервис каталога, сервис рекомендаций.

Сервисы бывают следующих видов:

  • REST - делает запросы базового характера, положить, взять, удалить (GET /users/123);
  • GraphQL - мы сами описываем, какие поля нужны, как в SQL;
  • gRPC - быстро, но сложно, используя двоичные данные вместо JSON;
  • SOAP - громоздко, на XML, но очень формально.

Программы вызывают веб-сервисы, обычно, через библиотеки. Например, requests в Python, axios в JavaScript, HttpClient в C#. Пример на Python:

import requests

response = requests.get("https://api.weather.example/v1/forecast?city=Moscow")
Данные = response.json()  # распарсили JSON

print(f"Температура: {Данные['temp']}°")

И всё. Вот и запрос - как раз по адресу и сервис погоды.

У веб-сервисов есть контракт - документ (или схема), где написано, какие запросы принимать, какие данные ждать и что отвечать.

Так что веб-сервис является обслуживающей программой без интерфейса для других программ.

Происхождение термина «сервис»​

Термин «сервис» (от лат. servitium — служба, подчинение) исторически обозначает действие, совершаемое одним субъектом в интересах другого. В контексте вычислительных систем понятие «сервис» унаследовало эту семантику: это программная функциональность, предоставляемая одной программной сущностью (провайдером) по запросу другой (клиента) с соблюдением заранее определённого контракта. Слово «сервер», в свою очередь, происходит от французского servir — «служить», и этимологически укрепляет связь между понятиями «служить» и «предоставлять». В архитектуре распределённых систем сервер — это именно субъект, оказывающий услугу другим участникам взаимодействия.

Таким образом, «веб-сервис» — это строго определённая программная возможность, экспонированная через веб-интерфейс и используемая в парадигме «запрос–ответ» или «публикация–подписка», при этом соблюдается принцип чёткого разграничения ответственности: клиент формулирует потребность, сервис реализует логику её удовлетворения. Важно подчеркнуть: веб-сервис не требует от клиента знания внутреннего устройства реализации — достаточно понимания контракта, который определяет входные и выходные данные, допустимые состояния и возможные ошибки. Это принцип инкапсуляции, перенесённый из объектно-ориентированного программирования в область сетевых взаимодействий.

Определение веб-сервиса как архитектурного паттерна​

Веб-сервис — это программный компонент, реализующий конкретную бизнес-функцию или техническую операцию, доступный через стандартные веб-протоколы, прежде всего HTTP/HTTPS, и предоставляющий взаимодействие посредством машиночитаемых сообщений. Такое определение подчеркивает три ключевых аспекта:

  1. Функциональная обособленность: веб-сервис реализует одну или несколько связанных операций, составляющих логически завершённую задачу — например, проверку баланса счёта, конвертацию валюты, идентификацию пользователя.
  2. Стандартизация транспорта: веб-сервис использует открытые, широко распространённые сетевые протоколы, в первую очередь HTTP(S), что обеспечивает совместимость с любыми платформами и языками программирования, способными выполнять HTTP-запросы.
  3. Машиночитаемость контракта: взаимодействие между клиентом и веб-сервисом строится на форматированных данных — 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.

Классификация веб-сервисов​

Веб-сервисы можно классифицировать по нескольким критериям. Наиболее значимыми являются:

По архитектурному стилю​

  1. SOAP-ориентированные веб-сервисы
    Основаны на протоколе SOAP (Simple Object Access Protocol) — XML-базированном протоколе обмена сообщениями. Характеризуются:

    • Использованием WSDL (Web Services Description Language) для описания интерфейса;
    • Поддержкой WS-* стандартов (WS-Безопасность, WS-ReliableMessaging, WS-Transaction и др.);
    • Строгой типизацией и схемами XSD;
    • Поддержкой асинхронных вызовов и сообщений с гарантированной доставкой;
    • Высокой степенью формальности и самодокументируемости.

    Такие сервисы часто применяются в корпоративных системах, финансовых институтах, государственных структурах, где важны детерминированность, безопасность и соответствие регуляторным требованиям.

  2. RESTful-сервисы
    Следуют архитектурному стилю REST и используют HTTP как платформу. Характеризуются:

    • Идентификацией ресурсов через URI;
    • Использованием стандартных HTTP-методов (GET, POST, PUT, DELETE и др.);
    • Отсутствием состояния на стороне сервера (statelessness);
    • Представлением ресурсов в форматах JSON, XML или других (чаще всего JSON);
    • Гипермедиа как движущей силой состояния (HATEOAS), хотя на практике этот принцип часто опускается.

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

  3. GraphQL-сервисы
    Являются относительно новым подходом, предложенным Facebook в 2015 году. В отличие от REST, где клиент запрашивает фиксированные ресурсы по заданным эндпоинтам, GraphQL предоставляет единую точку входа, через которую клиент описывает структуру желаемых данных. Это позволяет:

    • Избегать избыточной передачи данных (over-fetching);
    • Устранять множественные запросы для сбора связанных сущностей (N+1 problem);
    • Динамически адаптировать ответ под нужды клиента.

    Однако GraphQL требует более сложной серверной логики и тщательного контроля за сложностью запросов (защита от злонамеренных или рекурсивных запросов).

  4. gRPC-сервисы
    Разработаны Google как высокопроизводительная система удалённых вызовов на основе протокола HTTP/2 и бинарного формата сериализации Protocol Buffers. Характеризуются:

    • Строгой контрактностью через .proto-файлы;
    • Поддержкой потоковой передачи данных;
    • Высокой производительностью и низкой задержкой;
    • Межъязыковой совместимостью.

    gRPC активно используется во внутренней микросервисной архитектуре, особенно в облачных и высоконагруженных системах.

По модели взаимодействия​

  • Синхронные веб-сервисы: клиент блокируется до получения ответа. Это типично для REST и SOAP.
  • Асинхронные веб-сервисы: клиент получает подтверждение приёма запроса, а результат доставляется позже — через callback, webhook, очередь сообщений или событийную шину. Такие модели характерны для интеграций длительных операций (например, обработка видео, генерация отчётов).

По степени детерминированности​

  • Идемпотентные сервисы: повторный вызов с теми же параметрами не изменяет состояние системы (например, GET-запросы в REST).
  • Неидемпотентные сервисы: каждый вызов может приводить к изменению состояния (например, POST-запросы на создание сущности).

По области применения​

  • Публичные (открытые) веб-сервисы — доступны любому разработчику (например, API Google Maps, OpenWeatherMap);
  • Частные (внутренние) веб-сервисы — используются внутри организации или между доверенными партнёрами (например, микросервисы в архитектуре ELMA365);
  • Партнёрские веб-сервисы — доступны только авторизованным внешним участникам по соглашению (например, API банка для интеграции с бухгалтерскими системами).

См. также

Другие статьи этого же раздела в боковом меню (как на странице «О разделе»).

Ещё 9 статей в разделе

Освоение главы0%