Чем плох протокол OData для использования в бизнес приложениях

Хотел бы поделиться своим мнением на счет протокола OData и использования его в HTML5 бизнес приложениях.
Многим известен этот протокол, и Microsoft активно его продвигает, используя в своих разработках. Например, она изменила протокол обмена данных в WCF RIA Services на OData (теперь это WCF Data Services), она разрабатывает новый клиент — HTML5 LightSwitch client, и многие новые HTML5 библиотеки типа JayData и Breeze используют его как протокол обмена данных. Это REST протокол, который кажется удобен тем, что все параметры запроса передаются по методу GET — в строке запроса. Однако, для разработки бизнес приложений есть существенные минусы от его использования.

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

Второй минус, это то, что спецификация по этому протоколу постоянно изменяется от версии к версии. Сейчас используется вторая версия, а третья уже на подходе. Так кому нужны и ради чего, эти постоянные апдейты? Для бизнес приложений это мало приемлемо.

Третий, наиболее существенный минус для бизнес приложений — это безопасность. Это не видно с первого взгляда, но проблема все таки есть. Это, expand в строке запроса. В запросе вы можете указать включить связанные сущности. Вопрос только, кто проверяет, что вы не включите данные не предусмотренные для вашего просмотра. Обычно, сервисы данных работают в доверенном (Trusted) режиме, т.е. им позволено считывать всё из банных, а сервис данных сам проверяет имеет ли клиент доступ к каким то данным. Поэтому метод сервиса отработает в штатном режиме и вернет вам связанные сущности. Это могут быть конфиденциальные данные, не разрешенные для просмотра для лиц с определёнными ролями доступа к данным.

Ещё, одна проблема, как сделать так, чтобы expand не создавал не оптимальные запросы. Дело в том, что на поверхности включение связанных сущностей выглядит просто. Однако, запрос идущий непосредственно на сервер БД сильно усложняется, и может тормозиться в разы, приводя многие апдейты данных от других пользователей к блокировкам.

Теперь решение:
Не использовать без надобности этот протокол. (Хотя, если надобность вообще?)

В моем фреймворке, jRIApp, я все же сделал доступной эту функцию, возвращать связанные сущности. Однако, это контролируется на сервере, в методе который возвращает данные запроса. Включаются только те сущности, которые разрешил включать разработчик приложения!

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

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

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