Что такое веб сервис

Что такое веб-сервис и их виды?

Веб-сервис (англ. web service) — идентифицируемая веб-адресом программная система со стандартизированными интерфейсами. Веб-службы могут взаимодействовать друг с другом и со сторонними приложениями посредством сообщений, основанных на определённых протоколах. В обиходе веб-сервисами называют услуги, оказываемые в Интернете.

FTP (File Transfer Protocol)

FTP (англ. File Transfer Protocol — протокол передачи файлов) — стандартный протокол, предназначенный для передачи файлов по TCP-сетям (например, Интернет). FTP часто используется для загрузки сетевых страниц и других документов с частного устройства разработки на открытые сервера хостинга.

SSH (Secure Shell)

SSH (англ. Secure SHell — «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов). Схож по функциональности с протоколами Telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли. SSH допускает выбор различных алгоритмов шифрования. SSH-клиенты и SSH-серверы доступны для большинства сетевых операционных систем.

TELNET (англ. TErminaL NETwork) — сетевой протокол для реализации текстового интерфейса по сети (в современной форме — при помощи транспорта TCP). Название «telnet» имеют также некоторые утилиты, реализующие клиентскую часть протокола.

SMTP (Send Mail Transfer Protocol)

SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи почты) — это широко используемый сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.

DNS (Domain Name Service)

DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).

DHCP (Dynamic Host Control Protocol)

DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической конфигурации узла) — это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Данный протокол работает по модели «клиент-сервер». Для автоматической конфигурации компьютер-клиент на этапе конфигурации сетевого устройства обращается к так называемому серверу DHCP, и получает от него нужные параметры. Сетевой администратор может задать диапазон адресов, распределяемых сервером среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок. Протокол DHCP используется в большинстве сетей TCP/IP.

HTTP (HyperText Transfer Protocol)

HTTP (англ. HyperText Transfer Prоtocоl — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

POP3 (Post Office Protocol, version 3)

POP3 (англ. Post Office Protocol Version 3 — протокол почтового отделения, версия 3) — стандартный Интернет-протокол прикладного уровня, используемый клиентами электронной почты для извлечения электронного сообщения с удаленного сервера по TCP/IP-соединению.

SFTP (Secure File Transfer Protocol)

SFTP (англ. SSH File Transfer Protocol) — протокол прикладного уровня, предназначенный для копирования и выполнения других операций с файлами поверх надёжного и безопасного соединения. Протокол разработан группой IETF как расширение к SSH-2, однако SFTP допускает реализацию и с использованием иных протоколов сеансового уровня.

NNTP (Network New Transfer Protocol)

NNTP (англ. Network News Transfer Protocol) — представляет собой сетевой протокол, распространения, запрашивания, размещения и получения групп новостей при взаимодействии между сервером групп новостей и клиентом.

NTP (Network Time Protocol)

Network Time Protocol (NTP) — сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной латентностью.

NetBIOS (Network Basic Input/Output System) — протокол для работы в локальных сетях на персональных ЭВМ типа IBM/PC, разработан в виде интерфейса, который не зависит от фирмы-производителя. Был разработан фирмой Sytek Corporation по заказу IBM в 1983 году. Он включает в себя интерфейс сеансового уровня (англ. NetBIOS interface), в качестве транспортных протоколов использует TCP и UDP.

IMAP (Internet Message Access Protocol)

IMAP (англ. Internet Message Access Protocol) — протокол прикладного уровня для доступа к электронной почте.

SNMP (Simple Network Management Protocol)

SNMP (англ. Simple Network Management Protocol — простой протокол сетевого управления) — стандартный интернет-протокол для управления устройствами в IP-сетях на основе архитектур UDP/TCP. К поддерживающим SNMP устройствам относятся маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры, модемные стойки и другие. Протокол обычно используется в системах сетевого управления для контроля подключенных к сети устройств на предмет условий, которые требуют внимания администратора. SNMP определен Инженерным советом интернета (IETF) как компонент TCP/IP. Он состоит из набора стандартов для сетевого управления, включая протокол прикладного уровня, схему баз данных и набор объектов данных.

LDAP (Lightweight Directory Access Protocol)

LDAP (англ. Lightweight Directory Access Protocol — «облегчённый протокол доступа к каталогам») — протокол прикладного уровня для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции авторизации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей.

SSL (Secure Socket Layer)

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

NFS (Network File System)

Network File System (NFS) — протокол сетевого доступа к файловым системам, первоначально разработан Sun Microsystems в 1984 году. Основан на протоколе вызова удалённых процедур. Позволяет подключать (монтировать) удалённые файловые системы через сеть.

MySQL — свободная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems, которая ранее приобрела шведскую компанию MySQL AB. Продукт распространяется как под GNU General Public License, так и под собственной коммерческой лицензией. Помимо этого разработчики создают функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

Virtual Network Computing (VNC) — система удалённого доступа к рабочему столу компьютера, использующая протокол RFB (англ. Remote FrameBuffer, удалённый кадровый буфер). Управление осуществляется путём передачи нажатий клавиш на клавиатуре и движений мыши с одного компьютера на другой и ретрансляции содержимого экрана через компьютерную сеть.

Веб-сервисы в теории и на практике для начинающих

Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.

Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.

С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых.

Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.

Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.

По сути, веб-сервисы — это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети.

Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).

