Я изучаю использование OData для наших веб-сервисов Java RESTful. У меня есть длинный список преимуществ использования OData, которые составляют хороший аргумент для его использования. Однако, прочитав много статей об OData, я не видел ни одного списка недостатков, чтобы принять окончательное решение.
Кто-нибудь знает о недостатках использования OData (odata4j в этом случае)?
Спасибо
Sarah
Некоторые запросы просто не могут быть выполнены, и вы в конечном итоге создаете представления - например, см. этот пост: Операции службы WCF для возврата графа объектов. Это связано с тем, что вы не можете фильтровать расширенные записи, например. скажем, у вас есть люди с заказами, и вы хотите, чтобы все люди и их заказы на торты; если вы начинаете свой запрос OData с людей и расширяете заказы, вы можете получить всех людей, которые заказали торты, но вы также получите все свои заказы, а не только те, которые торчат. В большинстве случаев это не проблема, так как вы можете повернуть запрос на голову, то есть начать с заказов и расширить людей. Иногда это невозможно сделать, и вам нужно создать представление.
Нет эквивалента SQL In, вы должны сделать это долгий путь с помощью группы ors.
Агрегаты, вам либо нужно сделать дополнительный вызов операции OData, либо сделать их клиентской стороной, что не очень полезно, если вы хотите распечатать данные и показать агрегаты.
Попытайтесь придерживаться JSON, ATOM чрезмерно раздувается с фактическими данными, занимающими небольшой кусок пакета \
В зависимости от вашего сервиса - непонятные и бесполезные сообщения об ошибках, которые вы просматриваете через сообщения обновления OData, пытаясь точно определить, что вызвало ошибку.
Если я смогу больше думать, я вернусь и добавлю их.
Прошло много времени с момента вашего первоначального поста, возможно, вы сами обнаружили некоторые другие недостатки?
По моему мнению, недостаток OData (перед публичным доступом в Интернет) заключается в параметрах запроса, которые клиент может добавить к URL-адресу для фильтрации того, что показывает канал. OData позволяет клиенту по существу выполнять вызов/логику базы данных, чтобы вернуть фид "настраиваемый" для них.
Это связывает клиента с фидом, и им нужно заранее знать, что они могут использовать и фильтровать (что, я думаю, противоречит концепции обнаружения REST). Кроме того, это означает, что они используют его таким образом, что вы не можете видеть/контролировать значение, что их клиентское приложение может быть очень тесно связано с вашим фидом и подключенным к нему вызовом/логикой базы данных (существует множество доступных методов для клиента для использования с URL-адресом).
В контролируемой среде или только с несколькими потребителями это может быть выгодным для Odata, поскольку это легко и эффективно для конечного пользователя.
Но, на мой взгляд, если публиковать это публично, это может дать вам головные боли, когда вам нужно изменить фид или обновить, поскольку вы должны убедиться, что не нарушаете никаких "неизвестных" реализаций. Если функции доступны, люди будут их использовать.,
В настоящий момент эта функция не может быть отключена, но доступна по умолчанию.
Один из недостатков заключается в том, что вы не можете писать собственный, проприетарный, громоздкий API и документацию, прилагаемую к нему, чтобы потребители знали, как писать запросы к вашей службе.
Нет, подождите - это не совсем невыгодное положение, так что, я думаю, я не могу сейчас думать ни о чем. < grin/" >
Чтобы расширить этот ответ и сравнить его с SOAP:
SOAP также является полностью приемлемой методологией и является опубликованным стандарт. Однако, поскольку REST обеспечивает легкий доступ без атак используя HTTP-глаголы, а OData - это просто набор URI-соглашений для доступ к разрозненным службам REST с помощью общей методологии и поскольку оригинальный плакат описывал веб-службы Java RESTful, я дал мой щекотливый ответ выше в контексте REST и OData. Также: WSDL не требуется для OData, поскольку спецификация общего для всех служб OData и самой службы (при соблюдении со спецификацией) описывает предложения данных.
[Из моего комментария к этому ответу.]
Как и в случае V2, единственным недостатком, который я вижу, является отсутствие возможностей запросов по отношению к отношениям "один ко многим" во многих концах. Поэтому, если авторы и статьи в вашей модели, вы можете запрашивать статьи с атрибутами автора в запросе, но не наоборот: вы не можете запрашивать авторов с определенными статьями.
В OData V2 Any все операторы также не поддерживаются, но это исправлено в V3 (на основе предварительных, но закрытых спецификаций)
В частности, для OData и Java4Odata были некоторые проблемы совместимости, которые я считаю. Мы разоблачаем OData и имеем другую команду, потребляющую ее с Java. Они не были полностью счастливы и, по-видимому, много обсудили список рассылки.
Кроме того, OData, похоже, не так популярна, как ожидалось Microsoft (обещано). Таким образом, преимущества, которые есть, действительно присутствуют, если есть потребители, способные соответствовать производителям. Например, OData дает навигационные и пользовательские парадигмы данных, но если они не используются, что осталось?
И без реальных полных потребителей и производителей на нескольких языках OData так же хорош, как и любой другой проприетарный протокол.
Рассматривая преимущества и недостатки, можно рассматривать вещи абстрактно или со ссылкой на конкретный проект или сценарий.
Говоря абстрактно на мгновение, нужно задуматься над значением "стандартов". Стандарты - это доллары, правительства и границы... они существуют только до такой степени, что люди считают, что они существуют. В противном случае деньги - это просто бумага (или в цифровую эпоху, цифры). Так возникает вопрос, насколько широко это будет принято? Это то, что я пришел сюда, чтобы узнать, хотя мое предварительное расследование предполагает, что не будет появляться какая-либо технология, которая вездесуща. Люди принимают множество новых технологий в большом количестве.
Тогда, в частности, вы можете сравнить с такими альтернативами, как MongoDB (что, я считаю, очень похожее), с особой ссылкой на вашу организацию, которая ощущала потребности. Опять же, это то, что я пришел сюда, чтобы узнать.
Моя мысль заключается в том, что важная тенденция заключается в том, чтобы отправить что-то по проводу, который уже был отображен в HTML, и вместо этого отправил данные как некоторый вариант JSON и предоставил Javascript, который будет использоваться браузером для его отображения. Когда появятся драйверы для различных вариантов JSON, будет тривиально изменяться между тем или другим. Здесь один выходит для oData:
http://www.rssbus.com/ado/odata/
Это, я понимаю, позволит вам притвориться, что вы имеете дело с Sql Server. Я думаю, мы увидим больше этой абстракции JSON-подобного слоя, позволяющего увеличить свободу от "стандартов". Но опять же, что я здесь, чтобы узнать.
Я не знаю о ODataJ4. Я знаю, что существует ряд ресурсов в http://www.odata.org/, включая список производителей и потребителей одаты, а также список языков, известных поддержите его. OData имеет свои ограничения в областях и зависит от используемой вами версии протокола. OData по-прежнему разрабатывается во многих реализациях, чтобы полностью поддерживать версии. Поэтому, если вы после дополнительного материала, который вы получаете в v3 протокола, я думаю, вы обнаружите, что ряд реализаций пока не совсем там.
Помимо некоторой нехватки функциональности в провайдерах, единственное, о чем я могу думать, - это отсутствие гибкости (если это недостаток). Обычно в OData есть один способ сделать что-то.
Я хотел бы также отметить, что odata выпущен под Microsoft Open Specification Promise, и нет намерения взимать плату за использование протокола.
Я надеюсь, что это поможет