WCF vs ASP .Net Web API

wcf asp.net-mvc-4 asp.net-web-api

What are the pros and cons of using each technology?

WCF Web Api is now merged into Asp.net Asp.net web api now supports self hosting.

I still imagine if I want to expose multiple protocol schemas for the same operation I would still lean towards WCF or can Mvc end point do this too?

Also does the new Asp.Net web api expose Wsdl? If not how would the client figure out what operation is available to them?

Arguably the best feature of Mvc is the modelbinder. How robust is the WCF equivalent?

So can someone tell me what advantage does the Asp.net web api bring to the table? WCF seems overwhelmingly the more powerful/scalable choice, imo. About the only thing the Mvc Web Api has over the WCF model is probably ease of development, but that means squat if it ends up being a serious design limitation down the road.

I find the title of this question a bit misleading. The title is "MVC 4 vs Wcf Web Api", but the question seems to deal more with WCF vs ASP .Net Web API. From the title I thought that what was being compared was standard MVC 4 framework (Controllers, Models, Views) vs ASP .Net Web API framework. Anyone else find this title misleading?

IdoFlatow

First, I suggest you read my post on the subject: http://blogs.microsoft.co.il/blogs/idof/archive/2012/03/05/wcf-or-asp-net-web-apis-my-two-cents-on-the-subject.aspx

Regarding your WSDL question - since the WebApi does not use SOAP, it does not require a WSDL, and does not export one. You can use Hypermedia to return resources with a list of possible activity URLs (think of it as a self-describing resource)

That's a very very good write up. The best one I have ever seen. But I'm now more confused than ever. WebApi adds so much, but the inability to expose other endpoint seems very restrictive. If you had a client that can use soap, they'll now be forced to build the action and parse the result by hand when soap could have generated the entire context for them. You'll also lock them out of the more advanced Soap feature such as reliable session and Acid transaction... sigh.

@Alwyn - I think that all the facts you mentioned are true and therefore shouldn't confuse you but rather help you make a decision - Web API has its own advantages, but If your service needs to be exposed from multiple endpoints including other protocols, or you have a strong need for the client auto generating feature or soap advanced features - these might be consideration why to prefer WCF over Web API

@BornToCode: Client code can be auto-generated with WebAPI. You can produce a swagger json file using the WebAPI code. That json file can then be used by a code generator such as swagger-codegen to produce client code in a large number of target languages.

@unintentionallyleftblank - IMHO It's still more "user friendly" to auto generate client code via WCF than Web API.

Junior Mayhé

The choice depends on what we want to do.

ASP.NET Web API is a framework for building non-SOAP based services over HTTP only - so there aren't more transport protocols available using this framework. WCF / Windows Communication Foundation is a framework for exchanging SOAP-based messages - here we use a lot of transport protocols: HTTP, TCP, Named pipes, MSMQ, etc...

I am not sure about which one has better performance regarding the amount of data, maybe WCF since we can use low protocols. Any comments are appreciated.

No offense but HTTP is just an application-layer protocol. It has no inherent restriction on what transport-layer protocols can be used.

Gregory A Beamer

The WCF Web API primarily focuses on REST implementations. If you are setting up a REST implementation, the standard WCF bits are a bit of a pain in the rear. If you are setting up RESTful services, you will find the WCF Web API a much nicer experience. If you are setting up SOAP services, then the WCF Web API is not your best friend, and you are better off using WCF for your services.

Yes the configs are a pain, but it's a one time set up cost. Once you've done it, you can pretty much copy and paste the behavior/endpoint to another service. Most of the time you get by just tagging the new operations with WebGet. On the other hand if you ever get a client that wants to use Soap + Wsdl, it's all just a config change as opposed to code + deploy + QA + the rest. So how is Mvc Web Api any better?

If you are already comfortable with WCF, you can continue down that path. There are, in addition to what I mentioned, some internal improvements on REST in the WCF Web API (I don't have the list in front of me), but either can work and I would not spend weeks refactoring if you have tons of working services, esp. since there is a bit of a paradigm shift in thinking. For future work, I would consider the WCF Web API, however. But I have been with WCF Web API for quite some time, so I may be biased.

A_Var

Use WCF for intranet/B2B sites n Web API for B2C/C2C/internet sites...SOAP/XML is still the standard for intra-businesses communication n it's not going to go away!!!

WCF vs ASP .Net Web API

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US