Estou projetando um aplicativo distribuído que consistirá em serviços RESTful e uma variedade de clientes (Silverlight, iOS, Windows Phone 7, etc). No momento, estou determinando qual tecnologia devo usar para implementar meus serviços, WCF Data Services (OData) ou a nova API ASP.NET Web que está saindo com a ASP.NET MVC 4.
Assisti a algumas apresentações online sobre cada um e agora estou me inclinando para o WCF Data Services principalmente por causa dos mecanismos de filtragem embutidos no URI e na capacidade de hipermídia nativa. A única desvantagem que posso ver é o detalhamento da especificação Atom Pub em oposição ao POX.
Há algo que eu deva saber sobre essas duas tecnologias antes de tomar uma decisão? Por que alguém escolheria ASP.NET Web API em vez de WCF Data Services?
fonte
MediaTypeFormatterpara formatar suas respostas. Consulte code.msdn.microsoft.com/Contact-Manager-Web-API-0e8e373d para obter um exemplo.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 retorneIQueryable<T>. No WCF Data Services, você SÓ obtém acesso para anexar uma declaração "Where" usandoExpression<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 algoAlé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 ???
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 :)
fonte
OData Team Blog
Então, parece que agora tudo está claro o suficiente
fonte
Tanto a API da Web quanto o WCF Data Services oferecem suporte a OData pronto para uso. Com o WCF Data Services (WCFDS), é automático. Com a API Web, retorne
IQueryablede seu controlador e marque o método com[Queryable]. Isso lhe dará a$filterfuncionalidade de que estava falando. E se você fizer isso dessa maneira, ambos podem lidar com JSON na resposta automaticamente, colocandoaccept=application/jsono cabeçalho da solicitação. O OData do WCFDS oferece suporte a mais algumas palavras-chave OData do que a API Web (embora apenas a$expandpalavra - chave venha à mente), mas tenho certeza de que o tempo resolverá isso.Os clientes .NET e as páginas HTML podem acessar essas duas alternativas facilmente, mas se você gosta do LINQ e está criando clientes .NET, o WCFDS pode ser adicionado ao seu projeto como uma referência de serviço. Isso permite que você ignore todos os negócios HTTP e consulte diretamente as coleções.
O resultado final é que não há nada que o impeça de colocar arquivos .svc em seu projeto ASP.Net MVC. Não é uma proposição ou ou. Adicionar serviços de dados ao seu servidor irá evitar a necessidade de escrever muitos controladores, mas não impede que você escreva controladores adicionais se desejar.
fonte
Em outras palavras :
Se você está procurando expor um modelo de dados (EDM ou outro) rapidamente e não precisa de muitos códigos ou lógica de negócios, o WCF Data Services torna isso REALMENTE fácil e seria um bom ponto de partida.
Se você está construindo uma API e simplesmente deseja expor alguns recursos (e lógica) usando a sintaxe de consulta OData ou a formatação, a ASP.NET Web API é provavelmente o melhor lugar para começar.
http://mattmilner.com/Milner/Blog/post/2013/04/02/WCF-Data-Services-and-Web-API-with-OData;-choices-choices.aspx
fonte
Devaron deu a análise mais informativa do WCF vs Web Api que ainda não encontrei. Obrigado. Agora, ao ponto de o WCF ser muito complexo, direi que a complexidade não é automaticamente negativa. Você ficará grato pelo espaço para respirar que isso lhe proporciona no futuro. O desafio, como sempre, com as ferramentas da Microsoft é que não sabemos nem controlamos esse futuro. Vamos torcer para que a Microsoft tenha um sistema mais unificado e que continue por aí por alguns anos.
Também tenho um grande sistema para construir, e isso me deixa claro que o caminho não é mais claro. Eu pretendo adiar por mais alguns meses enquanto tudo isso se resolve. E pessoalmente estou torcendo por datajs (também dê uma olhada no JayData)
fonte
Basta colocar desta forma em termos mais simples, afaste-se do protocolo subjacente e olhe para isso da perspectiva do desenvolvedor / usuário. A API Web é o Rest Framework baseado em HTTP de primeira classe da Microsoft, não o WCF. Isso significa que quaisquer recursos e especificações do Rest que faltam serão adicionados ao pipe da API da Web e não necessariamente ao WCF.
Sim, você mesmo pode implementá-los no WCF, mas, como diz a frase, você mesmo precisa implementá-los.
Apenas como exemplo hoje, a implementação de uma autenticação de 2 fatores para uma API da Web leva menos de 15 minutos usando OWIN, que é um pacote nuget principalmente de autenticação / autorização que começou como um projeto de código aberto.
Quando você usa uma pilha de tecnologia, faz uma grande diferença usar a pilha de primeira classe para a Microsoft. Você ainda teria incontáveis códigos de amostra publicados pela MS e projetos no Github que você pode simplesmente copiar e começar em seu próprio projeto. Faz a diferença em todos os níveis, documentação, amostras de código, conjunto de recursos, suporte, api s auxiliares que você escolher.
Portanto, meu conselho simples para você, se você deseja construir aplicativos baseados em HTTP Restfull, use a API da Web (ou ASP.NET Core para portabilidade) e realmente fique longe do WCF. Se o protocolo não for HTTP e realmente não puder ser HTTP, use o WCF.
fonte
Esta é a resposta TL; DR para esta pergunta.
WCF é o canivete suíço para a chave de fenda da WEB API para comunicação e transferência de dados: WCF pode fazer tudo que a WEB API pode fazer, mas, se você precisar de mais (por exemplo, usando o protocolo TCP), o WCF é o caminho a percorrer.
Aqui está uma ótima comparação .
API WEB
A razão número um para usar a API WEB é que ela é leve. Isso significa que é mais simples de implementar, mais fácil de aprender, mais fácil de manter, etc. Ele é projetado especificamente para a Web, que precisa de serviços da Web RESTful sobre HTTP. Ele faz isso e faz bem. Se isso é tudo de que você precisa, a WEB API é provavelmente o caminho a percorrer.
Além disso, é Open Source (se você se importar)
WCF
WCF faz muito mais do que WEB API: ele oferece suporte a vários protocolos de transferência, vários padrões de troca (WEB API requer integração com SignalR ou Web Sockets), serviços SOAP podem ser descritos em WSDL, tem recursos de segurança adicionais e muito mais. Vá com o WCF se precisar dessa funcionalidade adicional.
OData
OData é simplesmente
Em outras palavras, de alto nível, trata-se apenas de padronizar uma gramática específica para solicitações HTTP RESTful. O que proporcionará os mesmos benefícios de qualquer protocolo. E a partir de pelo menos 2013, o WCF e a WEB API permitem o uso de OData. Portanto, provavelmente não vale a pena se preocupar com OData.
fonte