fbpx
WebAPI não é bala de prata
Publicado em: domingo, 3 de maio de 2015

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.

Choosing which technology to use

The following table describes the major features of each technology.

WCF

ASP.NET Web API

Enables building services that support multiple transport protocols (HTTP, TCP, UDP, and custom transports) and allows switching between them. HTTP only. First-class programming model for HTTP. More suitable for access from various browsers, mobile devices etc enabling wide reach.
Enables building services that support multiple encodings (Text, MTOM, and Binary) of the same message type and allows switching between them. Enables building Web APIs that support wide variety of media types including XML, JSON etc.
Supports building services with WS-* standards like Reliable Messaging, Transactions, Message Security. Uses basic protocol and formats such as HTTP, WebSockets, SSL, JSON, and XML. There is no support for higher level protocols such as Reliable Messaging or Transactions.
Supports Request-Reply, One Way, and Duplex message exchange patterns. HTTP is request/response but additional patterns can be supported through SignalR and WebSockets integration.
WCF SOAP services can be described in WSDL allowing automated tools to generate client proxies even for services with complex schemas. There is a variety of ways to describe a Web API ranging from auto-generated HTML help page describing snippets to structured metadata for OData integrated APIs.
Ships with the .NET framework. Ships with .NET framework but is open-source and is also available out-of-band as independent download.

Use WCF to create reliable, secure services that accessible over a variety of transports. Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients. Use ASP.NET Web API if you are creating and designing new REST-style services. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API. If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.

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

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

[docker de a a z]

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.