Ирина Эланс

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

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

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение

высшего образования

Тульский государственный университет

Кафедра прикладной математики и информатики

Контрольно-курсовая работа

по курсу: «Современные технологии программирования»

на тему: «Web-сервисы, виды, технологии. REST. OData»

Выполнил: ст. гр. 530202 Шачнева. Е. А.

Проверил: доцент каф. ПМиИ Смирнов О. И.

Тула

2014

Содержание

1. Определение сервиса 3

2. Требования к SOA 3

3. Функции Web-сервисов 4

4. Основные технологии Web-сервисов 5

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

6. REST 10

7. OData 14

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

1. Определение сервиса

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

Назовем сервисом ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:

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

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

2. Требования к SOA

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

обеспечивать преемственность инвестиций в IT, сохранение существующих информационных систем и их совместное эффективное использование для повышения ROI от IT-вложений;
обеспечивать реализацию различных типов интеграции:
- пользовательская интеграция (user integration) - обеспечение взаимодействия информационной системы с конкретным персонифицированным пользователем;
- интеграция приложений (application connectivity) - обеспечение взаимодействия приложений;
- интеграция процессов (process integration) - интеграция бизнес-процессов;
- информационная интеграция (information integration) - интеграция с целью обеспечения доступности информации и данных;
- интеграция новых приложений (build to integrate) - интеграция новых приложений и сервисов в существующие информационные системы.
обеспечивать поэтапность внедрения вновь созданных и миграции существующих информационных систем;
иметь стандартизованную технологическую обеспеченность реализации и инструментарий разработки, совокупно предоставляющие наилучшие возможности повторного использования приложений, внедрения новых и миграции существующих информационных систем;
позволять реализацию различных моделей построения информационных систем, в особенности таких как портальные решения, grid-системы и on-demand-системы.

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

3. Функции Web-сервисов

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

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

Таким образом Web services обеспечивают построенную на открытых стандартах информационную инфраструктуру, посредством которой организации могут:

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

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

4. Основные технологии Web-сервисов

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

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

Таким образом, все Веб-сервисы базируются на применении открытых, утверждаемых консорциумом ИТ-сообщества стандартах и протоколах, ключевыми из которых являются следующие:

SOAP (Simple Object Access Protocol) - протокол доступа к простым объектам, т.е. механизм для передачи информации между уделенными объектами на базе протокола HTTP и некоторых других Интернет-протоколов. Более подробную информацию о данном стандарте можно найти на странице "Ссылки";
WSDL (Web Services Description Language) - язык описания Web-сервисов. Подробная спецификация находится в разделе "Документы" ;
UDDI (Universal Description, Discovery and Integration) - универсальное описание, обнаружение и интеграция - упрощенно говоря, протокол поиска ресурсов в Интернете.

Серверы приложений являются хранилищами Web-сервисов и делают их доступными через протоколы HTTP GET, HTTP POST и HTTP SOAP.

Существующие Web-сервисы описываются в WSDL-документах, которые располагаются либо на сервере приложений, либо в специальных XML-хранилищах. WSDL-документ может ссылаться на другие WSDL-документы и документы XSD (XML Schema), в которых описаны типы данных, используемые Web-сервисами. XML-хранилища используются для управления WSDL-документами. Внутри WSDL-документа находится адрес (URL) Web-сервиса. Web-сервисы описаны и проиндексированы в бизнес-реестре, содержащем адреса (URL) WSDL-документов.

В следующих разделах мы рассмотрим три основных Web-стандарта, на которых базируются Web-сервисы SOAP, WSDL и UDDI, более подробно.

SOAP — Simple Object Access Protocol

SOAP — это стандарт для отсылки и получения сообщений по Internet. Изначально этот протокол был предложен фирмой Microsoft в качестве средства для удаленного вызова процедур (RPC, Remote Procedure Call) по протоколу HTTP, а спецификация SOAP 1.0 (Userland, Microsoft, Developmentor) была тесно связана с Component Object Model. Фирма IBM и ряд других компаний, в том числе Lotus, внесли определенный вклад в развитие этого протокола, и его стандарт был направлен на рассмотрение комитетом W3C.

Спецификация SOAP определяет XML-«конверт» для передачи сообщений, метод для кодирования программных структур данных в формате XML, а также средства связи по протоколу HTTP.

SOAP-сообщения бывают двух типов: запрос (Request) и ответ (Response). Запрос вызывает метод удаленного объекта, ответ возвращает результат выполнения данного метода. Ниже приведены примеры запроса и ответа в формате SOAP.

Спецификация SOAP определяет формат кодирования, который, в свою очередь, задает способ представления данных в XML-формате.

WSDL — Web Services Description Language

Для того чтобы приложения могли использовать Web-сервисы, программные интерфейсы последних должны быть детально описаны — с этой точки зрения язык WSDL играет ту же роль, что и язык Interface Definition Language (IDL) в распределенных вычислениях. Описание может включать такую информацию, как протокол, адрес сервера, номер используемого порта, список доступных операций, формат запроса и ответа и т.п.

Для описания этой информации было предложено несколько языков. Одним из них был язык Service Description Language (SDL), разработанный Microsoft и входивший в первую версию Microsoft SOAP Toolkit. Компания IBM переработала спецификацию и, использовав спецификацию Network Accessible Service Specification Language (NASSL), выпустила NASSL Toolkit как часть SOAP4J. Идеи, реализованные в NASSL, повлияли на спецификацию языка SOAP Contract Language (SCL), предложенную Microsoft. В настоящее время обе спецификации (NASSL и SDL/SCL), а также предложения других фирм учтены в спецификации языка WSDL. Для описания бизнес-логики IBM и Microsoft работают над спецификацией языка Web Services Flow Language (WSFL).

Как мы видим, описание сервисов представляет собой XML-документ, состоящий из нескольких элементов, в том числе из описания пространства имен (namespace), описания типов и элементов, сообщений, порта, а также возможных операций — запросов и ответов.

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

UDDI — Universal Description, Discovery and Integration

Задача UDDI — предоставить механизм для обнаружения Web-сервисов. UDDI задает бизнес-реестр, в котором провайдеры Web-сервисов могут регистрировать сервисы, а разработчики — искать необходимые им сервисы. Компании IBM, Microsoft и Ariba создали собственные UDDI-реестры (в скором времени эти реестры будут объединены в Web-реестр), в одном из которых разработчики могут зарегистрировать свои Web-сервисы, после чего данные будут автоматически реплицированы в другие реестры (См. рис. 5).

UDDI базируется на элементах четырех типов: Business Entity, Business Service, Binding Template и Technology Model. Элемент Business Entity описывает индустрию, предоставляющую данный Web-сервис. Этот элемент может включать описания категорий для данной индустрии, облегчающие более детальный поиск сервисов.

Business Service — это класс сервисов в рамках определенной отрасли промышленности или услуг. Каждая отрасль принадлежит определенному элементу Business Entity.

Вместе 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-поставщика общего назначения.

В схеме на рисунке показано, как такой ресурс, как база данных, может быть выставлен в Интернете при посредстве 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>

<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>

</author>

</entry>

</feed>

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

http://www.odata.org/
http://www.ubs.ru/ws/ws.html
http://www.osp.ru/
http://compress.ru/
http://www.ibm.com/developerworks/ru
http://habrahabr.ru/post/38730/
https://ru.wikipedia.org/wiki/
http://www.uddi.org/

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