Comments 33
facepalm.jpg.to
Ни REST, ни XML-RPC. И опять от небольших и нетвердых.
Не нужно.
Ни REST, ни XML-RPC. И опять от небольших и нетвердых.
Не нужно.
Вы бы почитали сначала что это такое.
Спасибо. 5 лет использую, теперь пойду почитаю, что ж я использовал-то.
Так оно ведь не нужно? Что ж вы использовали-то?
Такое ощущение, что кто-то стремится усложнять всем жизнь. Либо это способ дать программистам работу?
Небольшие и нетвердые всегда этим славились. Помнишь «девелоперс, девелоперс....»?
Создать язык запросов, и по-сложней. Что б были трактовки реализаций, а потом их вариации. Такой SQL для CGI. Со стандартизацией, спецификациями, WSDL-like описаниями схем и прочими радостями. Искаропки работающим в Visual Шtudio, c черезпеньколодной открытой реализацией (лучше двумя, несовместыми между собой, visual-studi'йной и, тем более, oasis'ной)… Понятно, что только о разработчиках они и заботятся.
Создать язык запросов, и по-сложней. Что б были трактовки реализаций, а потом их вариации. Такой SQL для CGI. Со стандартизацией, спецификациями, WSDL-like описаниями схем и прочими радостями. Искаропки работающим в Visual Шtudio, c черезпеньколодной открытой реализацией (лучше двумя, несовместыми между собой, visual-studi'йной и, тем более, oasis'ной)… Понятно, что только о разработчиках они и заботятся.
В данный момент проходим этап тестирования внедрения oData протокола в проект — все просто замечательно. По сравнению с другими «стандартизированными» решениями, oData — просто прорыв! Да, местами немного не совсем интуитивный синтаксис, но к нему привыкаешь. Возможности перекрывают все недостатки с лихвой.
_http://services.odata.org/Northwind/Northwind.svc/Customers?$filter=indexof(CompanyName, 'lfreds') eq 1
Не интуитивный? Экранирование, для начала, где?
Не интуитивный? Экранирование, для начала, где?
Экранирование чего, простите? Весь ваш GET хендлится веб-сервисом, который, будьте 100% уверены, пресечет все попытки инжектов (у нас так).
Клиент должен иметь возможность на понятном языке составить более-менее интуитивный запрос, и получить то, что он хочет. С oData это проще простого!
Клиент должен иметь возможность на понятном языке составить более-менее интуитивный запрос, и получить то, что он хочет. С oData это проще простого!
Практика использования REST, вкупе с диалектами SQL, говорит мне, что ничего хорошего из вашего odata не выйдет. Начинание хорошее, бесспорно, но реализаций, совместимых и (в основном) не особо — будет вагон и немаленькая такая тележка.
Соответственно и итоговый профит сомнительный.
Сейчас есть куча REST-совместимых API к базам данных. CouchDB, Riak, MongoDB. Они (API) все несовместимы не от хорошей жизни, а, как минимум, потому что базы разные (кэп, да), запросы и потребности разные, и функционал баз данных абсолютно разный. Грести их все под одну гребенку — получим никому не нужную (см. мой первый коммент), но стандартизированную (sql тоже стандартизирован, и че? Диалекты, реализации, версии, десяток реализаций, сотня врапперов) спецификацию.
Соответственно и итоговый профит сомнительный.
Сейчас есть куча REST-совместимых API к базам данных. CouchDB, Riak, MongoDB. Они (API) все несовместимы не от хорошей жизни, а, как минимум, потому что базы разные (кэп, да), запросы и потребности разные, и функционал баз данных абсолютно разный. Грести их все под одну гребенку — получим никому не нужную (см. мой первый коммент), но стандартизированную (sql тоже стандартизирован, и че? Диалекты, реализации, версии, десяток реализаций, сотня врапперов) спецификацию.
Принимаю роль кэпа — задача OASIS как раз сделать так, чтобы все запросы oData, везде выдавали один и тот же результат (на сколько это возможно).
Представьте себе стандартную API для получения мыла из эксчейнджа, гугла, мсн, меилру, и т.п. — разве не счастье?
Представьте себе стандартную API для получения мыла из эксчейнджа, гугла, мсн, меилру, и т.п. — разве не счастье?
> Представьте себе стандартную API для получения мыла из эксчейнджа, гугла, мсн, меилру, и т.п. — разве не счастье?
Не выйдет. В эксчейндже будет indexof, в гугле indexOf, в msn не будет ни того, ни другого, а будет TheIndexOf, в мейлру не будет вообще. В итоге напишут враппер для всех четырех (что за подборка-то? ужас), который будет эмулировать часть функций путем предкеширования на левом сервере. И снова — не нужно.
Не выйдет. В эксчейндже будет indexof, в гугле indexOf, в msn не будет ни того, ни другого, а будет TheIndexOf, в мейлру не будет вообще. В итоге напишут враппер для всех четырех (что за подборка-то? ужас), который будет эмулировать часть функций путем предкеширования на левом сервере. И снова — не нужно.
Смиритесь, и перестаньте тормозить прогресс.
Мы уже сыты всеми возможными способами коммуникаций, костылями к ним, патчами и фиксами. Хочется иметь один (как HTTP) протокол, который везде будет значить одно и то же. У oData все шансы стать им. Меня (и мою компанию) он устраивает, и поэтому я приложу все усилия для его продвижения и стандартизации.
P.S. К примеру, браузеры уже поняли провальность своей войны — все движковые префиксы скоро канут в лету.
Мы уже сыты всеми возможными способами коммуникаций, костылями к ним, патчами и фиксами. Хочется иметь один (как HTTP) протокол, который везде будет значить одно и то же. У oData все шансы стать им. Меня (и мою компанию) он устраивает, и поэтому я приложу все усилия для его продвижения и стандартизации.
P.S. К примеру, браузеры уже поняли провальность своей войны — все движковые префиксы скоро канут в лету.
> API для получения мыла из эксчейнджа, гугла, мсн, меилру, и т.п. — разве не счастье?
Чё-т я пропустил ключевое слово.
Для получения мыла уже есть два API — pop3 и imap. Если копать глубже, нароем pop4 и почти с десяток версий imap. Хотите еще одно API? To rule them all? Ну тогда у нас будет +1 API для получения почты.
Чё-т я пропустил ключевое слово.
Для получения мыла уже есть два API — pop3 и imap. Если копать глубже, нароем pop4 и почти с десяток версий imap. Хотите еще одно API? To rule them all? Ну тогда у нас будет +1 API для получения почты.
> Экранирование чего, простите?
Экранирование параметров в примере забыли. Если для красоты отображения, можно было не в урле зарисовывать. Меня, например, мутит при взгляде на такие типаурлы. Вроде и урл, а экранировать забыли. Соответственно, копипаст перед 'curl' в консоль что-то да сломает.
Экранирование параметров в примере забыли. Если для красоты отображения, можно было не в урле зарисовывать. Меня, например, мутит при взгляде на такие типаурлы. Вроде и урл, а экранировать забыли. Соответственно, копипаст перед 'curl' в консоль что-то да сломает.
Если не секрет — что на серверной стороне? WCF DataServices?
И еще, вы свой IQueriable интерфейс писали или у вас чистый EF?
И еще, вы свой IQueriable интерфейс писали или у вас чистый EF?
Может быть напишите обзорный топик с примерами об OData? Мне было бы очень любопытно прочитать?
_http://services.odata.org/Northwind/Northwind.svc/Customers?$filter=indexof(CompanyName, 'lfreds') eq 1
Не интуитивный? Экранирование, для начала, где?
Не интуитивный? Экранирование, для начала, где?
Ахтунг! Пост зла! Все комментящие по делу получают минусы.
По-моему не все, а один angry_elf. К чему бы это?
[xkcd, стандарты]
Не могу понять, почему в этом формате не предусмотрена система прав доступа, если я ничего не пропустил (смотрел спеку очень бегло).
Если кто-то с этим работает, расскажите пожалуйста, как вы решаете проблему управления доступом.
Если кто-то с этим работает, расскажите пожалуйста, как вы решаете проблему управления доступом.
Sign up to leave a comment.
OASIS стандартизует открытый протокол OData