WCF vs WEb api vs Web services for new ecommerce website [duplicate]

Question

I am creating a new ecommerce application in MVC and sql server as database.I want to use Entity framework for the same. I am confused in selection of my data access layer. Which one should I use among WCF vs Web api vs Web services. It may be possible that in future we may required android and IOS app. I think Web api will be the best option for this.

I try to find the difference between web api and WCF, what did i found is that. The new ASP.NET Web API is a continuation of the previous WCF Web API project (although some of the concepts have changed).

WCF was originally created to enable SOAP-based services. For simpler RESTful or RPCish services (think clients like jQuery) ASP.NET Web API should be good choice. There are thousand of links telling about Rest, TCP, FTP, soap, Http. But no where I found my answer. I am still confused Which one will fulfill my problem. One more thing if I choose Web api, can entity framework integrate with Web api. I am new to dot net. any help will be very helpful.

Edit: @win thanks for your help. I want to know, How to decide which one should i choose, RESTFull(Web api) or WCF(Soap). Which factors in application decide, which one to use.

Answer 1

WCF provides a lot of functionality, but at the cost of crazy-mad configuration setup. Crazy mad. It involves defining an "ABC", Address, Binding, Contract. I always tell people "with WCF: its the configuration, not the code". There are just ~so many options for configuring it.

If you need to push/pull small amounts of data to "clients" (browser, android, iphone), then WebApi is the best bet.

One feature, WebApi will give you xml OR json via how the request is setup (in the 'header').

With WCF, you have to "code up" either/or/both for json and xml and it isn't super trivial. Aka, you have to put attributes on the Service-Methods (the "Contract" of the ABC) to say "this method will send back xml" or "this method will send back json".

Your WebApi layer will provide services. This usually means providing json data or consuming json data. And MS has taken care of the "plumbing" for you, so on the services side, this happens auto-magically.

I've coded both since 2005 (well, WCF in 2005 and following, and then later with WebApi).

WebApi is much easier to deal with, especially for a beginner.

So unless you have a very concrete reason to use WCF, I would use WebApi.

As far as an ORM, that happens completely on the "server side", so you can pick whichever one you want. I would pick Poco/Code-First/Entity-Framework OR NHibernate (for "full" ORM's) or Dapper (for a micro ORM). Which ORM to use is a full discussion in itself. But quick advice, don't choose one willy-nilly, do a little research. Search things like "Entity-Framework vs NHiberate" or "Entity-Framework vs ADO.NET" or "Dapper vs NHiberate" (you get the drill, any combination, and sometimes you'll find a comparison that does all three plus others.

Here is a little explanation of the auto-magic wire up...where you are not hand-parsing json on the SERVER side.

http://encosia.com/using-jquery-to-post-frombody-parameters-to-web-api/

and here

http://encosia.com/rest-vs-rpc-in-asp-net-web-api-who-cares-it-does-both/

Outside of my opinions here, here is a Microsoft comparison article :

https://msdn.microsoft.com/en-us/library/jj823172.aspx

and the quote:

Use WCF to create reliable, secure web 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.