LINUX.ORG.RU
ФорумTalks

Microsoft делает клиент OData открытым


0

0

Совсем недавно Microsoft сделала заявление, что её отношение к сообществу opensource меняется. И подтверждение этих слов не заставило себя долго ждать. Microsoft открывает исходные кода клиента для протокола Open Data Protocol (OData). Итак, что же это за протокол и чем он выгодно отличается от решений конкурентов?

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

Протокол OData использует несколько другой подход. Для любой конечной точки сервиса на основе OData (например, http://odata.netflix.com/Catalog/CatalogTitles) можно сделать запрос на выдачу информации с обработкой результатов (например, ограничить диапазон или указать что-то конкретное).

Например:

  • фильмы, выпущенные в этом году ($filter=ReleaseYear eq 2010);
  • фильмы, выпущенные в этом году, со словом «банк» в описании ($filter=substringof('bank',Synopsis) and ReleaseYear eq 2010).

Microsoft предоставляет клиентские библиотеки для большого числа платформ: JavaScript, Java, PHP, .NET и Objective-C bindings. А с настоящего момента доступны и исходные коды клиентской библиотеки для .NET под лицензией Apache 2. Как уже заявил Мигель де Икаса в своём блоге, он намерен в ближайшее время включить поддержку открытого протокола в платформу Mono в библиотеку System.Data.Services.

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

Информация об OData на MIX Sessions.

Подробное описание протокола.

Перемещено Aceler из OpenSource

★★★★
Ответ на: комментарий от KDE41user

>>Они изобрели xml-rpc? Слава!

Это ведет к чрезмерному усложнению протокола и усложняет поддержку сервиса. В серьезных конторах это не используют.

MuZHiK-2 ★★★★
() автор топика
Ответ на: комментарий от MuZHiK-2

> Это ведет к чрезмерному усложнению протокола и усложняет поддержку сервиса. В серьезных конторах это не используют.

обосновать можно?

namezys ★★★★
()
Ответ на: комментарий от namezys

>>обосновать можно?

А что тут обосновывать? Если бы ты плотно возился с этим, то знал бы, что rpc ведет к укрупнению сервисов, в итоге приходится все пичкать вместе, как следствие ментейнить такое становится все сложнее, не говоря уже про удобство расширяемости/масштабируемости.

MuZHiK-2 ★★★★
() автор топика
Ответ на: комментарий от MuZHiK-2

> Если бы ты плотно возился с этим, то знал бы, что rpc ведет к укрупнению сервисов, в итоге приходится все пичкать вместе, как следствие ментейнить такое становится все сложнее, не говоря уже про удобство расширяемости/масштабируемости.

У нас все работает через rpc. Проблем нет

namezys ★★★★
()
Ответ на: комментарий от MuZHiK-2

>>Они изобрели xml-rpc? Слава!

Это ведет к чрезмерному усложнению протокола и усложняет поддержку сервиса. В серьезных конторах это не используют.

Ясно, что ведет к усложнению. Затем и придумали рест. Теперь внимательно читай свою новость:

Для любой конечной точки сервиса на основе OData (например, http://odata.netflix.com/Catalog/CatalogTitles) можно сделать запрос на выдачу информации с обработкой результатов

запрос [...] с обработкой результатов

Чем _принципиально_ это отличается от рпс и почему оно не усложняет поддержку? Я должен знать, какие фильтры накладывать, так чем оно отличается от знания функций, которые нужно вызывать? Меньше хмл-а гоняет? Так исправят к следующей версии.

KDE41user
()
Ответ на: комментарий от namezys

>>У нас все работает через rpc. Проблем нет

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

MuZHiK-2 ★★★★
() автор топика
Ответ на: комментарий от MuZHiK-2

> Я не говорю, что для каких-то небольших контор это не подходит. Но надо понимать, что у всего есть свой разумный предел.

Чем плох rpc при модульности сервера?

namezys ★★★★
()
Ответ на: комментарий от KDE41user

>>Ясно, что ведет к усложнению. Затем и придумали рест.

Ты собираешься в крупной компании или крупные сервисы строить на голом ресте? Лучше сразу в биореактор.

Чем _принципиально_ это отличается от рпс и почему оно не усложняет поддержку? Я должен знать, какие фильтры накладывать, так чем оно отличается от знания функций, которые нужно вызывать? Меньше хмл-а гоняет? Так исправят к следующей версии.

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

MuZHiK-2 ★★★★
() автор топика
Ответ на: комментарий от namezys

>>Чем плох rpc при модульности сервера?

Тем, что ограничивает способы работы с сервером.

MuZHiK-2 ★★★★
() автор топика
Ответ на: комментарий от MuZHiK-2

>голом ресте

есть спеки, в отличие от реста.

Ты упоротый. REST - это подход к архитектуре, не более. Протокол есть, библиотек, работающих с http, тысячи. Какие тебе спеки нужны и в чем «голость» реста?

KDE41user
()
Ответ на: комментарий от KDE41user

>>Ты упоротый. REST - это подход к архитектуре, не более. Протокол есть, библиотек, работающих с http, тысячи. Какие тебе спеки нужны и в чем «голость» реста?

Ты сам только что обосрал самого себя. Вот именно, что рест - это архитектура, поэтому и нету никаких четких спек. Каждый делает это по своему. Конечному клиенту не нужны тысячи либ - ему нужно чтобы работало и четко.

MuZHiK-2 ★★★★
() автор топика
Ответ на: комментарий от MuZHiK-2

>Каждый делает это по своему.

Если сабжевый протокол нужен, чтобы унифицировать доступ к всем вебсервисам, то так и напиши, посмеемся вместе. А если каждый Вася Пупкин будет делать себе локальное решение, то каким боком его сервис будет совместим с сервисом Пети Дупкина?

KDE41user
()
Ответ на: комментарий от KDE41user

>>Если сабжевый протокол нужен, чтобы унифицировать доступ к всем вебсервисам, то так и напиши, посмеемся вместе. А если каждый Вася Пупкин будет делать себе локальное решение, то каким боком его сервис будет совместим с сервисом Пети Дупкина?

Идея не в унификации сервисов, в в унификации ДОСТУПА к сервисам + получение только НУЖНОЙ мне инфы от сервиса при необходимости. При этом тебя не ограничивают, как работать с сервисом - через rpc, через rest.

MuZHiK-2 ★★★★
() автор топика
Ответ на: комментарий от Manhunt

>>Кстати, что там с патентной чистотой? Open Specification Promise?

Да, выпускается под OSP. Так что с патентами все в порядке. Другой вопрос в том, что оно еще не стандартизировано, но это вопрос времени. Office 2010, например, уже использует OData.

MuZHiK-2 ★★★★
() автор топика
Ответ на: комментарий от MuZHiK-2

>Да, выпускается под OSP. Так что с патентами все в порядке.

Да ладно, можно закапывать, открыли под APL2 только «коды клиентской библиотеки для .NET» - без сервера работать собственно не будет. :)

fi ★★★
()
Ответ на: комментарий от fi

>>Да ладно, можно закапывать, открыли под APL2 только «коды клиентской библиотеки для .NET» - без сервера работать собственно не будет. :)

Спеки на сервер в открытом доступе - пиши как хочешь и под любой лицензией.

MuZHiK-2 ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.