odata что это такое простыми словами

OData сервис без написания кода

Одним из наиболее важных аспектов разработки программного обеспечения является быстрое создание прототипов. Для большинства служб необходимы по крайней мере некоторые операции CRUD, и большинство приложений можно описать как приложения, управляемые данными. API, которые я пишу, в основном берут данные из базы данных и возвращает их клиенту в виде JSON. OdataToEntity — это инструмент, который генерирует API из базы данных и устраняет необходимость в написании отдельного REST API.

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

Эта функциональность доступна в проекте OdataToEntity.EfCore.DynamicDataContext, который является частью библиотеки OdataToEntity. Реализован пример HTTP сервера в виде консольной программы, принимающей на вход строку подключения к базе данных. Поддерживаются базы данных: MySql, PostgreSql, Sql Server. Помимо таблиц и CRUD операций над ними, доступны представления, хранимые процедуры и функции.

Описание HTTP сервера

«BasePath» — базовый путь в URL сервера.
«Provider» — тип базы данных, возможные значения mysql, postgresql, sqlserver.
«ConnectionString» — строка подключения к базе данных.
«UseRelationalNulls» — указывает, следует ли использовать семантику реляционной базы данных
при сравнении нулевых значений.
«InformationSchemaMappingFileName» — дополнительная настройка отображения базы данных в API.

Источник

Создание полнофункциональных интернет-приложений с применением Open Data Protocol

Шейн Бургес

Я начну с ответа на вопрос номер один, который мне задают с момента объявления OData в ноябре прошлого года: «Что это такое?». Говоря очень простыми словами, OData — это веб-протокол на основе ресурсов для запроса и обновления данных. OData определяет операции с ресурсами, используя HTTP-команды (PUT, POST, UPDATE и DELETE), и идентифицирует эти ресурсы по стандартному синтаксису URI. Данные передаются поверх HTTP с применением стандартов AtomPub или JSON. В случае AtomPub протокол OData определяет некоторые соглашения в стандарте для поддержки обмена информацией о запросах и схемах. Подробности о протоколе OData см. на сайте odata.org.

Экосистема OData

В этой статье я ознакомлю вас с несколькими продуктами, инфраструктурами и веб-сервисами, которые используют или создают каналы OData. Этот протокол определяет ресурсы, методы и операции (GET, PUT, POST, MERGE и DELETE, соответствующие операциям чтения, создания, замены, слияния и удаления), которые можно выполнять применительно к этим ресурсам с помощью методов.

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

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

Что нового в WCF Data Services?

Инфраструктура WCF Data Services — не просто протокол для RIA-приложений. Он был спроектирован для разработчиков крупномасштабных сервисов и имеет много привлекательных для них возможностей, в том числе поддержку лимитов на серверной стороне, HTTP-кеширования, сервисов без состояний, потоковой передачи данных и модели подключаемых провайдеров. Давайте рассмотрим новые средства, которые в целом представляют наибольший интерес для разработчиков RIA-приложений.

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

Чтобы упростить связывание с данными от OData-сервиса, в клиентскую библиотеку WCF Data Services добавлен новый тип — DataServiceCollection. Он реализует отслеживание изменений содержащихся в нем элементов (через интерфейсы INotifyPropertyChanged и INotifyCollectionChanged). Если его привязать к какому-либо элементу управления (например, DataGrid в Silverlight), он будет отслеживать изменения, внесенные в объекты и в сам набор. Этот новый набор значительно облегчает процесс создания OData-клиентов.

Также заказчики часто просили добавить возможность проецировать подмножество свойств сущности, возвращаемой в результате запроса. Для этого ввели LINQ-поддержку на основе LINQ-выражения Select. Это дает два преимущества: сокращается размер HTTP-ответов на запросы и уменьшается объем памяти, занимаемый объектами на клиентской стороне. Это может оказаться особенно полезным при разработке клиентского приложения, использующего некий сервис, который вам не принадлежит и в котором у каждой сущности есть много свойств, не нужных вашему клиенту. Далее в этой статье я продемонстрирую работу с крупномасштабным, общедоступным сервисом с большим количеством сущностей, имеющих множество свойств. Проекции будут весьма полезны в этом примере, так как благодаря им можно будет включать лишь некоторые, действительно необходимые свойства сущности.