Протоколы веб-сервисов

На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:

SOAP (Simple Object Access Protocol) — по сути это тройка стандартов SOAP/WSDL/UDDI
REST (Representational State Transfer)
XML-RPC (XML Remote Procedure Call)

На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.

Безусловно, существуют и иные протоколы, но, поскольку они не получили широкого распространения, мы остановимся в этом кратком обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем.

Нас в первую очередь интересуют вопросы создания новых веб-служб, а не реализация клиентов к существующим (как правило поставщики веб-сервисов поставляют пакеты с функциями API и документацией, посему вопрос построения клиентов к существующим веб-службам менее интересен с точки зрения автора).

SOAP против REST

Проблемы данного противостояния хорошо описаны в статье Леонида Черняка, найденой на портале www.citforum.ru.

По мнению же автора, кратко можно выделить следующее:

SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.

В любом случае вам решать, что больше подойдет вашему приложению. Вполне вероятно, вы даже захотите реализовать оба протокола, чтобы оставить выбор за пользователями службы и — это ваше право.

Практическое применение веб-сервисов

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

Допустим, нам необходимо создать службу, предоставляющую доступ к информации о курсах валют, которая собирается нашим приложением, и накапливается в базе данных. Далее посредством веб-сервиса, данная информация передается сторонним приложениям для отображения в удобном для них виде.

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

Этап первый — реализация приложения сбора информации о курсах валют.

Информацию о курсах валют мы будем собирать со страниц сайта НБУ (Национального Банка Украины) ежедневно и складывать в базу данных под управлением СУБД MySQL.

Создадим структуру данных.

Таблица валют (currency):

+-------------+------------------+ | Field | Type | +-------------+------------------+ | code | int(10) unsigned | | charcode | char(3) | | description | varchar(100) | | value | int(10) unsigned | | base | tinyint(1) | +-------------+------------------+

Таблица номиналов обмена (exchange):

+------------+------------------+ | Field | Type | +------------+------------------+ | id | bigint(20) ai | | rate_date | timestamp | | rate_value | float | | code | int(10) unsigned | +------------+------------------+

Для работы с базой данных воспользуемся ORM слоем на базе пакета PHP Doctrine. Реализуем граббер:

класс Grubber (models/Grabber.php):

([A-Z]+)(\d+)(.+?)(\d+\.\d+)/i', $content, $m) == false) < throw new Exception( 'Can not parse data!'); >/** * Preformatting data to return; */ $data = array(); foreach ($m[1] as $k => $code) < $data[] = array( 'code' =>$code, 'charcode' => $m[2][$k], 'value' => $m[3][$k], 'description' => $m[4][$k], 'rate_value' => $m[5][$k] ); > return $data; > public static function run() < $data = self::getData(); /** * Sets default currency if not exists */ if (!Doctrine::getTable( 'Currency')->find( 980)) < $currency = new Currency(); $currency->setCode( 980) ->setCharcode( 'UAH') ->setDescription( 'українська гривня') ->setValue( 1) ->setBase( 1) ->save(); > foreach ($data as $currencyData) < /** * Updating table of currencies with found values */ if (!Doctrine::getTable( 'Currency')->find( $currencyData['code'])) < $currency = new Currency(); $currency->setCode( $currencyData['code']) ->setCharcode( $currencyData['charcode']) ->setDescription( $currencyData['description']) ->setValue( $currencyData['value']) ->setBase( 0) ->save(); > /** * Updating exchange rates */ $date = date( 'Y-m-d 00:00:00'); $exchange = new Exchange(); $exchange->setRateDate( $date) ->setRateValue( $currencyData['rate_value']) ->setCode( $currencyData['code']) ->save(); > > > ?>

