А что тут думать, у гугла все написано прямым текстом:
Many services at Google provide external access to data and functionality through APIs that utilize the Google Data Protocol.
Естественно, gData. А у МСа надо разогнать маркетологов к чертям. Как и на любом их сайте — тонна воды, а что именно делает тот или иной их сервис ≈ хрен узнаешь.
MS предоставляет открытый протокол, который поддерживает большее количество клиентов, включая сильверлайт в браузере и windows phone. Стандартная реализация сервера на .Net. Поддержка в новых фреймворках разработки (Asp.Net MVC, etc).
Например с помощью связки OData + WFC + Entity Framework можно вообще пропустить шаг разработки серверной части — писать запросы к разрешенным таблицам можно прямо на клиенте в javascript коде.
Отдельной строкой идет встроенная поддержка в Visual Studio через WCF сервисы.
Ах ну да. Еще новые версии офиса и шарепойнта поддерживают его. Azure и его сервисы. А также Facebook, Netflix, Stackoverflow, etc.
Дьявол как обычно в деталях. Но из общих рассуждений — я делаю ставку на OData.
Здравствуйте, Mamut, Вы писали:
M>А что тут думать, у гугла все написано прямым текстом: M>
M>Many services at Google provide external access to data and functionality through APIs that utilize the Google Data Protocol.
M>Естественно, gData. А у МСа надо разогнать маркетологов к чертям. Как и на любом их сайте — тонна воды, а что именно делает тот или иной их сервис ≈ хрен узнаешь.
Вообще-то OData — это отнюдь не сервис. Это протокол обмена данными. Правильный SOAP. С мощной поддержкой от МС.
Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, Mamut, Вы писали:
M>>А что тут думать, у гугла все написано прямым текстом: M>>
M>>Many services at Google provide external access to data and functionality through APIs that utilize the Google Data Protocol.
M>>Естественно, gData. А у МСа надо разогнать маркетологов к чертям. Как и на любом их сайте — тонна воды, а что именно делает тот или иной их сервис ≈ хрен узнаешь.
Кэр>Вообще-то OData — это отнюдь не сервис. Это протокол обмена данными. Правильный SOAP. С мощной поддержкой от МС.
Мнээээ.. И?
Кэр>Но если вам нужен текст, кто поддерживает OData — то это прямо на втором табе: Кэр>http://www.odata.org/producers
Кэр>А кто поддерживает gData кроме Гугла? Пользователи Google Gears?
При чем тут Google Gears. Nам прямым текстом написано выделенное. Понятно, что это, понятно, где оно испольхуется. Сервисами гугоа пользуются все, кому не лень, они понятно, зачем существуют, и понятно, зачем нужны. То, что MS придумал еще один SOAP никому нафиг не упало и не интересно.
OData is being used to expose and access information from a variety of sources including, but not limited to, relational databases, file systems, content management systems and traditional Web sites.
Чем то лучше того же YQL вооще никому не известно. А чем вот это все лучше того же RDF'а понятно еще меньше
Здравствуйте, Mamut, Вы писали:
M>Чем то лучше того же YQL вооще никому не известно. А чем вот это все лучше того же RDF'а понятно еще меньше
Справедливости ради — RDF мало кому понятен.
Здравствуйте, Mamut, Вы писали:
M>>>Естественно, gData. А у МСа надо разогнать маркетологов к чертям. Как и на любом их сайте — тонна воды, а что именно делает тот или иной их сервис ≈ хрен узнаешь.
Кэр>>Вообще-то OData — это отнюдь не сервис. Это протокол обмена данными. Правильный SOAP. С мощной поддержкой от МС.
M>Мнээээ.. И?
И то, что я не понимаю при чем тут наезд на какой-то "сервис".
Кэр>>Но если вам нужен текст, кто поддерживает OData — то это прямо на втором табе: Кэр>>http://www.odata.org/producers
Кэр>>А кто поддерживает gData кроме Гугла? Пользователи Google Gears?
M>При чем тут Google Gears.
Так просто — проехался по практике адаптации технологий от Гугла.
M>Nам прямым текстом написано выделенное. Понятно, что это, понятно, где оно испольхуется. Сервисами гугоа пользуются все, кому не лень, они понятно, зачем существуют, и понятно, зачем нужны.
Ну и если вы будете писать интеграцию с сервисами Гугла — то деваться будет некуда. Придется юзать gData. Нафиг это использовать в повседневной разработке своих сервисов —
M>То, что MS придумал еще один SOAP никому нафиг не упало и не интересно.
Как вы можете видеть это не так — иначе бы сторонние компании не вкладывались в разработку. То что это вам не интересно — это совершенно другой разговор, хотя вы и беретесь утверждать от имени "всех". Можно обсудить технические стороны этого вопроса. Пока вы технических аргументов не предоставили. А убеждать вас — у меня задачи не стоит.
Мне интересен как минимум тот факт, что REST изначально брался в ум, когда проектировался протокол OData, а также тот факт что офис/шарепойнт/Azure/Facebook имеют поддержку этого протокола. Я не знаю, какое значение в ваших глазах имеют эти сервисы — но уверяю вас что пара пользователей у них найдется.
M>
M>OData is being used to expose and access information from a variety of sources including, but not limited to, relational databases, file systems, content management systems and traditional Web sites.
M>Чем то лучше того же YQL вооще никому не известно. А чем вот это все лучше того же RDF'а понятно еще меньше
Хотя бы тем что есть стандартная поддержка в .Net от Microsoft. В дебри протоколов даже не надо лезть, чтобы на это ответить.
Кэр>>>А кто поддерживает gData кроме Гугла? Пользователи Google Gears?
M>>При чем тут Google Gears.
Кэр>Так просто — проехался по практике адаптации технологий от Гугла.
Сервисы гугла пользуют все, кому не лень. Благо, их много, и пользоваться ими удобно.
M>>То, что MS придумал еще один SOAP никому нафиг не упало и не интересно.
Кэр>Как вы можете видеть это не так — иначе бы сторонние компании не вкладывались в разработку.
В разработку вкладываются, судя по списку, только компании, с которыми MS тесно сотрудничает.
Кэр>То что это вам не интересно — это совершенно другой разговор, хотя вы и беретесь утверждать от имени "всех". Можно обсудить технические стороны этого вопроса. Пока вы технических аргументов не предоставили. А убеждать вас — у меня задачи не стоит.
Кэр>Мне интересен как минимум тот факт, что REST изначально брался в ум, когда проектировался протокол OData, а также тот факт что офис/шарепойнт/Azure/
Кто бы сомневался
Кэр>Facebook имеют поддержку этого протокола.
Facebok не имеет поддержки этого протокола. На странице OData показано какое-то приложение, которое проксирует фейсбучный OpenGraph в OData.
Кэр>Я не знаю, какое значение в ваших глазах имеют эти сервисы — но уверяю вас что пара пользователей у них найдется.
Как и у любого сервиса.
M>>
M>>OData is being used to expose and access information from a variety of sources including, but not limited to, relational databases, file systems, content management systems and traditional Web sites.
M>>Чем то лучше того же YQL вооще никому не известно. А чем вот это все лучше того же RDF'а понятно еще меньше
Кэр>Хотя бы тем что есть стандартная поддержка в .Net от Microsoft. В дебри протоколов даже не надо лезть, чтобы на это ответить.
Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>>Кто что думает про AS>>Miscrosoft — http://www.odata.org AS>>и AS>>Google — http://code.google.com/apis/gdata/
AS>>Кто из них круче, кто перспективнее, кто выживет?
Кэр>MS предоставляет открытый протокол, который поддерживает большее количество клиентов, включая сильверлайт в браузере и windows phone. Стандартная реализация сервера на .Net. Поддержка в новых фреймворках разработки (Asp.Net MVC, etc).
Кэр>Например с помощью связки OData + WFC + Entity Framework можно вообще пропустить шаг разработки серверной части — писать запросы к разрешенным таблицам можно прямо на клиенте в javascript коде.
Неужели ктото так делает? Это ж такая дыра в security!
Здравствуйте, henson, Вы писали:
Кэр>>Например с помощью связки OData + WFC + Entity Framework можно вообще пропустить шаг разработки серверной части — писать запросы к разрешенным таблицам можно прямо на клиенте в javascript коде.
H>Неужели ктото так делает? Это ж такая дыра в security!
Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, henson, Вы писали:
Кэр>>>Например с помощью связки OData + WFC + Entity Framework можно вообще пропустить шаг разработки серверной части — писать запросы к разрешенным таблицам можно прямо на клиенте в javascript коде.
H>>Неужели ктото так делает? Это ж такая дыра в security!
Кэр>Выделил жирным шрифтом специально для вас.
Это очень похоже на классическую рекламу МС.
— Вы можете делать сайты без строчки кода на С# (2003 год)
— Вы можете делать Ajax сайты без строчки Javascript кода (2005 год)
— Вы можете делать сайты без написания SQL кода (2008 год)
— Вы можете писать сайты на Javascript
Вы же сами хорошо знаете чем отличается слой Business Layer от слоя Data Access. OData = Data Access, а BL будет весь на клиенте?
Ну как-то несерьёзно...
Здравствуйте, PDmitry, Вы писали:
PD>Это очень похоже на классическую рекламу МС.
PD>- Вы можете делать сайты без строчки кода на С# (2003 год)
А разве нет?
PD>- Вы можете делать Ajax сайты без строчки Javascript кода (2005 год)
А разве нет? Многие и сейчас так делают.
PD>- Вы можете делать сайты без написания SQL кода (2008 год)
Это правда. Я за полгода почти не написал ничего.
PD>- Вы можете писать сайты на Javascript
на самом деле "Вы можете обращаться к реляционной субд на js"
Тоже правда.
Конечно эволюционируют понятия о написании программ и старые подходы признаются ошибочными, но это не делает их менее рабочими.
PD> Вы же сами хорошо знаете чем отличается слой Business Layer от слоя Data Access.
Вообще говоря отличия только в голове программиста.
PD>OData = Data Access, а BL будет весь на клиенте?
У тебя — возможно, другие не будут совершать подобных ошибок.
PD>Ну как-то несерьёзно...
Очень серьезно, разбираться надо.
Здравствуйте, gandjustas, Вы писали:
PD>>- Вы можете делать сайты без написания SQL кода (2008 год) G>Это правда. Я за полгода почти не написал ничего.
В смысле почти ничего на SQL.
Здравствуйте, Sinix, Вы писали:
AS>>Кто что думает про S>Вот не надо всё усложнять, первое — это протокол для доступа к сервисам МС, второй — гугля S>Ок, помимо REST и WS-* у нас очередные два модных протокола. Щастья-то...
REST — не протокол, а идея, что протокол приложения должен использовать фичи HTTP, а не абстрагироваться от них.
Здравствуйте, Кэр, Вы писали:
AS>>Кто что думает про AS>>Miscrosoft — http://www.odata.org AS>>и AS>>Google — http://code.google.com/apis/gdata/
AS>>Кто из них круче, кто перспективнее, кто выживет?
Кэр>MS предоставляет открытый протокол, который поддерживает большее количество клиентов, включая сильверлайт в браузере и windows phone. Стандартная реализация сервера на .Net. Поддержка в новых фреймворках разработки (Asp.Net MVC, etc).
Кэр>Например с помощью связки OData + WFC + Entity Framework можно вообще пропустить шаг разработки серверной части — писать запросы к разрешенным таблицам можно прямо на клиенте в javascript коде.
На этой фразе у любого человека, мало-мальски разбирающегося в БД, должно ёкнуть сердце.
Здравствуйте, iHateLogins, Вы писали:
HL>Здравствуйте, Кэр, Вы писали:
AS>>>Кто что думает про AS>>>Miscrosoft — http://www.odata.org AS>>>и AS>>>Google — http://code.google.com/apis/gdata/
AS>>>Кто из них круче, кто перспективнее, кто выживет?
Кэр>>MS предоставляет открытый протокол, который поддерживает большее количество клиентов, включая сильверлайт в браузере и windows phone. Стандартная реализация сервера на .Net. Поддержка в новых фреймворках разработки (Asp.Net MVC, etc).
Кэр>>Например с помощью связки OData + WFC + Entity Framework можно вообще пропустить шаг разработки серверной части — писать запросы к разрешенным таблицам можно прямо на клиенте в javascript коде.
HL>На этой фразе у любого человека, мало-мальски разбирающегося в БД, должно ёкнуть сердце.
Здравствуйте, iHateLogins, Вы писали:
Кэр>>Например с помощью связки OData + WFC + Entity Framework можно вообще пропустить шаг разработки серверной части — писать запросы к разрешенным таблицам можно прямо на клиенте в javascript коде.
HL>На этой фразе у любого человека, мало-мальски разбирающегося в БД, должно ёкнуть сердце.
Я имею наглость утверждать, что мало-мальски разбираюсь в БД. Сердце почему-то не екает. Сложные запросы (когда приходится быть умнее SQL сервера, создавать временные таблицы и пр) возможно не удастся написать, но в мире есть огромное количество приложений, которые SQL используют очень прямолинейно.
Более того, выставлять наружу данные через данную технику как раз очень удобно. Огромное количество странных запросов от пользователей покрывается автоматически. Не надо ваять новый метод сервиса на новый запрос.
