OASIS стандартизует открытый протокол OData

    odata

    Открытый протокол запросов OData базирующийся на REST, Atom/XML и JSON будет стандартизирован организацией OASIS, которая отвечает за утверждение промышленных стандартов в области веб-сервисов и передачи данных.

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

    _http://services.odata.org/OData/OData.svc/Category(1)/Products?$top=2&$orderby=name

    Просит выбрать из источника данных первые два продукта отсортированные по имени, которые принадлежат определенной категории товаров с идентификатором "1". Другой пример:

    _http://services.odata.org/OData/OData.svc/ProductsByColor?color='red'

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

    _http://services.odata.org/Northwind/Northwind.svc/Customers?$filter=indexof(CompanyName, 'lfreds') eq 1

    Вернет всех клиентов с именем компании, которая содержит подстроку "lfreds". И так далее. Подробное описание нотаций и самого протокола можно найти по адресу http://www.odata.org/documentation.

    Odata сегодня


    Сегодня на официальном сайте OData предлагается масса готовых библиотек для реализации доступа к данным на разных платформах и языках:

    clip_image001

    Стандартизация


    Протокол OData был достаточно давно разработан в Microsoft и сначала носил название ADO.NET Data Services. Механизм получился настолько хорошим, что сторонние компании предложили вынести протокол отдельно от платформы .NET и после формирования открытой спецификации OData его реализация в .NET стала носить название WCF Data Services.

    Сегодня OData используется в массе продуктов Microsoft и сторонних компаний: Excel, SharePoint, SQL Server Reporting Services, Dynamics CRM, Windows Server и Windows Azure. Более полно узнать о уже существующей экосистеме OData можно на отдельной странице официального сайта http://www.odata.org/ecosystem.

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

    Все спецификации и документация по протоколу OData доступны на официальном сайте http://www.odata.org/. Дополнительную информацию о стандартизации можно найти в этой записи блога MSDN
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 33

      –2
      facepalm.jpg.to

      Ни REST, ни XML-RPC. И опять от небольших и нетвердых.

      Не нужно.
        0
        Вы бы почитали сначала что это такое.
          0
          Спасибо. 5 лет использую, теперь пойду почитаю, что ж я использовал-то.
            +2
            Так оно ведь не нужно? Что ж вы использовали-то?
              –4
              Хабр из русского языка сделал что-то странное. Вроде бы очевидные и однозначные вещи приходится разжевывать.

              То что предлагают как oData, уже было, как rest и как xml-rpc. Я использовал и то, и другое (оно было нужно, rest — точно, xml-rpc — сомнительно). Зачем еще нужно тут третье — не понимаю.
                +3
                Насколько я понимаю, vittore предлагал вам прочитать об oData. Вы ответили, что уже 5 лет используете, отсюда и мой комментарий. Так что очевидные и однозначные вещи приходится разжёвывать именно для вас.
        –1
        Такое ощущение, что кто-то стремится усложнять всем жизнь. Либо это способ дать программистам работу?
          0
          Небольшие и нетвердые всегда этим славились. Помнишь «девелоперс, девелоперс....»?

          Создать язык запросов, и по-сложней. Что б были трактовки реализаций, а потом их вариации. Такой SQL для CGI. Со стандартизацией, спецификациями, WSDL-like описаниями схем и прочими радостями. Искаропки работающим в Visual Шtudio, c черезпеньколодной открытой реализацией (лучше двумя, несовместыми между собой, visual-studi'йной и, тем более, oasis'ной)… Понятно, что только о разработчиках они и заботятся.
            –1
            — * CGI читать как HTTP.
          +5
          В данный момент проходим этап тестирования внедрения oData протокола в проект — все просто замечательно. По сравнению с другими «стандартизированными» решениями, oData — просто прорыв! Да, местами немного не совсем интуитивный синтаксис, но к нему привыкаешь. Возможности перекрывают все недостатки с лихвой.
            –7
            _http://services.odata.org/Northwind/Northwind.svc/Customers?$filter=indexof(CompanyName, 'lfreds') eq 1

            Не интуитивный? Экранирование, для начала, где?
              +3
              Экранирование чего, простите? Весь ваш GET хендлится веб-сервисом, который, будьте 100% уверены, пресечет все попытки инжектов (у нас так).

              Клиент должен иметь возможность на понятном языке составить более-менее интуитивный запрос, и получить то, что он хочет. С oData это проще простого!
                0
                Практика использования REST, вкупе с диалектами SQL, говорит мне, что ничего хорошего из вашего odata не выйдет. Начинание хорошее, бесспорно, но реализаций, совместимых и (в основном) не особо — будет вагон и немаленькая такая тележка.

                Соответственно и итоговый профит сомнительный.

                Сейчас есть куча REST-совместимых API к базам данных. CouchDB, Riak, MongoDB. Они (API) все несовместимы не от хорошей жизни, а, как минимум, потому что базы разные (кэп, да), запросы и потребности разные, и функционал баз данных абсолютно разный. Грести их все под одну гребенку — получим никому не нужную (см. мой первый коммент), но стандартизированную (sql тоже стандартизирован, и че? Диалекты, реализации, версии, десяток реализаций, сотня врапперов) спецификацию.
                  +3
                  Принимаю роль кэпа — задача OASIS как раз сделать так, чтобы все запросы oData, везде выдавали один и тот же результат (на сколько это возможно).

                  Представьте себе стандартную API для получения мыла из эксчейнджа, гугла, мсн, меилру, и т.п. — разве не счастье?
                    –4
                    > Представьте себе стандартную API для получения мыла из эксчейнджа, гугла, мсн, меилру, и т.п. — разве не счастье?

                    Не выйдет. В эксчейндже будет indexof, в гугле indexOf, в msn не будет ни того, ни другого, а будет TheIndexOf, в мейлру не будет вообще. В итоге напишут враппер для всех четырех (что за подборка-то? ужас), который будет эмулировать часть функций путем предкеширования на левом сервере. И снова — не нужно.
                      +5
                      Смиритесь, и перестаньте тормозить прогресс.

                      Мы уже сыты всеми возможными способами коммуникаций, костылями к ним, патчами и фиксами. Хочется иметь один (как HTTP) протокол, который везде будет значить одно и то же. У oData все шансы стать им. Меня (и мою компанию) он устраивает, и поэтому я приложу все усилия для его продвижения и стандартизации.

                      P.S. К примеру, браузеры уже поняли провальность своей войны — все движковые префиксы скоро канут в лету.
                        –6
                        Стандартизируйте тогда SQL. Не вижу принципиальной разницы между ним и oData.
                          +3
                          «Больше не кормлю»
                            –5
                            Мва-ха-ха. Т.е. это я троллить начал? А пост тогда о чём? :)))
                            +1
                            А про sql/92 нет, не слышал.
                              –1
                              Да-да. И много баз данных его на 100% реализуют?
                        –1
                        > API для получения мыла из эксчейнджа, гугла, мсн, меилру, и т.п. — разве не счастье?

                        Чё-т я пропустил ключевое слово.

                        Для получения мыла уже есть два API — pop3 и imap. Если копать глубже, нароем pop4 и почти с десяток версий imap. Хотите еще одно API? To rule them all? Ну тогда у нас будет +1 API для получения почты.
                      –1
                      > Экранирование чего, простите?

                      Экранирование параметров в примере забыли. Если для красоты отображения, можно было не в урле зарисовывать. Меня, например, мутит при взгляде на такие типаурлы. Вроде и урл, а экранировать забыли. Соответственно, копипаст перед 'curl' в консоль что-то да сломает.
                    0
                    Если не секрет — что на серверной стороне? WCF DataServices?
                    И еще, вы свой IQueriable интерфейс писали или у вас чистый EF?
                      +1
                      Может быть напишите обзорный топик с примерами об OData? Мне было бы очень любопытно прочитать?
                      –6
                      _http://services.odata.org/Northwind/Northwind.svc/Customers?$filter=indexof(CompanyName, 'lfreds') eq 1

                      Не интуитивный? Экранирование, для начала, где?
                        –7
                        Ахтунг! Пост зла! Все комментящие по делу получают минусы.
                          +2
                          По-моему не все, а один angry_elf. К чему бы это?
                            0
                            Очевидно, это было предупреждение. Но я не понял главного — пост был настолько не интересен вообще никому, что я сам сюда зря полез.
                          0
                          [xkcd, стандарты]
                            0
                            Не могу понять, почему в этом формате не предусмотрена система прав доступа, если я ничего не пропустил (смотрел спеку очень бегло).

                            Если кто-то с этим работает, расскажите пожалуйста, как вы решаете проблему управления доступом.
                              0
                              Система прав доступа решается по своему в каждой реализации. В WCF Data Services есть QueryInterceptor и ChangeInterceptor
                                0
                                Это же REST-сервисы, система прав доступа устанавливается тем бэкендом, которые вы для REST используете

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

                              Самое читаемое