Last post Mar 06, 2012 06:06 PM by Christian.Weyer
Feb 22, 2012 05:27 AM|neon2|LINK
i wonder in asp.net web api you no longer need a wcf service in place, so is it the end of WCF?
WCF web api was working fine with webGet, WebInvoke, UriTemplate, so why this is shifted to asp.net web api to bring the controller style ?
Now tell if i want to expose my WCF api in a rest full way over http how can i do this? will i use wcf web api style means webGet /Invoke/ UriTemplate ?
Thanks in advance.
Feb 22, 2012 09:28 AM|DarrellNorton|LINK
According to this thread, the WCF Web Api is not going anywhere. However, all future development seems to be on ASP.NET Web Api.
You can continue to use the WCF Web Api to expose a RESTful api.
The benefits of why the change come from this post by Jon Galloway (http://weblogs.asp.net/jgalloway/archive/2012/02/16/asp-net-4-beta-released.aspx):
ASP.NET Web API includes support for the following features:
Feb 22, 2012 05:17 PM|neon2|LINK
Well first of all thanks for ur reply. So wcf web api will be there for use but any further development will be on asp.net web api. So it is now upto the developer how they are going to expose there api , with Wcf using more protocol (http,tcp etc.) or they
just use asp.net web api to go over http only. Now tell me is not it very hard for a developer to maintain both kind of api interface in a app.
We the developer have to maintain both api arch in our app to be consumed by other programme.
for jquery, java script , web client we have to use web api and for client who want to communicate via tcp, msmq we have to code in WCF.
it is not very good as i can see it from here.
Feb 22, 2012 05:43 PM|Darrel Miller|LINK
I'm afraid you are misreading that email from Marcin. On the WCF codeplex site http://wcf.codeplex.com/ it says the content will disappear at the end of 2012.
With the self-host model of ASP.NET Web API you can do pretty much everything you could in WCF Web API.
Feb 22, 2012 07:33 PM|marcind|LINK
That is correct. If you were using WCF Web API (from
http://wcf.codeplex.com) then we suggest you move to ASP.NET Web API (http://asp.net/web-api/). We will be discontinuing WCF Web API by the end of the year.
WCF itself is still around and a supported part of the .NET framework. If you need to write or consume SOAP-based services then that's the right choice. However, if you want to write RESTful or RPCish JSON-based services then ASP.NET Web API is the way to
Feb 23, 2012 04:29 AM|neon2|LINK
Well Thanks for reply, i have a question for you ,
"If you need to write or consume SOAP-based services then that's the right choice. However, if you want to write RESTful or RPCish JSON-based services then ASP.NET Web API is the way to go."
So if it does mean that i have to define two different interface & implementation of my one core service ( like getting all emp from DB), it is realy pain full. Intially WCF was made such a way that i can define one interface of my service & can expose it
with mutiple end point as per my need.
But my actually implementation of serive will remain same in every case. It is just grt from Microsoft. But now u r asking me to define different implementation of my same service ? one from rest (client jQuery, Java Script etc ..) & another for nomal WCF
Please let me know if i am wrong .
Thanks a lot.
Feb 23, 2012 04:45 AM|marcind|LINK
In all honesty I don't know enough about regular WCF to speak authoritatively about what you can or cannot do using
However, I do know that SOAP and RESTful JSON apis are quite different and we found it necessary to create a new framework that enables you to use HTTP as an application protocol (i.e. what HTTP was designed to do) instead of as just as a transport (the
approach employed by SOAP).
To sum up, if you are comfortable with the functionality and implementation you already have you can certainly keep using that. Since WCF is part of the .NET framework it means it will be supported for a long time to come.
Feb 24, 2012 11:20 PM|dr_overflow|LINK
Feb 25, 2012 05:04 PM|satya_tanwar|LINK
I agree here and feel the power of WCF is lost here.. now going forward we will be forced to keep two version of same business service when I want to expose this service for extranet client and intranet client over netTCP and http. This is a very valid scenarios
and one of the foremost reason why WCF services ever existed.
Feb 25, 2012 05:40 PM|Christian.Weyer|LINK
I tended to agree with you and your current opinions. Just to give you some scope: I am one of the original Digerati board members of Indigo (then WCF). Some people say I know WCF inside-out - I have given several dozens of introductions to WCF in seminars,
conference and usergroup sessions world-wide and did numberless consulting gigs in Europe with WCF.
OK, so here goes... :)
There is currently a shift - or rather a new focus - in distributed application architecture. And no, I am not going to call it REST and I am not saying it is the one and only true thing from now on. But we have new drivers like application mashups, mobile
devices and cloud computing which force us to move away from the good old feature-rich (and somehow heavy-weight) SOAP-based approaches. This development and this need is non-discussable and undeniable. One possible solution to these new needs is the use of
light-weight Web APIs (which can be evolved into a REST-ful API or be used 'just' in an RPC-ish way).
So, which technology framework should we as .NET developers choose to build Web APIs? One choice is to leverage WCF's WebHttp model. After working with it for some years I quickly noticed a number of shortcomings (testability/mockability, serializers, ...)
and wished that Redmond would come up with something better. *Of course* it had to be WCF, it had to be part of the overall "let's abstract away communication 'details'". And so it happended that they announced WCF Web API (and I was lucky enough to be part
of the advisory board, again). All was fine in my world.
Fine until I again realized that it has shortcomings when building some more flexible and advanced Web APIs. But this time it was actually the fact that the limitations were in WCF itself. The 'SAOP message' model of WCF just does not fit at all into this
world. Everything the team tried to accomplish and to provide features for a web-based paradigm was just trying to put the round into the rectangle (and vice versa). For a web-based base framework maybe WCF is not the right choice.
And it turned out that there is a very good framework that can deal with the web and HTTP in a fantastic way. So, the decision to build a .NET web API framework on ASP.NET (and ASP.NET MVC, to be more precise) was somehow natural.
I persoanlly had one very strong wish - something I have learned in the past years is invaluable for a lot of our customers... self-hosting! So, the advisors pushed hard to get self-hosting, and here it is: we can perfectly build our own host processes and
host the exact same Web API implementation either there or in IIS/ASP.NET.
Today, I am quite happy with what happened. The only issue I still have is the name: I would definitely have not called it ASP.NET Web API, but rather .NET Web API.
Anyway... coming to your questions regarding architecture:
I would build a WCF service and a ASP.NET Web API (at least with the RPC-ish approach) as a facade only - the actual logic (business logic or data/resource acces) is hidden beyond that facade. With this simple pattern it is no problem to have both WCF SOAP
services and ASP.NET Web APIs sitting right next to each other happily ever after. I am doing it all the time. And you are then actually in the power to levergae the full power of each framework - get the most out of SAOP/XSD/WSDL/WS-* and the best out of
Sorry, this posting somehow evolved into a blog post :)
Feb 25, 2012 05:49 PM|Darrel Miller|LINK
Unfortunately, it was a fallacy that you could create a REST based service and a SOAP based service by having the same service contract and exposing them via different bindings. Architecturally the two approaches are completely different.
You are still free to use wsHttpBinding to take advantage of HTTP on the intranet for RPC style services. However, REST requires a completely different design for both the client and the server.
Having infrastructure that inferred this was possible was doing a huge disservice to the community and it wasn't helping Microsoft's reputation.
WCF has lost absolutely nothing. It is still the primary way that Microsoft based enterprises should use to communicate between their servers in their datacenters.
Feb 27, 2012 04:26 AM|neon2|LINK
Good to see all ur openion in this thread.
Now abt arch of a project , it is true that we put our business logic in core business classes not in the service implementation part.So as we build a WCF soap based api we can also build Web http only based api for our business logic.
But when microsoft introduced WCF the goal was to every thing under one hood. In case of this new Web Api you have to agree that in is not under the hood of WCF any more.
Tell me if i am right or Wrong.
Thanks in advance
Feb 27, 2012 03:23 PM|colmac73|LINK
@Christian.Weyer , your earlier post gives a good insight into the thought process behind the change. The one point I would pick up on is when you say:
For a web-based base framework maybe WCF is not the right choice.
Mar 06, 2012 06:06 PM|Christian.Weyer|LINK
The team is working on improved OData support: http://aspnet.codeplex.com/wikipage?title=ASP.NET%20MVC%204%20RoadMap