и сам граббер (grabber.php):

Теперь заставим наш граббер отрабатывать раз в сутки в 10:00 утра, путем добавления команды запуска граббера в таблицы cron:

0 10 * * * /usr/bin/php /path/to/grabber.php

Все — у нас есть достаточно полезный сервис.

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

Реализация SOAP сервиса

Для реализации веб-сервиса на базе SOAP протокола, мы воспользуемся встроенным пакетом в PHP для работы с SOAP.

Поскольку наш веб-сервис будет публичным, хорошим вариантом будет создание WSDL файла, который описывает структуру нашего веб-сервиса.

WSDL (Web Service Definition Language) — представляет из себя XML файл определенного формата. Подробное описание синтаксиса можно найти здесь.

На практике будет удобно воспользоваться функцией автоматической генерации файла, которую предоставляет IDE Zend Studio for Eclipse. Данная функция позволяет генерировать WSDL файл из классов PHP. Поэтому, прежде всего, мы должны написать класс, реализующий функциональность нашего сервиса.

класс CurrencyExchange (models/CurrencyExchange.php):

find( $code); $exchange = $currency->getExchange( $date); return $exchange ? (float)$exchange->getRateValue() : null; > /** * Retrievs all available currencies * * @return array - list of all available currencies */ public function getCurrencyList() < return Doctrine::getTable( 'Currency')->findAll()->toArray(); > > ?>

Отметим, что для автоматической генерации WSDL, нам необходимо написать комментарии в стиле javadoc, потому что именно в них мы прописываем информацию о типах принимаемых аргументов и возвращаемых значений. Неплохо также описывать в нескольких словах работу методов — ведь WSDL послужит описанием API для сторонних разработчиков, которые будут использовать ваш веб-сервис.

Не пишите в докблоках param void или return void — для WSDL это не критично, но вот при реализации REST доступа к тому-же классу у вас возникнут проблемы.

Теперь в Zend Studio входим в меню File->Export. выбираем PHP->WSDL, добавляем наш класс, прописываем URI-адрес нашего сервиса и создаем WSDL-файл. Результат должен быть примерно таким: http://mikhailstadnik.com/ctws/currency.wsdl

Если вы будете добавлять новую функциональность в ваш веб-сервис, вам нужно будет пересоздавать WSDL-файл. Но здесь не так все гладко. Следует учитывать, что SOAP-клиент, который уже запрашивал ваш WSDL файл, кеширует его на своей стороне. Поэтому, если вы замените старое содержимое новым в WSDL файле, некторые клиенты его не прочтут. А значит, при добавлении новой функциональности, дописывайте версию в имя вашего файла. И не забудбте обеспечить обратную совместимость для старых клиентов, особенно если вы не являетесь их поставщиком.

С другой стороны, WSDL довольно жестко задает структуру веб-сервиса, а это значит, что, если существует необходимость ограничить функциональность клиента по сравнению с сервером, вы можете не включать определенные методы ваших классов в WSDL. Таким образом они не смогут быть вызваны, несмотря на то, что существуют.

Реализация же самого сервера не предстваляет теперь никакой сложности:

setClass( 'CurrencyExchange'); $server->handle(); ?>

Вы можете попробовать веб-сервис в работе по адресу: http://mikhailstadnik.com/ctws/
Там же доступен тестовый клиент: http://mikhailstadnik.com/ctws/client.php

Код простейшего клиента может быть таким:

getExchange( 840, date( 'Y-m-d')); ?>

Реализация REST сервиса

REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов.

