По мере накопления большого количества данных вполне естественно встает вопрос об организации работы с ними — например, в 1970-х годах, когда на рынке стали появляться базы данных от различных производителей, возникла необходимость в едином логическом языке построения запросов. Благодаря совместной работе производителей и организаций по стандартизации ISO и ANSI был предложен простой и понятный язык SQL. Однако за прошедшие годы потребности бизнеса в обработке данных вышли за рамки SQL, получили развитие подходы категории NoSQL и ряд других, и, таким образом, обилие разнообразных методов работы с данными в современной Всемирной паутине снова привело к необходимости унификации.

Для работы с многообразием данных в Сети сегодня приходится комбинировать разные подходы и стандарты: SPARQL [1] — для графовых, SQL — для реляционных данных и т. д. Одним из стандартов, определяющих протокол обмена данными и язык запросов, является OData (Open Data Protocol).

Открытый, некоммерческий протокол OData, предназначенный для публикации и обмена данными через WWW, позволяет создавать и использовать разнообразные RESTful API для запроса и обновления данных. Стандарт поддерживается независимой ассоциацией OASIS (Advancing Open Standards for the Information Society), что отличает его от других протоколов — например, Gdata, продвигаемого компанией Google для тех же целей. Основное преимущество OData заключается в том, что он определяет формат и порядок выполнения операций CRUD (create, read, update, delete) при обращении к веб-ресурсам. Сегодня одной из задач сообщества OData является обеспечение совместимости различных модулей и приложений, обрабатывающих веб-запросы на основе OData.

REST

Обобщение и структурирование методов взаимодействия приложений в Интернете привели к созданию таких архитектурных стилей программирования, как SOAP, CORBA и RPC, однако в связи с ростом объемов данных, необходимостью ускорения разработки и внедрением веб-приложений наибольшую популярность в сообществе разработчиков приобрел простой архитектурный стиль — Representational State Transfer (REST).

Он подразумевает передачу информации в виде параметров HTTP-запроса. В рамках REST обмен данными в Сети происходит подобно соединению клиента и сервера при работе с базами данных, и действительно, с точки зрения REST веб-сервер представляет собой базу данных. В этом контексте OData играет роль унификатора языка запросов к веб-ресурсу (так же, как SQL для реляционных баз данных).

REST определяет набор архитектурных принципов, на основе которых можно для любых ресурсов создавать универсальные веб-сервисы. При использовании OData готовое веб-приложение может получать, удалять и модифицировать данные сервера, используя стандартные HTTP-запросы: GET, POST, PUT и DELETE.

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

Некоторое время назад сообщество программистов начало предпринимать попытки обобщения лучших практик разработки приложений на принципах REST. Для развития был выбран разработанный в Microsoft протокол, который компании Citrix Systems, IBM, Progress Software, SAP AG и WSO2 предложили стандартизировать в OASIS. Так появился открытый веб-протокол для формирования запросов и обновления данных — OData.

OData

Протокол OData позволяет обращаться к ресурсам, используя в качестве запросов HTTP-команды. Обмен данными происходит в форматах JSON или XML. Однако широкое распространение JavaScript, а также наличие базовых навыков работы с этим языком даже у начинающих веб-программистов сделали JSON наиболее популярным инструментом для работы по протоколу OData. Посредством OData можно стандартизировать набор команд для выполнения операций чтения, удаления и модификации данных (CRUD), а также обмена данными, что позволяет единым образом обращаться к различным данным, расположенным на любом сайте. Протокол позволяет создавать и использовать сервисы, работающие с реляционными, документоориентированными, объектными и графовыми базами данных.

OData оперирует коллекциями объектов (Collection of Entities), которые можно рассматривать как некоторый аналог таблицы (если OData работает с реляционными данными, то это и есть таблица). OData позволяет читать данные, узнавать связи между объектами, выполнять поиск, сортировку и другие важные при работе с данными процедуры. Благодаря простому интерфейсу приложение может за один запрос получить составные данные (например, о человеке вместе с его телефонами и списком друзей). Результаты запросов могут выводиться в удобном для чтения виде.

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

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

С точки зрения OData любой интернет-ресурс — это база данных, доступная через REST API. OData предполагает, что любые данные имеют URL: коллекции, объекта, связи, отдельного свойства и т. д. Например, если набрать в браузере URL

