WCF Services REST Services ASMX Services
Was in the discussion with my coulip to either go for WCF , ASMX or REST Services. Would have been a tough decision if we don't know one of the three services.
Thinking that would like to explore all the services on my blog with this post.
WCF Web API is the next generation of Microsoft's service framework.
WCF Services were originally designed with a channel architecture allowing customization of the protocols and transports used to communicate between systems. While this gives the architect/developer great flexibility in building inter-operable applications, it comes at the cost of complexity. Configuring WCF has never been simple (IMO).
The most prevalent use case (IMO), is using WCF services to provide support to web applications via ajax requests from the browser for additional data. Also, since the time that WCF was originally introduced, it has become common for applications to provide an API using http.
Because the of this, the new WCF Web API is an attempt to simplify the service infrastructure and assume the http transport protocol.
If you are building a new web application, I would use the new Web API. I would only look at using WCF Services if I needed to communicate with another system using something other http.
WCF is not done, nor is it going away anytime soon. WCF is the framework to use to build services that are flexible with regard to transport, encoding, and various protocols. This was precisely what WCF was designed for and what it does extremely well. WCF enables me to write service code and contracts which can then be exposed over various bindings (transport, security, etc.). That hasn’t changed and continues to be the case. If you are building a service in your organization and plan to support multiple protocols, or simply use protocols other than HTTP (tcp, name pipes, udp, etc.) then WCF continues to be your choice.
If you happen to want to expose your service over HTTP with WCF you have two high level choices: SOAP over HTTP or web HTTP. Obviously SOAP over HTTP is simply a different endpoint/binding choice, again where WCF shines. You can also expose your service using the WCF HTTP model that has been around since .NET 3.5. This model changes the dispatching to happen based on URI templates and HTTP verbs rather than SOAP actions. The WCF HTTP model also provides some help in providing help documentation, surfacing faults in an HTTP friendly way (think status codes) and returning content in web friendly formats such as JSON.
But, and there had to be a but, WCF was built as a transport-neutral fashion, that’s a selling point; except when you do care about the transport and really want to leverage HTTP for example.
ASP.NET MVC provides some great tools that could be leveraged for services including model binding and routing. For most people building web APIs, however, there are other concerns as well. As a simple example, I’ve always felt a little uncomfortable building services in MVC because of the standard routing model that includes the action in the URI. A little thing, sure, and something I could work around with some MVC extensions of my own. Web API provides me a model for routing based on HTTP verb rather than a URI that contains an action. This puts me close to the HTTP protocol, simplifies my routing and seems right to me. In addition, Web API allows me to fully leverage content negotiation to enable returning various representations of my objects/resources. This means I have a pluggable model for allowing the client to tell me what representation they would like (text/xml, application/json, text/calendar) and choosing the best formatter to create the best match representation. All this comes with the ability to use the routing, dependency resolution, unit testing, and model binding.
In addition WebAPI allows you to self-host your services a la WCF (and in fact uses a little WCF under the covers to enable this) so you can, if you choose, go outside ASP.NET / IIS as the host of your service and continue to leverage all these great benefits. This enables you to host your HTTP services in any .NET appdomain and still use the same routes, controllers, etc.
Thinking that would like to explore all the services on my blog with this post.
WCF Web API is the next generation of Microsoft's service framework.
WCF Services were originally designed with a channel architecture allowing customization of the protocols and transports used to communicate between systems. While this gives the architect/developer great flexibility in building inter-operable applications, it comes at the cost of complexity. Configuring WCF has never been simple (IMO).
The most prevalent use case (IMO), is using WCF services to provide support to web applications via ajax requests from the browser for additional data. Also, since the time that WCF was originally introduced, it has become common for applications to provide an API using http.
Because the of this, the new WCF Web API is an attempt to simplify the service infrastructure and assume the http transport protocol.
If you are building a new web application, I would use the new Web API. I would only look at using WCF Services if I needed to communicate with another system using something other http.
WCF is not done, nor is it going away anytime soon. WCF is the framework to use to build services that are flexible with regard to transport, encoding, and various protocols. This was precisely what WCF was designed for and what it does extremely well. WCF enables me to write service code and contracts which can then be exposed over various bindings (transport, security, etc.). That hasn’t changed and continues to be the case. If you are building a service in your organization and plan to support multiple protocols, or simply use protocols other than HTTP (tcp, name pipes, udp, etc.) then WCF continues to be your choice.
If you happen to want to expose your service over HTTP with WCF you have two high level choices: SOAP over HTTP or web HTTP. Obviously SOAP over HTTP is simply a different endpoint/binding choice, again where WCF shines. You can also expose your service using the WCF HTTP model that has been around since .NET 3.5. This model changes the dispatching to happen based on URI templates and HTTP verbs rather than SOAP actions. The WCF HTTP model also provides some help in providing help documentation, surfacing faults in an HTTP friendly way (think status codes) and returning content in web friendly formats such as JSON.
But, and there had to be a but, WCF was built as a transport-neutral fashion, that’s a selling point; except when you do care about the transport and really want to leverage HTTP for example.
ASP.NET MVC provides some great tools that could be leveraged for services including model binding and routing. For most people building web APIs, however, there are other concerns as well. As a simple example, I’ve always felt a little uncomfortable building services in MVC because of the standard routing model that includes the action in the URI. A little thing, sure, and something I could work around with some MVC extensions of my own. Web API provides me a model for routing based on HTTP verb rather than a URI that contains an action. This puts me close to the HTTP protocol, simplifies my routing and seems right to me. In addition, Web API allows me to fully leverage content negotiation to enable returning various representations of my objects/resources. This means I have a pluggable model for allowing the client to tell me what representation they would like (text/xml, application/json, text/calendar) and choosing the best formatter to create the best match representation. All this comes with the ability to use the routing, dependency resolution, unit testing, and model binding.
In addition WebAPI allows you to self-host your services a la WCF (and in fact uses a little WCF under the covers to enable this) so you can, if you choose, go outside ASP.NET / IIS as the host of your service and continue to leverage all these great benefits. This enables you to host your HTTP services in any .NET appdomain and still use the same routes, controllers, etc.
No comments:
Post a Comment