Чтобы помочь вам понять ценность экосистемы OData, мы создадим веб-приложение — сайт вымышленной риэлтерской компании Contoso Ltd., где посетители смогут просматривать лоты управляемой ею недвижимости.

Реляционные данные

Основной источник данных для приложения Home Finder компании Contoso.com — база данных SQL Server, которая содержит информацию обо всей недвижимости, управляемой компанией, и все лоты (текущие и ранее проданные), опубликованные по этой недвижимости.

Чтобы создать канал OData поверх реляционных данных, начните с создания веб-приложения ASP.NET в Visual Studio 2010, которое будет хостом OData-сервиса. В Visual Studio выберите File | New | Project | ASP.NET Web Application. Это приведет к генерации скелетного кода веб-сервиса, который можно будет использовать для хостинга канала OData.

После создания и настройки веб-сервиса мы создадим модель данных Entity Framework, которую будет предоставлять канал OData. Visual Studio упрощает эту задачу с помощью мастера Add New Item, позволяющего автоматически генерировать такую модель на основе существующей базы данных. На рис. 1 показана простая модель данных, созданная с применением мастера Add New Item поверх данных SQL Server, в которых содержатся сведения о недвижимости и лотах, управляемых Contoso.

Рис. 1. Модель данных Entity Framework для реляционных данных

Теперь создадим WCF-сервис данных, открывающий доступ к этой модели как к каналу OData. Visual Studio позволяет упростить и эту задачу выбором варианта WCF Data Service в мастере Add New Item. В этом случае Visual Studio предоставляет файл кода (в данном примере этот файл называется Listings.svc.cs), используемый для конфигурирования сервиса данных.

Рис. 2. Определение WCF-сервиса данных

Давайте подробнее рассмотрим, что еще делает метод InitalizeService на рис. 2. Он вызывает SetEntitySetAccessRule для обоих наборов сущностей, которые будет предоставлять сервис и задает права доступа как AllRead. Это указывает сервису сделать оба набора сущностей полностью доступными для чтения, но запретить любые попытки вставок, обновлений или удалений. И это отличный способ управлять доступом к сервису. WCF Data Services также поддерживает методы, называемые перехватчиками запросов (Query Interceptors); они позволяют автору сервиса более тонко разграничивать права доступа для сервиса индивидуально для каждого набора сущностей. Установите файл Listings.svc как стартовую страницу проекта и запустите проект. Откроется окно браузера, и вы увидите документ сервиса (рис. 3).

Рис. 3. Документ сервиса для сайта SharePoint

Соглашения в OData по URI

В документе сервиса перечисляются наборы сущностей, предоставляемые этим сервисом. Помните: вы можете обращаться к ресурсам в этом сервисе, используя мощный синтаксис URI, определенный как необязательная часть протокола OData. Давайте кратко рассмотрим синтаксис URI для этого сервиса. Чтобы получить доступ к каналу для каждого набора сущностей, вы дописываете имя этого набора к базовому URI сервиса, например http://myhost/Listings.svc/Properties будет указывать на набор сущностей Properties.

Кроме того, можно адресоваться индивидуально к конкретной сущности, используя ее значение ключа; URI http://myhost/Listings.svc/Properties(0) указывал бы на сущность Property с идентификатором, равным 0. Вы можете использовать связи между сущностями или наборами сущностей, добавляя в конец URI имя отношения, и http://myhost/Listings.svc/Properties(0)/Listings позволял бы обращаться к набору лотов, связанных с сущностью Property с нулевым идентификатором. Благодаря такому синтаксису становится возможной навигация по множеству уровней связей (отношений).

Рис. 1. Параметры OData-запроса

Предоставление данных из SharePoint

