Atualmente, existem outras diferenças importantes entre WebApi e WCF Data Services, que ninguém parece mencionar. Gostaria que a MS publicasse um bom artigo comparando os dois.
Eu acompanho o OData há um tempo e também o WebApi. Sempre encontrei algumas diferenças importantes.
Em primeiro lugar, não tenho certeza do que seu chefe quer dizer com "MS está apoiando WebApi", o que significa que eles não estão apoiando OData ?? IMO, eles estão apoiando ambos e atualmente há alguma sobreposição mínima. O Windows Azure Data Market expõe seus dados usando OData, o Azure Table Storage usa OData, o SharePoint 2010 permite consultas OData sobre seus dados e outros produtos da MS também oferecem suporte, como o Excel PowerPivot. É uma estrutura de consulta muito poderosa quando se trata de dados relacionais. E por ser RESTful, qualquer linguagem, estrutura, dispositivo, etc. pode se integrar a ele.
Aqui está o que eu gosto no OData + WCF Data Services:
O OData + WCF Data Services finalmente permitiu que os aplicativos clientes fossem mais "expressivos" ao consultar dados na web. Antes, sempre tínhamos que usar ASMX ou WCF para construir APIs da Web rígidas que se tornam difíceis de manejar e exigem mudanças constantes sempre que uma IU deseja algo ligeiramente diferente. O aplicativo cliente só poderia especificar parâmetros para ditar quais critérios retornar. Ou faça como eu fiz e "serialize" as expressões LINQ e passe-as como os parâmetros e reidrate-as Expressions<Func<T,bool>>no servidor. É decente. Fiz o trabalho, mas quero usar o LINQ no cliente e traduzi-lo na Web usando REST, que é exatamente o que o OData permite e não quero usar meu próprio "hack" de solução.
É como expor "TRANSACT SQL" sem a necessidade de uma string de conexão do banco de dados. Basta fornecer um Url e whoala! Comece a consultar. Obviamente, tanto WebApi quanto WCF Data Services suportam autenticação / autorização, então você pode controlar o acesso, anexar instruções "Where" adicionais com base em funções ou outra configuração de dados. Eu prefiro fazer isso em minha camada de API da Web do que em SQL (como construir visualizações ou Procs armazenados). E agora que os aplicativos podem construir consultas por conta própria, você verá as ferramentas Ad-Hoc e BI Reporting começando a aproveitar o OData e permitir que os usuários definam seus próprios resultados. Não depender de relatórios estáticos onde eles têm controle mínimo.
Ao desenvolver em Silverlight, Windows 8 Metro ou ASP.NET (MVC, WebForms, etc), você pode simplesmente adicionar uma "Referência de Serviço" no Visual Studio ao Serviço de Dados WCF e rapidamente começar a usar LINQ para consultar Dados E você obter um "Contexto de dados" no cliente, o que significa que ele rastreia as alterações e permite que você "envie" suas alterações atomicamente de volta ao servidor. É muito semelhante aos serviços RIA para Silverlight. Eu teria usado WCF Data Services em vez de RIA Services, mas na época não era compatível com DataAnnotations ou Actions, mas agora sim :) WCF Data Services tem outra vantagem sobre RIA Services, que é a capacidade de realizar "projeções" do cliente. Isso pode ajudar no desempenho, caso eu não queira retornar todas as propriedades de uma entidade. Ter um "Contexto de Dados"
Portanto, o WCF Data Services é ótimo se você tiver dados com relacionamentos, especialmente se estiver usando o SQL Server e o Entity Framework. Você poderá rapidamente expor Dados Queryable + Actions (chamadas para invocar operações, ou seja, fluxos de trabalho, processos em segundo plano) sobre REST com muito pouco Código. O WCF Data Services acaba de ser atualizado. Novo lançamento lançado. Confira todas as novas funcionalidades.
A desvantagem do WCF Data Services é o "controle" que você perde sobre a pilha HTTP. Descobri que a maior falha estava nos IQueryable<T>Métodos que retornam Coleções. Ao contrário de RIA Services E WebApi, você NÃO tem acesso total para desenvolver a lógica no Método IQueryable. Em RIA Services e WebApi, você pode escrever qualquer código que desejar, desde que retorne IQueryable<T>. No WCF Data Services, você SÓ obtém acesso para anexar uma declaração "Where" usando Expression<Func<T,bool>>métodos de interceptor. Eu achei isso decepcionante. Nosso aplicativo atual usa RIA Services e acho que realmente precisamos da capacidade de controlar a lógica IQueryable. Espero estar errado nisso e estou apenas perdendo algo
Além disso, o WCF Data Services ainda NÃO oferece suporte total a todos os operadores LINQ. Ele ainda suporta mais do que WebApi.
E quanto ao WebApi ???
- Gosto do controle sobre Solicitação / Resposta Http
- É fácil de seguir (aproveitando os padrões MVC). Tenho certeza que mais ferramentas virão.
A partir de agora (no meu entendimento), não há suporte para "Contexto de dados" no cliente (ou seja, Silverlight, ASP.NET Server-Side Code, etc), porque WebApi não é realmente sobre modelos de dados de entidade como WCF Data Services / OData é. Ele pode expor coleções de objetos de modelo usando IQueryable / IEnumerable, mas não há "Propriedades de navegação" de chave primária / chave estrangeira (ou seja, cliente.Faturas) para usar uma vez que as entidades são carregadas no cliente, porque não há "Contexto de dados" que os carrega de forma assíncrona (ou em uma chamada usando $ expand) e gerencia as alterações. Você não tem nenhuma "representação" gerada por código de seu Modelo de Dados de Entidade no Cliente, como você faz nos Serviços RIA ou nos Serviços de Dados WCF. Não estou dizendo que você não pode / não tem modelos no cliente que representam seus dados, mas você preencheu manualmente os dados e gerenciou quais "faturas" devem ser definidas com cada "cliente" assim que forem recuperadas na web. Isso pode ficar complicado, especialmente com todas as coisas do Async acontecendo. Você não sabe quais ligações voltarão primeiro. Isso pode ser difícil de explicar aqui, mas apenas leia sobre as coisas de "Contexto de dados" em Serviços RIA ouServiços de dados WCF . Portanto, ao lidar com aplicativos de linha de negócios, esse é o principal problema para mim. Isso se baseia principalmente na produtividade e na manutenção. Você pode construir aplicativos obsoletos sem um contexto de dados. Isso simplesmente torna as coisas mais fáceis, especialmente no Silverlight, WPF e agora no Windows 8 Metro. Ter Entidades relacionais carregadas na memória de forma assíncrona e ter Two-Binding é muito bom ter.
Dito isso, isso significa que algum dia o WebApi poderá oferecer suporte a um "Contexto de dados" no cliente? Eu acho que sim. Além disso, com mais ferramentas, um projeto do Visual Studio pode gerar todos os seus métodos CRUD com base em um esquema de banco de dados (ou Entity Framework).
Além disso, sei que estou mencionando apenas .NET para .NET Frameworks quando se trata de trabalhar com WCF Data Services ou WebApi, mas estou ciente de que HTML / JS também é um jogador importante. Eu estava apenas mencionando os benefícios que descobri ao lidar com uma IU do Silverlight ou código do lado do servidor ASP.NET, etc. Acredito que com o advento de "IndexedDB" em HTML5 / JavaScript, ter um "Contexto de dados" e um A estrutura LINQ em JavaScript também pode se tornar disponível, tornando a capacidade de consultar o OData Services ainda mais fácil a partir do JavaScript (você pode usar DataJS hoje com OData). Além disso, usar KnockoutJS para suportar MVVM e Binding em HTML / JS também tornará tudo mais fácil :)
Atualmente, estou pesquisando qual plataforma usar. Eu ficaria feliz em usar qualquer um, mas tendo a me inclinar para o OData com base no fato de que meu próximo aplicativo é principalmente sobre Analytics (somente leitura) e eu quero uma API RESTful expressiva e rica. Acredito que OData + WCF Data Services me dê isso porque WebApi só suporta $ take, $ skip, $ filter, $ orderby em coleções. NÃO suporta projeções, inclusões ($ expand), etc. Não tenho muitas "atualizações / exclusões / inserções" e nossos dados são bastante relacionais.
Espero que outros participem da discussão e dêem suas opiniões. Ainda estou decidindo e adoraria ouvir outras opiniões. Eu realmente acho que os dois frameworks são ótimos. Gostaria de saber se você ainda tem que escolher, por que não usar os dois se necessário. Do cliente, trata-se de criar chamadas REST de qualquer maneira. Apenas um pensamento :)