Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Mar 06, 2012 06:06 PM by Christian.Weyer
Feb 25, 2012 05:49 PM|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|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|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|LINK
The team is working on improved OData support: http://aspnet.codeplex.com/wikipage?title=ASP.NET%20MVC%204%20RoadMap