В предыдущем разделе я показал, как обеспечить доступ к данным, хранящимся в моей реляционной базе данных с информацией о недвижимости и лотах для веб-сайта риэлтерской компании. Допустим, у меня есть также информация об агентах по продажам недвижимости, но эти сведения хранятся на сайте SharePoint. Microsoft SharePoint 2010 позволяет предоставлять все списки и документы внутри этих списков как канал OData. Это просто замечательно для сайта риэлтерской компании, так как информация об агентах, введенная сотрудниками компании, доступна по каналу OData, который может быть включен в создаваемое мной приложение для обработки лотов (Listings application). Компаниям, у которых есть процессы ввода и обновления таких данных через интерфейс SharePoint, не придется что-либо менять в своих рабочих процессах для подстройки под мое приложение. Данные, введенные на сайт SharePoint компании, доступны в реальном времени для создаваемого приложения Listings.

На рис. 5 показан простой портал SharePoint, используемый агентами по продаже недвижимости для записи и обновления своей контактной информации.

Рис. 5. Сайт SharePoint для хранения информации об агентах

Рис. 6. Канал агентов для SharePoint Agent Service

Использование справочных данных от OGDI

По умолчанию канал OData будет возвращать ATOM-представление, поэтому при обращении из браузера результат будет показываться как канал ATOM. Если в запросе изменить заголовок приема (accept header) на «application/json», те же данные будут возвращаться как канал JSON.

Open Government Data Initiative (OGDI) — сервис, встроенный в платформу Microsoft Windows Azure и упрощающий правительственным агентствам публикацию самых разнообразных общедоступных данных. Проект OGDI предоставляет стартовый набор, который правительственные агентства могут использовать для доступа к своим данным. Например, в Эдмонтоне используют стартовый набор для доступа к информации от муниципалитета, а сервис на ogdisdk.cloudapp.net имеет набор данных с разнообразной информацией о Вашингтоне, округ Колумбия. Другой пример — проект Microsoft по кодовым названием «Dallas», нацеленный на то, чтобы упростить любому лицу или организации, обладающей какой-либо общественно интересной информацией, предоставление своих данных в виде сервиса в Интернете. Этот проект также создан на платформе Windows Azure и обеспечивает доступ к данным через OData. Все это примеры крупномасштабных сервисов, открывающих доступ к большим наборам справочных данных, которые могут использоваться веб-приложениями. Как я покажу далее, если эти сервисы предоставляют свои данные через OData, их очень легко использовать в самых разных приложениях.

Как уже говорилось, веб-сайт OGDI содержит общедоступные сведения о Вашингтоне, округ Колумбия. Приложение Contoso для управления недвижимостью применяется для просмотра лотов в этом округе, и пользователям было бы очень полезно получать эти открытые справочные сведения о местности вокруг конкретного дома. Создавая клиент для этого приложения-примера, я продемонстрирую, как включить канал OData с веб-сайта OGDI в качестве одного из источников данных для приложения.

Другие провайдеры данных OData

До сих я показывал примеры использования данных от SQL Server, SharePoint и универсального OData-сервиса в Интернете, но существуют и другие варианты. Облачная платформа Windows Azure имеет сервис таблиц, которые предоставляет доступ к данным, хранящимся в таблицах Windows Azure, и соответствующий API построен на использовании OData. Как упоминалось, проект Microsoft Dallas является централизованной площадкой для поиска и запроса данных, предоставляемых сервисом Dallas, и этот сервис обеспечивает доступ к своим данным по протоколу OData. Кроме того, провайдеры данных OData не ограничены только продуктами Microsoft; в частности, IBM недавно объявила, что ее продукт WebSphere eXtreme Scale 7.0 теперь поддерживает протокол OData.

Клиент Silverlight

Приложение Contoso для поиска недвижимости теперь имеет, во-первых, веб-сервис ASP.NET, который предоставляет реляционные данные из SQL Server с информацией о лотах и недвижимости, управляемой компанией, во-вторых, сайт SharePoint, применяемый для управления сведениями об агентах по продаже недвижимости, и, в-третьих, государственный веб-сервис, предоставляющий информацию о местности вокруг рекламируемой компанией недвижимости. Я хочу соединить все эти источники в одно приложение Silverlight, которое сможет осмысленно работать с этими данными.

