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 ?
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 MVC’s 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.
Darrell Norton, MVP
Darrell Norton's Blog Please click "Mark as Answer" if this helped you.
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.
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.
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.
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
?
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.
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.
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.
Satya
------------------------------
Mark as answer if you think
this helped you
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.
-Christian Weyer
Microsoft MVP for Windows Azure [Architecture]
http://weblogs.thinktecture.com/cweyer
neon2
Member
44 Points
48 Posts
WCF web api is lost ?
Feb 22, 2012 05:27 AM|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.
DarrellNorto...
All-Star
86645 Points
9629 Posts
Moderator
MVP
Re: WCF web api is lost ?
Feb 22, 2012 09:28 AM|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:
Darrell Norton's Blog
Please click "Mark as Answer" if this helped you.
neon2
Member
44 Points
48 Posts
Re: WCF web api is lost ?
Feb 22, 2012 05:17 PM|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.
pls reply.
Darrel Mille...
Member
162 Points
54 Posts
Re: WCF web api is lost ?
Feb 22, 2012 05:43 PM|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.
marcind
Contributor
3344 Points
609 Posts
Microsoft
Re: WCF web api is lost ?
Feb 22, 2012 07:33 PM|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 go.
ASP.NET Team
@marcind
Blog
neon2
Member
44 Points
48 Posts
Re: WCF web api is lost ?
Feb 23, 2012 04:29 AM|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.
Debdeep
marcind
Contributor
3344 Points
609 Posts
Microsoft
Re: WCF web api is lost ?
Feb 23, 2012 04:45 AM|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.
ASP.NET Team
@marcind
Blog
dr_overflow
Member
2 Points
1 Post
Re: WCF web api is lost ?
Feb 24, 2012 11:20 PM|LINK
satya_tanwar
Contributor
2859 Points
496 Posts
Re: WCF web api is lost ?
Feb 25, 2012 05:04 PM|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.
------------------------------
Mark as answer if you think
this helped you
Christian.We...
Member
32 Points
11 Posts
Re: WCF web api is lost ?
Feb 25, 2012 05:40 PM|LINK
@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.
Microsoft MVP for Windows Azure [Architecture]
http://weblogs.thinktecture.com/cweyer
https://github.com/thinktecture/Thinktecture.Web.Http