И все же удаленный вызов процедур применим и в REST. Он использует методы PUT, GET, POST, DELETE HTTP протокола для манипуляции объектами. Кардинальное отличие его от SOAP в том, что REST остается HTTP-запросом.

Поскольку в PHP пока еще нет реалзации REST, мы воспользуемся Zend Framwork, в который включена реализация как REST клиента, так и REST севера.

Воспользуемся уже готовым классом CurrencyExchange. Напишем сам сервер:

setClass( 'CurrencyExchange'); $server->handle(); ?>

Как видите все очень сходно и просто.

Однако, следует оговорить, что наш REST-сервис менее защищен, чем SOAP-сервис, так как любой добавленый метод в класс CurrencyExchange при его вызове отработает (сам класс определяет сруктуру сервиса).

Проверим работу нашего сервиса. Для этого достаточно передать параметры вызова метода в сроке GET-запроса:

?method=getExchange&code=840&date=2008-11-29

?method=getExchange&arg1=840&arg2=2008-11-29

При желании или необходимости вы можете самомтоятельно задавать структуру ваших XML ответов для сервиса REST. В этом случае, также будет необходимо позаботиться и о создании определения типа вашего XML документа (DTD — Document Type Definition). Это будет минимальным описанием API вашего сервиса.

Простейший тестовый клиент к REST сервису может быть в нашем случае таким:

getExchange( 840, date( 'Y-m-d'))->get(); if ($result->isSuccess()) < echo 'USD exchange: ' . $result->response; > ?>

В принципе, Zend_Rest на сегодняшний день нельзя назвать наиболее точной реализацией принципов REST. Утрируя, можно говорить о том, что эта реализация свелась к удаленному вызову процедур (RPC), хотя философия REST гораздо шире.

Вы можете скачать пример в исходных кодах c PHP Doctrine и Zend Framework (4,42 Мб).

Заключение

Мы выполнили задачу минимум и показали, что такое веб-сервисы, для чего они нужны и как их реализовывать. Естественно, приведенный пример, возможно, несколько оторван от жизни, но он был выбран лишь в качестве инструмента для объяснения предмета и сущности веб-сервисов.

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

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

Что такое веб-сервисы и как они используются

Чтобы запустить веб-сервис, который понравится пользователям, надо знать, как он работает. Это поможет стартапу правильно ставить задачу разработчикам, контролировать их работу, да и вообще понимать, что нужно именно вашему стартапу. Разбираемся, что такое веб-сервис и как стартаперу его запустить.

Время чтения: 4 минут

Веб-сервис или веб-сайт?

Начнем с понятий. Веб-сервис (web-service) — это программа в интернете, которая оказывает услугу или отвечает на определенное требование пользователя. Например, электронная почта отправляет письма, поисковик Google ищет информацию в интернете, а сайт с погодой показывает прогноз. Веб-сервис , который еще называют веб-службой — это веб-приложение.

Веб-сайт — это тоже веб-приложение, но с другой функциональностью. Это страница или страницы в интернете, которые содержат информацию о чем-то. Бизнес использует оба вида веб-приложений. Например, если у вас тур-агентство, то вам подойдет и веб-сайт, и веб-сервис . Вот как между ними выбрать:

Если собираетесь размещать информацию о компании, контакты представителей, часы работы, в каких направлениях работаете, какие есть акции, то подойдет веб-сайт;
Если пользователь может не только получить информацию, но и подобрать тур на определенные даты, выбрать отель, создать учетную запись , то выбирайте веб-сервис.

Функциональность веб-приложения зависит от его архитектуры. Как она устроена и почему важна для работы веб-сервиса?

Зри в корень: архитектура и протоколы

Архитектура — это набор компонентов веб-приложения и способ взаимодействия между ними. К компонентам веб-приложения относятся:

пользовательский интерфейс;
программный интерфейс (API);
базы данных;
внешние сервисы — помогают веб-сервису реализовывать бизнес-логику. Например, брокер сообщений или эквайринг;
кэш.

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

READ MORE На одном языке с разработчиками: как стартаперу спроектировать приложение от архитектуры до UX

Архитектура и ее компоненты

Фактически архитектура делится на 2 части:

