WCF web api is lost ?

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.

Re: WCF web api is lost ?

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:

Modern HTTP programming model: Directly access and manipulate HTTP requests and responses in your Web APIs using a new, strongly typed HTTP object model. The same programming model and HTTP pipeline is symmetrically available on the client through the new HttpClient type.
Full support for routes: Web APIs now support the full set of route capabilities that have always been a part of the Web stack, including route parameters and constraints. Additionally, mapping to actions has full support for conventions, so you no longer need to apply attributes such as [HttpPost] to your classes and methods.
Content negotiation: The client and server can work together to determine the right format for data being returned from an API. We provide default support for XML, JSON, and Form URL-encoded formats, and you can extend this support by adding your own formatters, or even replace the default content negotiation strategy.
Model binding and validation: Model binders provide an easy way to extract data from various parts of an HTTP request and convert those message parts into .NET objects which can be used by the Web API actions.
Filters: Web APIs now supports filters, including well-known filters such as the [Authorize] attribute. You can author and plug in your own filters for actions, authorization and exception handling.
Query composition: By simply returning IQueryable<T>, your Web API will support querying via the OData URL conventions.
Improved testability of HTTP details: Rather than setting HTTP details in static context objects, Web API actions can now work with instances of HttpRequestMessage and HttpResponseMessage. Generic versions of these objects also exist to let you work with your custom types in addition to the HTTP types.
Improved Inversion of Control (IoC) via DependencyResolver: Web API now uses the service locator pattern implemented by MVCs dependency resolver to obtain instances for many different facilities.
Code-based configuration: Web API configuration is accomplished solely through code, leaving your config files clean.
Self-host: Web APIs can be hosted in your own process in addition to IIS while still using the full power of routes and other features of Web API.

Re: WCF web api is lost ?

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.

pls reply.

Re: WCF web api is lost ?

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.

Re: WCF web api is lost ?

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 go.

Re: WCF web api is lost ?

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.

Debdeep

Re: WCF web api is lost ?

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.

Re: WCF web api is lost ?

While I can see the attraction in making the 'REST services' programming model similar to MVC, I think it was the completely wrong way to do it. Wcf, which was designed as an abstraction over 'communication' as a whole, has the majority of parts nessecary for a good REST programming model. I need to expose my services as both soap and rest. Wcf webapi could do this, asp.net web API is far enough removed from wcf that I'm not sure if it will be possible. Wcf needs its message object to be decoupled from XML and to expose the raw packet. Other than that, the actionfilter/operationhandler concept is better than messagefilters in wcf.

Re: WCF web api is lost ?

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.

Re: WCF web api is lost ?

@dr_overflow, satya_tanwar:

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 web APIs/REST/whatever.

Sorry, this posting somehow evolved into a blog post :)

Cheers.

Re: WCF web api is lost ?

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.

Re: WCF web api is lost ?

@ALL

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

Re: WCF web api is lost ?

@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:

Christian.Weyer
For a web-based base framework maybe WCF is not the right choice.

I can see the sense of this argument here, but it seems like still having the WCF Data Services API as an ongoing concern is contradictory to this. Should ASP.NET Web API not expand it's OData support so that we are left with a single framework to expose web API's?

Re: WCF web api is lost ?

The team is working on improved OData support: http://aspnet.codeplex.com/wikipage?title=ASP.NET%20MVC%204%20RoadMap