Web-сервисы, виды, технологии. REST. OData

Вместе Binding Template и Technology Model определяют Web-сервис. Technology Model содержит абстрактное описание, а Binding Template — конкретную спецификацию сервиса. Каждый элемент Binding Template принадлежит определенному элементу Business Service, но несколько элементов Binding Template могут ссылаться на один элемент Technology Model.

Бизнес-реестр UDDI сам является SOAP Web-сервисом. Он поддерживает операции создания, модификации, удаления и поиска элементов всех четырех рассмотренных выше типов.

 

5. Виды Web-сервисов

 

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

 

1) Поисковые  системы. Наиболее популярные поисковые  системы – Google и Яндекс

 

2) Почтовые  сервисы так же предоставляют  создатели поисковых системы, но  самым популярным почтовым сервисом  в Росии, на сегодняшний день, является mail.

 

3) Интернет-форумы. На сайтах этого вида пользователи  могут создавать различные темы, а также комментировать их. Как  правило, форумы ограничены одной  специфической тематикой

 

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

 

5) Доски объявлений  – на этих сайтах пользователи  могут размещать либо искать  какую-то конкретную информацию  в виде объявлений о покупке  или продаже чего-либо

 

6) Социальные  сети – этот тип сайтов создан  для общения пользователей между  собой. Как правило, такие сайты  состоят из страниц пользователей, групп и множества других сервисов. Данные сайты удобны для знакомства, переписки и дальнейшего общения.

 

6. REST

REST (Representational state transfer) – это стиль архитектуры программного  обеспечения для распределенных  систем, таких как World Wide Web, который, как правило, используется для  построения веб-служб. Термин REST был  введен в 2000 году Роем Филдингом, одним из авторов HTTP-протокола. Системы, поддерживающие REST, называются RESTful-системами. 
 
В общем случае REST является очень простым интерфейсом управления информацией без использования каких-то дополнительных внутренних прослоек. Каждая единица информации однозначно определяется глобальным идентификатором, таким как URL. Каждая URL в свою очередь имеет строго заданный формат.  
 
А теперь тоже самое более наглядно: 
 
Отсутствие дополнительных внутренних прослоек означает передачу данных в том же виде, что и сами данные. Т.е. мы не заворачиваем данные в XML, как это делает SOAP и XML-RPC, не используем AMF, как это делает Flash и т.д. Просто отдаем сами данные. 
 
Каждая единица информации однозначно определяется URL – это значит, что URL по сути является первичным ключом для единицы данных. Т.е. например третья книга с книжной полки будет иметь вид /book/3, а 35 страница в этой книге — /book/3/page/35. Отсюда и получается строго заданный формат. Причем совершенно не имеет значения, в каком формате находятся данные по адресу /book/3/page/35 – это может быть и HTML, и отсканированная копия в виде jpeg-файла, и документ Microsoft Word. 
 
Как происходит управление информацией сервиса – это целиком и полностью основывается на протоколе передачи данных. Наиболее распространенный протокол конечно же HTTP. Так вот, для HTTP действие над данными задается с помощью методов: GET (получить), PUT (добавить, заменить), POST (добавить, изменить, удалить), DELETE (удалить). Таким образом, действия CRUD (Create-Read-Updtae-Delete) могут выполняться как со всеми 4-мя методами, так и только с помощью GET и POST. 
 
Вот как это будет выглядеть на примере: 
 
GET /book/ — получить список всех книг 
GET /book/3/ — получить книгу номер 3 
PUT /book/ — добавить книгу (данные в теле запроса) 
POST /book/3 – изменить книгу (данные в теле запроса) 
DELETE /book/3 – удалить книгу 
 
Существуют так называемые REST-Patterns, которые различаются связыванием HTTP-методов с тем, что они делают. В частности, разные паттерны по-разному рассматривают POST и PUT. Однако, PUT предназначен для создания, реплейса или апдейта, для POST это не определено (The POST operation is very generic and no specific meaning can be attached to it). Поэтому мой пример будет правильным и в таком виде, и в виде если поменять местами POST и PUT. 
 
Вообще, POST может использоваться одновременно для всех действий изменения:  
POST /book/ – добавить книгу (данные в теле запроса) 
POST /book/3 – изменить книгу (данные в теле запроса) 
POST /book/3 – удалить книгу (тело запроса пустое) 
 
Это позволяет иногда обходить неприятные моменты, связанные с неприятием PUT и DELETE. 
 

Использование REST для построения Web-сервисов.

 
Как известно, web-сервис – это приложение работающее в World Wide Web и доступ к которому предоставляется по HTTP-протоколу, а обмен информации идет с помощью формата XML. Следовательно, формат данных передаваемых в теле запроса будет всегда XML.  
 
Для каждой единицы информации (info) определяется 5 действий. А именно: 
 
GET /info/ (Index) – получает список всех объектов. Как правило, это упрощенный список, т.е. содержащий только поля идентификатора и названия объекта, без остальных данных. 
 