В Silverlight 3 клиентская библиотека WCF Data Services включается в Silverlight SDK, который упрощает взаимодействие приложений Silverlight с сервисом, поддерживающим OData. Для этого в Visual Studio из проекта Silverlight щелкните правой кнопкой мыши проект и выберите Add Service Reference. В итоге это позволит добавить ссылку на сервис. Главное, что вы должны ввести, — URI сервиса, на который есть ссылка из приложения Silverlight. На рис. 7 показан пример добавления ссылки на сервис-пример OGDI.

Рис. 7. Добавление ссылки на сервис-пример OGDI

Мастер добавления ссылки на сервис создает контекст на клиентской стороне, используемый для взаимодействия с сервисом данных. Клиентский контекст абстрагирует детали работы с HTTP и URI в модели программирования на клиентской стороне и позволяет разработчику клиента сосредоточиться исключительно на C#-классах и XAML. Клиентский контекст также включает реализацию LINQ-провайдера, что обеспечивает поддержку LINQ-запросов к прокси. Кроме того, мастер Add Service Reference генерирует набор классов клиентских прокси, отражающих типы, которые предоставляются сервисом. Создав ссылку на сервис OGDI, я также добавляю ссылки на уже готовые сервисы SharePoint и Listings. Следующий код показывает, как создавать контексты, применяемые для взаимодействия с этими тремя сервисами OData:

На рис. 8 приведен внешний вид приложения Home Finder на Silverlight. Оно будет размещено в SharePoint, чтобы к нему могли легко обращаться мои существующие пользователи, привыкшие работать в среде SharePoint.

Рис. 8. Contoso Home Finder

На рис. 9 представлен код для запроса сервиса Listings и связывания результата с элементом управления «сетка» в верхней части окна приложения Home Finder.

Рис. 9. Создание контекстов клиентских прокси

Код на рис. 9 создает DataServiceCollection — отслеживаемый набор — и привязывает его к свойству ItemsSource основной сетки лотов. Поскольку этот набор реализует отслеживание изменений, любое изменение, внесенное в элементы сетки, будет автоматически отражаться на сущностях в наборе лотов. Изменения, внесенные в сетке, можно сохранять в сервисе вызовом метода BeginSaveChanges контекста для сервиса Listings.

В Silverlight все сетевые вызовы осуществляются асинхронно, поэтому выполнение любых операций с сервисом с применением клиентской библиотеки WCF Data Services требует начального вызова операции и написания отдельного метода обратного вызова, передаваемого для последующей обработки результата асинхронного вызова. Чтобы упростить работу с асинхронными вызовами, в класс DataServiceCollection был добавлен метод LoadAsync, который берет на себя выполнение всей работы с функцией обратного вызова и загрузки результатов в набор.

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

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

На рис. 9 показано, как запросить у сервиса SharePoint сущность агента, передав ему имя агента. Похожий код используется для запроса от OGDI статистических данных по криминогенной обстановке в близлежащей местности на диаграмме внизу страницы Home Finder. Код вплоть до этого момента демонстрирует только возможности запросов клиента Silverlight, но такой клиент не ограничен одними запросами; он располагает богатыми средствами для обратной записи изменений в сервис.

Рис. 10. Выполнение асинхронного запроса

OData в PowerPivot

PowerPivot — новый инструмент бизнес-анализа информации в памяти, поставляемый как надстройка для Microsoft Excel 2010; за более подробными сведениями обращайтесь на сайт powerpivot.com. Этот инструмент поддерживает импорт больших наборов данных из источника данных, выполнение комплексного анализа информации и генерацию отчетов. PowerPivot может импортировать данные из разнообразных источников, в том числе прямо из каналов OData. Выбор From Data Feeds в PowerPivot (рис. 11) включает поддержку конечной точки OData-сервиса как адрес канала для импорта.

Рис. 11. PowerPivot импортирует данные из канала OData

На рис. 12 показана сводная диаграмма по статистике криминогенной обстановки в Вашингтоне, округ Колумбия, полученной от OGDI.

Рис. 12. Диаграмма PowerPivot на основе информации из канала OData

