МСУEDUARD SAPOTSKIСлушай, давай не будем про ставки мелкософта, а то возникает желание на яву сбежать
Ну если шарики на одате, одинэсы и прочая херотва, то надо уже начинать вилять задом чё



А не похоже, что OData движется по тому же пути, что и SOAP в своё время?
Спецификацию OData v2 можно за час прочитать. А спецификация OData v4 вполне уже тянет на рекомендации W3C :)

Скоро получится такой же огромный неповоротливый монстр, как и SOAP-службы. Тогда в чем профит, реально?

Про удобство реализации в .NET - не аргумент. Если сервис востребованный, использовать его отовсюду будут - из Java, PHP, из Delphi, чего доброго... :)
Естественно, я сейчас про публичные API говорю, не про внутренности сайтов.

МСУДиезА не похоже, что OData движется по тому же пути, что и SOAP в своё время?
Нет. Тут гораздо больше общего с ria services.

Я не про общие концепции, а про геометрический рост сложности протокола в процессе развития.
МСУДиезСпецификацию OData v2 можно за час прочитать. А спецификация OData v4 вполне уже тянет на рекомендации W3C :)
Ты имел ввиду OData v3 на нативном атоме? Да, вещь, причем поддерживается всякими экселями и прочим. v4 уже другая песня, добавили функции и прочие вкусности. Речь о v4, разумеется.


http://www.odata.org/documentation/odata-version-2-0/
http://www.odata.org/documentation/odata-version-4-0/

Объемы документации, мягко говоря, различаются :)

SOAP тоже начинался с примитивного XML-RPC. А потом его начали расширять, стандартизировать, опять расширять, опять стандартизировать.
Теперь мы вместо Simple Object Access Protocol имеем набор WS-*, в которых сам черт ногу сломит. :)

МСУДиезСкоро получится такой же огромный неповоротливый монстр, как и SOAP-службы.
Это будет скрыто от прикладного разработчика.

ДиезТогда в чем профит, реально?
Профит в том, что кодогенерированный контекст на клиенте так же трачится, как EF контекст и RIA. Работаешь с контекстом и с доменными объектами, а оно само всё транслируется в REST запросы. SOAP'у такого и не снилось.


Точно так же реализация скрыта и для SOAP. Никто в здравом уме не будет формировать XML для Envelope или Fault. Для разработчика виден лишь набор классов и методов.

МСУДиезПро удобство реализации в .NET - не аргумент.
Еще какой аргумент.

ДиезЕсли сервис востребованный, использовать его отовсюду будут - из Java, PHP, из Delphi, чего доброго... :)
Сделают темплейты, кодогенераторы. И поплывёт. Не проблема.

ДиезЕстественно, я сейчас про публичные API говорю, не про внутренности сайтов.
Публичные API вообще должны быть 100% REST. Априори.

ОК, назовем их не публичными, а используемыми внешними системами, в противоположность внутреннему АПИ сайта, которое лишь для AJAX-запросов. Даже если всё в рамках интранета.

МСУ Web services are dead -- long live REST
SOAP is officially dead, long live REST
How REST replaced SOAP on the Web: What it means to you
On the death of SOAP
SOAP is Not Dead - It's Undead, a Zombie in the Enterprise
REST in peace, SOAP
SOAP is Comatose But Not Officially Dead! (February 19, 2005!!!)
SOAP is dead, REST is coming

Вот скажите, зачем вы публикуете ссылки, которые не читали? По крайней мере, последнюю, на тайском языке
МСУДрузья, какой в задницу SOAP?





Насчет диаграмм - 15% - это не так уж и мало для мертвой с 2005 года технологии, не правда ли?

(Кстати, в энтерпрайзе вовсю CORBA поддерживается до сих пор. Вот уж где окаменелости )

Но речь-то не о том, что SOAP лучше OData. А о том, что стандартизация превращает любую удобную технологию в неудобную, хотя и общеиспользуемую.

Программисты, имхо, за то и любят REST, что он прост как табуретка, и не навязывает конкретную реализацию. Придумал удобный для себя протокол - и пользуй на здоровье. А тут опять "прокрустово ложе" навязывают...