Новый формат
Веб-сервисы: что это и зачем они сайтам
Веб-сервис — программный интерфейс по сети: один ресурс отдаёт или принимает данные по понятным правилам, другой их использует. Для пользователя это «магия» агрегатора туров или оплаты на сайте; для разработки — контракт между системами.
Ниже — идея архитектуры, где сервисы применяют и на что смотреть бизнесу. Устаревшие акценты на UDDI/SOAP из гайдов 2000-х не раздуваем: сегодня чаще REST, JSON и готовые API платёжек, доставки, CRM.
Что делает веб-сервис
У сервиса есть адрес (endpoint), правила запроса/ответа и обычно идентификация (ключ, OAuth). Клиент (ваш сайт, мобильное приложение, другой сервер) вызывает метод и получает структурированный ответ.
Классический пример: агрегатор авиабилетов или туров запрашивает наличие и цены у поставщиков через их API и показывает сводную выдачу, не копируя вручную каждый сайт.
Участники упрощённо:
- поставщик данных/операций (исполнитель);
- потребитель (ваш сайт, приложение, партнёр);
- контракт: формат, ошибки, лимиты, авторизация.
Архитектура без ностальгии по UDDI
Под капотом всегда сеть и протоколы (TCP/IP, HTTP/HTTPS). Данные чаще упаковывают в JSON; XML/SOAP остаются там, где так требует контрагент.
Старые обзоры много писали про UDDI-каталоги и WSDL. Для малого и среднего digital важнее понятная документация API, песочница, стабильные версии и мониторинг ошибок — а не теория реестров 2000-х.
На что смотреть при выборе/заказе интеграции:
- есть ли актуальная документация и примеры;
- лимиты запросов и SLA;
- как обновляются цены/остатки;
- безопасность ключей и логирование;
- что происходит при простое провайдера.
Где используют
Оплата и касса, доставка и трекинг, CRM и рассылки, телефония, карты и геокодинг, маркетплейсы и товарные фиды, обмен с 1С/ERP — типичный контур современного сайта.
Выгода для бизнеса:
- меньше ручного переноса данных;
- единый источник правды по остаткам и статусам;
- быстрее подключать новые каналы продаж;
- можно менять фронт, не ломая учёт, если контракт API стабилен.
Частые вопросы
Веб-сервис = сайт?
Нет. Сайт — интерфейс для людей. Сервис — интерфейс для программ (часто JSON/XML по HTTP). Иногда у сервиса есть и документация в браузере.
Что такое API?
Набор методов и форматов обмена. «Веб-сервис» в быту часто синоним HTTP API.
Зачем это интернет-магазину?
Оплата, доставка, остатки, Маркет/фиды, CRM, телефония — почти всё стыкуется сервисами, а не копипастом вручную.
SOAP ещё жив?
В корпоративных контурах встречается. Для новых интеграций чаще REST/JSON. Выбор зависит от контрагента, не от моды статьи.
Чем опасны интеграции?
Простои чужого API, смена форматов, ключи в открытом доступе, рассинхрон остатков/цен. Нужны мониторинг, права и ответственность за данные.
Агрегатор — это веб-сервис?
Агрегатор — продукт. Он обычно ходит в сервисы поставщиков, собирает данные и отдаёт витрину пользователю.
Нужен ли свой сервис с нуля?
Не всегда. Часто хватает готовых API (оплата, почта, карты). Свой — когда уникальная логика или нет подходящего провайдера.