Клиентская (frontend) — то, что видит пользователь на экране;
Серверная (backend) — то, что находится за экраном, т.е. запрограммированная реакция на действия пользователя.

Чтобы представить себе архитектуру веб-сервиса, подумайте об архитектуре здания. Вот вы видите фасад дома: количество этажей, форму окон, крышу, ступеньки и дверь. Это все клиентская часть, фронтенд. А потом вы заходите внутрь и видите, какие там комнаты, как они расположены, из какой комнаты можно пройти в другую, а из какой нельзя. Где есть лестница и куда она ведет. Параллельно замечаете, что вот здесь зря не сделали дверь, ведь так можно быстрее добраться до другой части дома, а здесь можно добавить лестницу, чтобы попасть на мансарду, минуя два этажа. Это уже серверная часть, бэкенд. А если здание плохо спроектировано, то оно вообще может обрушиться.

Примерно так же построен и веб-сервис , с той лишь разницей, что бэкенд пользователям не виден.

Протоколы и технологии

Протокол — это набор правил и способов , по которым происходит взаимодействие между компонентами веб-сервиса , а также между разными веб-сервисами. Обычно веб-сервисы построены на стандартах. Стандарты — это те нормы и правила, которые обеспечивают согласованное взаимодействие веб-приложений. К стандартам и наборам открытых протоколов для обмена информацией относятся :

HTTP, HTTPS, FTP, TCP/IP— сетевые протоколы или протоколы передачи данных;
SSL, TLS— протокол шифрования, нужен для безопасной передачи или хранения данных;
API — набор или описание способов как одна программа может обращаться к другой;
XML и JSON — структурируют информацию для обмена;
WSDL ( Web Services Description Language) — это язык описания веб-сервиса . С помощью него клиентский сервис понимает, как можно пользоваться веб-сервисом;
SOAP — это простой протокол доступа к объектам. Он работает через HTTP и позволяет взаимодействовать приложениям на его основе.

Как работает веб-сервис на примере банка

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

Разберем как работает веб-сервис на примере заявки клиента на выпуск кредитной карты в банке. Банку надо разгрузить операторов, которые формируют и обрабатывают заявки. Для этого сделали веб-приложение :

1. Пользователь заходит на сайт банка и переходит на страницу с формой заявки. Заполняет ее и нажимает «Отправить». Таким образом производится запрос на бэкенд .

2. Бэкенд обрабатывает заявку и определяет, правильно ли она заполнена. Если нет, то веб-сервис возвращает ответ клиенту, о том, что произошла ошибка. Если правильно, то он отправляет заявку в сервис управления заявками и ждет ответа.

3. Сервис управления заявками принимает или не принимает ее. Потом отправляет сообщение обратно в веб-сервис . Если заявка отклонена, то веб-сервис сообщает клиенту, что произошла ошибка. Если заявка принята, то веб-сервис передает данные брокеру сообщений.

4. В брокере сообщений заявка встает в очередь на распределение между менеджерами. После этого клиент получает сообщение, что заявка принята и с ним свяжется менеджер.

Клиент не видит пункты 2-4, так как они происходят на стороне бэкенда. Ему виден лишь результат — заявка принята или произошла ошибка.

Хотите еще пример веб-сервиса? По ссылке ниже мы рассказываем, как за 3 месяца разработали маркетплейс для видеоконтента. В кейсе подробно описана реализация веб-сервиса, какие нюансы обсуждали с заказчиком, с какими вопросами и сложностями столкнулись и как их решили.

READ MORE Идеальный маркетплейс для видеоконтента за 3 месяца с индексацией приватных страниц (что? да!)

Зачем нужны веб-сервисы?

Есть сферы бизнеса, где веб-приложения принесут пользу компаниям: фитнес-индустрия, ресторанная сфера и доставка еды, туризм, медицина. Ценность веб-сервисов для бизнеса можно разделить на две составляющие:

Внутренняя. Помогает автоматизировать и упростить процесс бизнеса. Например, сделать отчет, наладить обмен информацией между отделами или следить за наличием товара;
Внешняя. Это взаимодействие с пользователями. Например, онлайн-запись на услуги, заказ товаров или услуг.

READ MORE Как мы за полгода разработали 4 приложения и одну админку для ночного клуба