GET /info/{id} (View) – получает полную информацию о объекте. 
 
PUT /info/ или POST /info/ (Create) – создает новый объект. Данные передаются в теле запроса без применения кодирования, даже urlencode. В PHP тело запроса может быть получено таким способом: 
 
function getBody() { 
if (!isset($HTTP_RAW_POST_DATA)) 
$HTTP_RAW_POST_DATA = file_get_contents("php://input"); 
return $HTTP_RAW_POST_DATA; 
} 
 
POST /info/{id} или PUT /info/{id} (Edit) – изменяет данные с идентификатором {id}, возможно заменяет их. Данные так же передаются в теле запроса, но в отличие от PUT здесь есть некоторый нюанс. Дело в том, что POST-запрос подразумевает наличие urldecoded-post-data. Т.е. если не применять кодирования – это нарушение стандарта. Тут кто как хочет – некоторые не обращают внимания на стандарт, некоторые используют какую-нибудь post-переменную. 
 
DELETE /info/{id} (Delete) – удаляет данные с идентификатором {id}. 
 
Еще раз отмечу, что в нашем примере /info/ — может и базироваться на какой-то другой информации, что может быть (и должно) быть отражено в URL: 
 
/data/4/otherdata/6/info/3/ … и тому подобное. 
 
Какие можно сделать из этого выводы: 
 
Как видно, в архитектура REST очень проста в плане использования. По виду пришедшего запроса сразу можно определить, что он делает, не разбираясь в форматах (в отличие от SOAP, XML-RPC). Данные передаются без применения дополнительных слоев, поэтому REST считается менее ресурсоемким, поскольку не надо парсить запрос чтоб понять что он должен сделать и не надо переводить данные из одного формата в другой.  

Практическое применение.

 
Самое главное достоинство сервисов в том, что с ними работать может какая угодно система, будь то сайт, flash, программа и др. так как методы парсинга XML и выполнения запросов HTTP присутствуют почти везде.  
 
Архитектура REST позволяет серьезно упростить эту задачу. Конечно в реальности, того что описано не достаточно, ведь нельзя кому угодно давать возможность изменять информацию, то есть нужна еще авторизация и аутентификация. Но это достаточно просто разрешается при помощи различного типа сессий или просто HTTP Authentication. 

Правила REST для взаимодействия клиент/сервер могут целиком определяться требованиями приложений. Так, если определить интерфейс REST, предназначенный для клиента JavaScript, можно сделать так, чтобы данные возвращались в формате JSON, а если он предназначен для клиента PHP, то это могут быть упорядоченные данные или XML.

Каждый вызов Web-сервисов REST – это простой запрос HTTP с использованием одного из стандартных глаголов HTTP. Как правило, используется глагол, наиболее подходящий для выполняемого действия:

• GET - для получения данных от сервера;
• POST - для передачи данных на сервер;
• DELETE - для удаления ресурса на сервере.

В листинге показано, как пример взаимодействия с Web-сервисом поиска Yahoo! REST работает с PHP. Пример взаимодействия с Web-сервисом REST на PHP.

<?php

// Указание нужного Web-сервиса REST

$url = 'http://search.yahooapis.com/WebSearchService/V1/

     webSearch?appid=YahooDemo&query=sugarcrm';

// Обращение к Web-сервису; результаты  возвращаются в формате XML

$resultsXml = file_get_contents($url);

// Преобразование XML в объект SimpleXML

$xmlObject = simplexml_load_string($resultsXml);

// Просмотр объекта для извлечения  заголовков результатов поиска 

foreach ( $xmlObject->Result as $result )

    echo "{$result->Title}\n";

В примере из листинга выполняется поиск по ключевому слову sugarcrm с помощью Web-сервиса поиска Yahoo. При этом используется функция PHP file_get_contents(), которая выполняет запрос GET по указанному URL. По умолчанию она возвращает результаты запроса в качестве строки XML, а библиотека PHP SimpleXML используется для ее преобразования в объект PHP, который можно многократно применять для получения искомых данных.

 

7. OData

OData — это веб-ориентированный API-интерфейс  для доступа к данным и манипулирования  ими. Он подобен API-интерфейсам mini-ODBC и JDBC, но в отличие от них  специально ориентирован на Интернет. Точнее говоря, OData позволяет клиентам  конструировать URI-идентификаторы для  именования набора сущностей, осуществлять  фильтрацию содержащихся в этом  наборе сущностей, а также прослеживать  отношения со связанными сущностями  и коллекциями сущностей. OData предоставляет  механизмы для ресурсов (т.н. "поставщиков"), позволяющие представить "выставляемые" ими описания структур данных, и механизмы для клиентов (т.н. "потребителей"), позволяющие посредством  протокола HTTP получить выставленные  порции ресурсов и манипулировать  ими. Веб-ориентированный API-интерфейс OData описывает, как должны быть  отформатированы запросы от клиентов  и результаты от поставщиков. Документы со спецификациями OData были представлен в организацию OASIS (Organization for the Advancement of Structured Information Standards) в мае 2012 г.

