O tema

Pessoal, faz alguns dias que assisti um debate interessante e muito produtivo com o tema “Serviços na plataforma .NET: WCF ou WebAPI?”. Quem conduziu o debate foi a galera do AspNetCast‬, com a presença do Evilásaro Alves. Bom, não vou debater a respeito do cast que está aqui, minha intenção é debater sobre o assunto.

Deja-Vú

O ponto mais engraçado é que para uma grande parte da galera nova, e já trabalhei com um pessoal que pensa isso, WCF é algo totalmente desnecessário e irrelevante, em contrapartida WebAPI é a solução mais eficiente e eficaz para integrações e exposição de serviços.  Na cabeça deles, WCF é quase um elefante branco, desnecessário, over design, simplesmente too much. Eles traziam consigo o hype de que o WCF era tão grotesco e pré-histórico quando cobol.

RPC antes do WCF

Antes de falarmos de WCF, precisamos falar do mundo pré-wcf. Se voltarmos 10 anos no tempo, vamos ver uma infinidade de aplicações .Net tentando trabalhar com processamento distribuído usando Web Services. O nosso bom e velho (nem tão bom, mas velho) ASMX, sob o ASP.NET, o mesmo do Web Forms. Quem entrasse no mercado nessa época, precisaria conhecer essa tecnologia. Mas ela nunca foi a única. Tínhamos o .Net Remoting, exclusivo da plataforma .Net e o Enterprise Services, um irmão do antigo COM+. Ainda tínhamos MSMQ, muito menos usado que os demais.

A vida sem WCF

A princípio, pode parecer algo trivial, já que convivemos com o WCF há 10 anos, mas se falarmos dessas tecnologias, de forma isolada, vamos ver que temos estilos e artefatos que precisam seguir regras de construção bem específicas para cada um destes cenários. Um WebService não pode ser publicado como .Net Remoting, assim como um Enterprise Service, não pode ser publicado como nenhuma outra coisa.

O Spring.Net Spring.Services

Por volta de 2005, 2006, o framework de aplicação Spring, do Java, recebe seu primeiro port para .Net. Desde já, o Spring.Net lançava-se com o Spring.Services, um pacote opcional do Spring.Net destinado à infraestrutura de serviços. Com o Spring.Services, tínhamos uma estratégia muito interessante para exposição de componentes e serviços remotos. A filosofia era bem simples: Construa uma única vez e publique como quiser. Simplificando: Pense em um WCF básico, mas sem a necessidade dos atributos (ServiceContract, OperationContract, DataContract, DataMember).

Com base em uma implementação de um serviço, e um contrato fortemente tipado, o Spring.Net cuidava de tudo para você. Como ele já era um Container IoC/DI, e já implementava Proxy e AOP, não era complexo para ele permitir que uma dependência tivesse embarcada no mesmo domínio de aplicação ou remota. Ele criava e gerenciava automaticamente do Host e do Proxy (client) para esse serviço. Essa abstração era fantástica, pela possibilidade de pegar uma dependência direta, previamente codificada, e hospedá-la em outra máquina sem que houvesse necessidade de recodificar sequer uma linha. Tudo era feito via configuração.

Nessa época, tínhamos do lado da Microsoft as primeiras versões do Enterprise Library, com o ObjectBuilder e ServiceLocator e Unity. E a primeira geração de gambiarras que naquela época apenas a Microsoft, mas hoje toda a comunidade .Net tenta chamar de IoC/DI.

A chegada do WCF

No final de 2006, chega à plataforma Microsoft o WCF, que na minha opinião foi motivado ou apenas acelerado, pela chegada do Spring Services à plataforma .Net. No WCF temos a mesma feature: Codifique uma vez, publique como quiser. Mas sob esse framework de comunicação vemos algo muito mais robusto, e contamos hoje com uma infinidade de recursos bem interessantes, como (detalhes):

• Workflow Services
• Endpoints: Addresses, Bindings, Behaviors
• Data Transfer and Serialization
• Sessions, Instancing, and Concurrency
• Transport layer
• Queues and Reliable Sessions
• Transactions [from BPUEDev11]
• Security
• Peer-to-Peer Networking
• Metadata
• Hosting
• Interoperability and Integration
• WCF Web HTTP Programming Model
• WCF Syndication
• AJAX Integration and JSON Support
• WCF Discovery
• Routing

Na prática, qual a vantagem de se usar WCF sob WebAPI?

A resposta é bem simples:

1. Codifique apenas uma única vez, e escolha a forma de publicar e compor seu parque o mais tarde possível.
2. Permite abandonar Service References e Web References e e partir para a publicação de assemblies de contrato
3. Extensível e Configurável

Mas para que o WebAPI?

O WCF é muito bom, muito eficiente, e eficaz, mas foi desenhado sob a ótica SOA e pensado para serviços e esse não é 100% do todo. Há demandas de serviços que atendem às UI’s, dispositivos móveis, SPA’s e as demais plataformas vêm prezando pela simplicidade no desenvolvimento desses serviços. Para estes http é obrigatório. Mas é possível usar WebAPI para integração entre aplicações e serviços. Sim, é possível, mas dificilmente será a melhor alternativa para este cenário.

Abaixo temos um o link para o comparativo WCF and ASP.NET Web API:

WCF is Microsoft’s unified programming model for building service-oriented applications. It enables developers to build secure, reliable, transacted solutions that integrate across platforms and interoperate with existing investments. ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework. This topic presents some guidance to help you decide which technology will best meet your needs.

Conclusão

Wcf ou WebAPI? Ambos! Os requisitos que endereçam a criação de uma WebAPI são diferente daqueles que demandam a criação de um WCF. Quem precisa de WebAPI pode não precisar de WCF e vice-versa. Um não suplanta o outro, eles simplesmente coexistem e haverá cenários em que você terá um WebAPI consumindo um WCF, isso não é um problema.

A única coisa que me preocupa, é que no #build2015 não falaram em WCF no Linux e Mac, isso sugere que o WebAPI surge como única alternativa para essas plataformas, por enquanto.

Excelente Leitura:

WCF or ASP.NET Web APIs? My two cents on the subject