Диаграмма на рис. 12, использующая тот же набор данных, что и риэлтерское приложение в предыдущем примере, показывает сводные данные по каждому округу. Рекомендую скачать PowerPivot for Excel 2010 и импортировать данные с сайта OGDI по ссылке ogdi.cloudapp.net/v1/dc, а потом самостоятельно убедиться, насколько быстро этот инструмент выполняет анализ этих данных.

Open Data Protocol Visualizer

OGDI-сервис данных, по сути, является «черным ящиком» для стороннего разработчика, который создает приложение, использующее данные от этого сервиса. К счастью, OGDI-сервис предоставляет свои данные по протоколу OData, поэтому знать детали внутреннего устройства сервиса для взаимодействия с ним не требуется. Модель программирования этого сервиса — протокол OData. Конечная точка сервиса описывает форму данных и, как я показывал в предыдущем разделе, это все, что вам нужно знать для взаимодействия с сервисом. Однако зачастую полезно видеть форму данных в сервисе и лучше понимать взаимосвязи между частями сервиса. Именно с этой целью и был создан Open Data Protocol Visualizer. Он доступен из меню Tools | Extension Manager в Visual Studio 2010. На рис. 13 даны два представления, с помощью которых этот визуализатор отображает структуру данного OGDI-сервиса.

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

Рис. 13. Представления сервиса-примера OGDI в Open Data Protocol Visualizer

Где узнать больше

Эта статья — не более чем введение в Open Data Protocol и экосистему, построенную вокруг него, включая инфраструктуру WCF Data Services. Дополнительные сведения можно получить на веб-сайте Open Data Protocol по адресу odata.org. Дополнительные сведения по WCF Data Services можно получить по адресу msdn.microsoft.com/data/bb931106 или в блоге по WCF Data Services по адресу blogs.msdn.com/astoriateam.

Шейн Бургес (Shayne Burgess) — менеджер программ в группе Microsoft Data and Modeling, занимается WCF Data Services и Open Data Protocol. Регулярно публикует статьи в блоге группы WCF Data Services blogs.msdn.com/b/astoriateam.

Выражаю благодарность за рецензирование статьи эксперту: Элизе Фласко (Elisa Flasko) и Майку Фласко (Mike Flasko)

Источник

Руководство по протоколу OData

Изучите протокол OData, который позволяет легко получить доступ к наборам данных с помощью API RESTFul.

1. Введение

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

2. Что такое OData?

OData является стандартом OASIS и ISO/IEC для доступа к данным с помощью API RESTful. Таким образом, он позволяет потребителю обнаружить и перемещаться по наборам данных с помощью стандартных вызовов HTTP.

Например, мы можем получить доступ к одному из общедоступные услуги OData с простым локон одной линии :

Наличие стандартного протокола для доступа к набору данных приносит некоторые преимущества по отношению к стандартным API, таким как JDBC или ODBC. Как потребитель уровня конечных пользователей, мы можем использовать популярные инструменты, такие как Excel для получения данных от любого совместимого поставщика. Программированию также способствует большое количество доступных клиентских библиотек REST.

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

3. Концепции OData

В основе протокола OData находится концепция модели данных сущности – или EDM для краткости. EDM описывает данные, выставленные поставщиком OData через метаданный документ, содержащий ряд мета-сущностей:

Возвращенный документ содержит кучу XML, описывающих схемы, поддерживаемые этим сервером:

Давайте разорвем этот документ на его основные разделы.

Элемент верхнего уровня, может иметь только одного ребенка, элемент . Важно заметить здесь пространство имен URI, поскольку это позволяет нам определить, какую версию OData использует сервер. В этом случае пространство имен указывает на то, что у нас есть сервер OData V2, который использует идентификаторы Майкрософт.

3.1. Элемент EntityType

Этот элемент определяет доступные свойства данной сущности, включая ее основной ключ. Он также может содержать информацию о взаимоотношениях с другими типами схем и, глядя на пример – Кармейкер – Мы сможем увидеть, что он не сильно отличается от описаний, найденных в других технологиях ORM, таких как JPA:

НавигацияПропертия это особый вид свойства, описывая «точку доступа» к связанной сущности.