Функциональность веб-приложения и его применение ограничивается только вашей фантазией. Но от того, как реализован веб-сервис и что он «умеет», во многом зависит успех стартапа.

У вас есть идеи для веб-сервиса? Напишите нам и мы поможем их реализовать. Команда Purrweb разрабатывает веб-приложения с нуля: помогаем анализировать рынок, прорабатываем бизнес-логику и UI/UX дизайн, создаем цифровой продукт и поддерживаем работу веб-сервиса.

Насколько публикация полезна?

Оцени эту статью!

85 оценок, среднее 4.6 из 5.

Оценок пока нет. Поставьте оценку первым.

Так как вы нашли эту публикацию полезной.

Подписывайтесь на нас в соцсетях!

Что такое веб-сервис

Получи нашу книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подпишись на рассылку и получи книгу в подарок!

Web-сервис (служба) – программа, которая организовывает взаимодействие между сайтами. Информация с одного портала передается на другой.

Например, есть авиакомпания. У нее много рейсов, соответственно, много билетов. Информацию через веб-службу она передает сайту-агрегатору тур-путешествий. Пользователь, который заходит на агрегатор, сможет прямо там купить билеты этой авиакомпании.

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

Информация в интернете разнородна. Сайты управляются разными системами. используются разные протоколы передачи и шифрования. Веб-сервисы упрощают обмен информацией между разными площадками.

Архитектура и протоколы Web-сервисов

Можно определить 3 инстанции, которые взаимодействуют между собой: каталог, исполнитель и заказчик. После создания сервиса, исполнитель регистрирует его в каталоге, а там сервис находит заказчик.

Механизм обмена данными формируется в описании Web Services Description. Это спецификация, охватывающая форматы пересылки, типы контента, транспортные протоколы, которые применяются в процессе обмена сведениями между заказчиком и транспортировщиком услуг.

Сегодня чаще всего используются несколько технологий для реализации различных веб-сервисов:

TCP/IP – протокол, который понимается практически любым сетевым оборудованием, от мэйнфреймов до портативных устройств и PDA.
HTML — универсальный язык разметки, используемый для демонстрации контента устройствами потребителей.
XML – универсальное средство для обработки всех разновидностей данных. На его базе могут работать и прочие протоколы обмена информацией: SOAP и WSDL.
UDDI – универсальный источник распознавания, интеграции и описания. Работает, как правило, в частных сетях и пока не нашел достаточного распространения.

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

Преимущества

Создание необходимых условий для взаимодействия программных компонентов вне зависимости от платформы.
Веб-сервисы основываются на открытых стандартных протоколах. За счет внедрения XML обеспечивается простота формирования и настройки веб-сервисов.
Применение HTTP гарантирует взаимодействие систем посредством межсетевого доступа.

Недостатки

Невысокая производительность и большой объем трафика, в сравнении с системами RMI, CORBA, DCOM, за счет использоваться XML-сообщений в разрезе текста.
Уровень безопасности. Все современные веб-сервисы должны внедрять кодирование, и требовать авторизации пользователя. Хватит ли здесь наличия HTTPS или необходимы более надежные протоколы, как XML Encryption, SAML и т.д., – решаются в ходе разработки.

Задачи веб-сервисов

Веб-сервисы могут использоваться во многих сферах.

B2B-транзакции

Интеграция процессов идет сразу, без участия людей. Например, пополнение каталога интернет-магазина новыми товарами. Их привозят на склад, и кладовщик отмечает в базе данных приход. Автоматически информация передается в интернет-магазин. И покупатель вместо пометки “Нет на складе” на карточке товара видит его количество.

Интеграция сервисов предприятий

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

Создание системы клиент-сервер

Сервисы используются, чтобы настроить работу клиента и сервера. Это дает преимущества:

можно продавать не само программное обеспечение, а делать платным доступ к веб-сервису;
легче решать проблемы с использованием стороннего ПО;
проще организовывать доступ к контенту и материалам сервера.

Веб-сервис — это приложение, которое упрощает техническую настройку взаимодействия ресурсов.

Рассказать о статье:

Десятки тысяч посетителей на ваш сайт по тематике вашего бизнеса за копейки

О вашем бренде узнают и начнут говорить