OData —  это веб-ориентированный API-интерфейс  для доступа к данным и манипулирования  ими. Он подобен API-интерфейсам mini-ODBC и JDBC, но в отличие от них  специально ориентирован на Интернет. Точнее говоря, OData позволяет клиентам  конструировать URI-идентификаторы для  именования набора сущностей, осуществлять  фильтрацию содержащихся в этом  наборе сущностей, а также прослеживать  отношения со связанными сущностями  и коллекциями сущностей.

Выставление базы данных в Интернете с помощью OData-поставщика общего назначения.

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

Язык CSDL

 

На рисунке показана схема языка CSDL (Conceptual Schema Definition Language). CSDL — это опциональный инструмент, помогающий приложениям-потребителям понимать структуру выставляемых данных. CSDL подобен метаданным в JDBC and ODBC, он помогает клиентским приложениям понимать, к чему именно они обращаются.

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

OData и другие веб-ориентированные API-интерфейсы

В настоящее время используются тысячи веб-ориентированных API-интерфейсов. К числу популярных API-интерфейсов этой категории относятся картографические сервисы. По состоянию на июнь 2012 года на веб-сайте Programmable Web было перечислено более 6000 веб-ориентированных API-интерфейсов (см. заметку под названием: API Business Models Take Center Stage). Недавнее исследование компании Vordel показало, что "половина предприятий внедряет API-интерфейсы для построения новых бизнес-каналов", при этом 25% из этих интерфейсов разрабатывается специально для мобильных приложений.

Одна из интересных областей – какое отношение имеет OData к деятельности в области API-интерфейса Linked Data. Рабочая группаW3C Linked Data Platform (LDP) Working Group и технический комитет OASIS OData Technical Committee стремятся специфицировать API-интерфейсы REST-типа для получения данных и манипулирования ими в Интернете с использованием различных моделей данных. Платформа LDP базируется на модели данных Resource Definition Framework (RDF) а OData базируется на модели данных Entity Data Model (EDM).

• ИнфраструRDF была описана организаций W3C в 1999 году, но восходит к более ранним работам по тройкам (triple), выполненным в 1980-1990 г.г. Примеры: базы данных типа triple stores и инфраструктура meta-content framework (MCF). RDF — это модель данных, в которой информация моделируется т.н. "тройками" (triple), напр., "номер соцстрахования Стива — nnn-nn-nnn", "пол Стива — мужчина", "Стив приобрел стол", "Джон — друг Стива", "Джоан — подруга Джона" и т.д. Для обращения к ресурсам, а также для связывания ресурсов (Стив, Джон, Джоан, стол и т.д.) с их свойствами инфраструктура RDF пользуется универсальными идентификаторами URIs.
• Модель EDM была специфицирована компаний Microsoft и берет свое начало в модели Peter Chen's Entity Relationship Modelсформулированной в 1976 г. (Peter Chen). Модель EDM до сих пор используется при проектировании реляционных баз данных. Модель данных EDM базируется на преобразовании информации в сущности и в отношения. Эта модель использует специфические для определенной области значения, например, номера социального страхования, номера счетов-фактур, номера товаров, для ссылки на ресурсы и на их свойства, а также для связывания информации.

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

Построение адаптеров между гетерогенными веб-ориентированными API-интерфейсами вполне возможно. К примеру, прототип адаптера для связывания рабочих элементов (workitem) решения IBM Rational Team Concert, получаемых посредством API-интерфейс на базе Linked Data под названием OSLC (Open Services for Life Cycle Collaboration), и документов Microsoft Sharepoint, получаемых посредством OData.

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

Пример на OData, обращающийся к сервису Netflix

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<feed xml:base="http://odata.netflix.com/v2/Catalog/"

          xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"

xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"

xmlns="http://www.w3.org/2005/Atom">

  <title type="text">Titles</title>

  <id>http://odata.netflix.com/v2/Catalog/Titles/</id>

  <updated>2012-05-23T21:41:18Z</updated>

  <link rel="self" title="Titles" href="Titles" />

  <entry>

    <id>http://odata.netflix.com/v2/Catalog/Titles('13aly')</id>

    <title type="text">Red Hot Chili Peppers: Funky Monks</title>

    <summary type="html">Lead singer Anthony Kiedis, bassist Flea, ... </summary>

    <updated>2012-01-31T09:45:16Z</updated>

    <author>

      <name />

    </author>

    .

    .

    .

  </entry>

</feed>

 

 

 

 

 

 

 

 

 

 

 

8. Используемые ресурсы

1. http://www.odata.org/
2. http://www.ubs.ru/ws/ws.html
3. http://www.osp.ru/
4. http://compress.ru/
5. http://www.ibm.com/developerworks/ru
6. http://habrahabr.ru/post/38730/
7. https://ru.wikipedia.org/wiki/
8. http://www.uddi.org/