https://samples.databoom.space/api1/sampledb/collections/persons

то мы получим коллекцию всех людей. Есть много примеров других сайтов, содержащих специально организованные структуры для работы с OData: Microsoft, OData, Kendo UI и т. п. Отдельный человек, идентифицированный ключом «person169», может быть получен по URL

https://samples.databoom.space/api1/sampledb/collections/persons(«person169»)

OData позволяет выполнять и более сложные запросы, для этого в языке имеются логические операторы, операторы сравнения, параметры фильтрации ($filter), сортировки ($orderby), выдачи дочерних объектов ($expand), ограничения на количество результатов ($top) и другие, являющиеся частью HTTP-запроса.

Рассмотрим в качестве примера небольшую коллекцию, содержащую информацию о книгах, их авторах и читателях, издательствах и тиражах. Итак, если требуется найти всех людей по имени Vanda на ресурсе, понимающем OData, то нужно сделать следующий запрос:

https://samples.databoom.space/api1/sampledb/collections/persons?$filter=firstname eq «Vanda»

Сложные запросы OData могут содержать большое количество параметров, разделенных знаком «&». Например, на запрос

https://samples.databoom.space/api1/testdb/book?$filter=publisher/president/likes/author/familyname eq 'Акунин'&$top=10&$orderby=title

будут выведены первые 10 книг Акунина, которые любит президент издательства, отсортированные по названию.

Интересной особенностью OData является возможность работы со связями: сегодня спецификация поддерживает поиск среди «друзей друзей», что актуально для приложений социальных сетей. Например, чтобы обратиться к SQL-базе, надо знать ее IP, имя пользователя, пароль и структуру данных, а для работы с OData тоже нужны эти параметры, только вместо IP надо указать URL.

Перспективы OData

Сегодня все больший интерес к OData проявляет сообщество разработчиков, этот стандарт пользуется поддержкой со стороны OASIS, в своей работе его учитывают Microsoft, SAP, «1C», IBM, DevExpess, Webix, Databoom, Syncfusion, ComponentOne и др. На сегодняшний день представлено множество API, совместимых с OData, их перечень можно найти на сайте OData.org. Однако с момента передачи протокола под управление OASIS прошло всего три года, и проблемы у OData имеются. Например, не стоит ждать полной совместимости всех API, включающих не только базовые функции, поддерживаемые OASIS, но и различные расширения, необходимые для того или иного проекта.

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

Концепция Semantic Web, включающая в себя адаптацию данных из Сети для машинной обработки, подразумевает развитие стандартов хранения и предоставления связанных данных, поэтому разработчики создают расширения JSON для поддержки различных типов связей между объектами. Например, идут разработки по представлению графовых данных в JSON, а также описанию видов и дифференциации связей. Однако пока такие разработки несовместимы друг с другом, поэтому в сообществе OData активно обсуждаются следующие версии протокола, стандартизирующие, в частности, представление графовых данных.

***

Благодаря тому, что OData облегчает процесс разработки, количество веб-приложений на его основе продолжает расти — стандарт позволяет различным компаниям независимо разрабатывать и объединять компоненты. Например, для «1С:Предприятия» имеется REST API, созданный в соответствии со стандартом OData. Пользователь системы делает свой грид в соответствии со стандартом OData, а разработчик расширения к «1С» делает интерфейс, который использует «1С» и грид стороннего производителя. Пользователь не должен обсуждать REST API с компанией «1С» — они совместимы, поскольку оба удовлетворяют стандарту OData, который в этом смысле аналогичен SQL. При этом не нужно договариваться по каждой мелочи — например, как организовать постраничный вывод, фильтровать и сортировать данные, обрабатывать ошибки. Все становится просто и удобно, как было в свое время с SQL в мире реляционных баз данных.

Литература

  1. Владислав Головков, Андрей Портнов, Виктор Чернов. RDF — инструмент для неструктурированных данных // Открытые системы.СУБД. — 2012. — № 09. — С. 46–49. URL: http://www.osp.ru/os/2012/09/13032513 (дата обращения: 11.11.2015).

Владислав Головков, Андрей Портнов, Виктор Чернов ({vg, ap, vc}@databoom.space) — управляющие партнеры, «Датабум» (Москва).