3.2. Элемент ассоциации

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

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

3.3. Элемент EntitySet

EntityContainer элемент, который является элементом схемы верхнего уровня, группы всех доступных EntitySet секунда:

4. URL-адреса и методы OData

Для доступа к данным, выставленным службой OData, мы используем обычные глаголы HTTP:

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

Давайте рассмотрим пример URL, используемый для доступа к нашей предыдущей службе OData:

Возвращенный документ содержит входные элемент для каждого Кармейкер пример.

Давайте подробнее рассмотрим, какая информация у нас есть:

Важным моментом, который следует заметить здесь, является использование пары значений ключей для идентификации конкретной сущности в наборе сущностей. В нашем примере ключ числов, поэтому такой ресурсный путь, как CarMaker (1L) относится к сущности с первичным ключевым значением, равным 1 – ” L ” здесь просто обозначает долго значение и может быть опущено.

5. Параметры запроса

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

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

Мы можем перемещаться по большому набору данных с помощью $top $skip параметры запроса:

$top сообщает службе, что мы хотим только первые 10 записей Автопроизводители набор сущностей. $skip, который применяется до $top, говорит серверу пропустить первые 10 записей.

Обычно полезно знать размер данного Набор объектов и для этого мы можем использовать $count суб-ресурс:

Этот ресурс производит текст/обычная документ, содержащий размер соответствующего набора. Здесь мы должны обратить внимание на конкретную версию OData, поддерживаемую поставщиком. В то время как OData V2 $count как суб-ресурс из коллекции, V4 позволяет использовать его в качестве параметра запроса. В этом случае $count является Boolean, поэтому мы должны изменить URL соответственно:

Мы используем $filter опция запроса ограничить возвращенные объекты из данного Набор объектов тем, кто соответствует данным критериям. Значение для $filter является логическим выражением, которое поддерживает основных операторов, группировку и ряд полезных функций. Например, давайте построим запрос, который возвращает все Кармейкер случаи, когда его Название атрибут начинается с буквы ‘B’:

Теперь давайте объединим несколько логических операторов для поиска Кармоделс конкретного Год и Создатель :

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

Используя наш выборочных доменов, давайте построим URL-адрес, который возвращает данные из данной модели и его создатель, таким образом избегая дополнительной поездки туда и обратно на сервер:

Возвращенный документ теперь включает в себя Кармейкер данные как часть связанной сущности:

Давайте использовать эту опцию в запросе, который возвращает только Название и Ску свойства:

Полученный документ теперь имеет только запрошенные свойства:

Мы также видим, что даже связанные сущности были опущены. Для того, чтобы включить их, мы должны включить название отношения в $select выбор.

$orderBy опция работает в значительной степени, как его аналог S’L. Мы используем его для порядок, в котором мы хотим, чтобы сервер вернул данный набор сущностей. В более простой форме его значением является лишь список имен свойств выбранной организации, дополнительно информирующий направление заказа:

Этот запрос приведет к списку Кармоделс приказал их имена и SKUs, в восходящих и нисходящих направлениях, соответственно.

Например, мы можем использовать Json в качестве аббревиатуры для приложение/json :

Этот URL-адрес поручает нашему сервису возвращать данные в формате JSON, а не XML, как мы видели раньше. Когда эта опция не присутствует, сервер будет использовать значение Примите заголовок, если присутствует. Когда ни один из них не доступен, сервер может свободно выбирать любое представительство – обычно XML или JSON.

Что касается JSON в частности, это принципиально схематично. Тем не менее, OData 4.01 определяет схема JSON для конечных точек метаданных тоже. Это означает, что теперь мы можем писать клиентам, которые могут полностью избавиться от обработки XML, если они захотят сделать это.

6. Заключение

В этом кратком введении к OData, мы рассмотрели его основные семантики и как выполнять простую навигацию набора данных. Наша последующая статья будет продолжаться там, где мы уехали и идти прямо в библиотеку Olingo. Затем мы увидим, как реализовать примеры служб с помощью этой библиотеки.

Примеры кода, как всегда, доступны более чем на GitHub.

Источник