Алексей КНе знаю. Может пока ничего не говорят, но наверняка думают в этом направлении. Ну кроме последнего, который мёртв.
Я о том, что первый вариант более популярен. А OData - специфическая штука, которая нужна далеко не каждому SOA (язык запросов в URL + IQueryable методы). Многие просто не захотят выставлять свои данные, которыми можно крутить как хочешь через IQueryable, особенно это касается публичных нагруженных систем.

SeVaМуслима, все тебе нужно разжевывать до посинения. OData может отдавать чистый AtomPub, json, a web api вообще все, что угодно.Сформировать клиентский запрос можно практически на любой технологии, при этом метаданные можно получить без особого труда, если они нужны, плюс готовая система описания связей. Все это позволяет сделать так не понимаемый тобой обобщенные варианты
Долбосева, все проблемы от твоей неопытности, а не разжевывания. Атом, json и xml могут отдавать все кому не лень, не поверишь, даже WCF REST. Об этом вообще речи не идет. Речь о том, что OData - специфический протокол под конкретную задачу. А в чистом Web API нет схем метаданных, по которым можно кодогенерировать. С обобщенными вариантами можешь сходить в сад, это никому не надо. У OData есть в коробке энтити контроллер, который до дефолту обобщенный. Для не OData никаких обобщений не нужно, потому что контроллер может оперировать несколькими сущностями и DTO.

SeVaНа клиенте proxy - большой чемодан, который тяжело носить. Когда ты дорастешь и у тебя их будет хотя бы несколько десятков, то ты сразу поймешь, что это за геморрой.
Ты пока еще не созрел учить меня тому, в чем абсолютно не разбираешься. На клиенте схема и прокси - это большой огромный плюс в копилку экономии времени и нервов.
Модератор: Если бы не пятница - забанил бы нафиг.
Хватит, ёлки-палки, между собой общаться. Вообще, забудьте о существовании друг друга.

REST APIВ том состоянии, о котором говорите вы oData vs SOAP - действительно, практически идентичны - прав МСУ и ТС - разницы, в принципе, менять шило на мыло никакой нету!!!
OData - нужна для 3% проектов для кросплатформенного управления различными вариантами запросов к удаленному ресурсу. Для всех остальных вариантов нужен честный SOA, который публикует только то, что нужно. Ни шагу влево, ни шагу вправо. Сравнивать на одной чаше весов OData и SOAP глупо, у каждого свое предназначение. Речь о REST vs SOAP. У REST нету схемы, у SOAP есть. Вот и всё отличие.