I'm about to start a project where we have a back-end service to do long-winded processing so that our ASP.NET website is free to do quicker requests. As a result I have been reading up on services such as WCF and Web API to get a feel for what they do. Since this back-end service will actually be made up of several services communicating to each other and will not be publicly available to our customers, it seems that WCF is the ideal technology for this kind of scenario.
But after doing a lot of research I am still confused as to the benefits and differences between WCF and Web API. In general it seems that:
If you want a public and/or a RESTful API then Web API is best
WCF can support far more transports than just HTTP so you can have far more control over them
Web API development seems easier than WCF due to the additional features/complexity of WCF
But perhaps my question boils down to the following:
Why would a REST service be more beneficial anyway? Would a full blown WCF service ever be a good idea for a public API? Or is there anything that a WCF service could provide that Web API cannot?
Conversely, if I have a number of internal services that need to communicate with each other and would be happy to just use HTTP as the transport, does Web API suddenly become a viable option?
I answered a couple of related questions:
What is the future of ASP.NET MVC framework after releasing the asp.net Web API
Should it be a WebAPI or asmx
As an additional resource, I would like to recommend you to read:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
If you want to learn more about REST, check this Martin Fowler article
Summaring up:
As far as I know, both technologies are being developed by the same team in Microsoft, WCF won't be discontinued, it will still be an option (for example, if you want to increase the performance of your services, you could expose them through TCP or Named Pipes). The future is clearly Web API
WCF is built to work with SOAP
Web API is built to work with HTTP
In order to take the correct choice:
If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.
One combersome bit of WCF is the need to generate new client proxys when input and/or output models change in the service. REST services don't require proxys, the client simply changes the query string sent or changes to parse and/or use the different output.
I found the default JSON serializers in .Net to be a bit slow, I implemented http://json.codeplex.com/ to do the inbound and output serialzation.
WCF services are not that complex, REST services can be equally challenging as you're working within the confines of HTTP.
ASP.net Web API is all about HTTP and REST based GET,POST,PUT,DELETE with well know ASP.net MVC style of programming and JSON returnable; web API is for all the light weight process and pure HTTP based components. For one to go ahead with WCF even for simple or simplest single web service it will bring all the extra baggage. For light weight simple service for ajax or dynamic calls always WebApi just solves the need. This neatly complements or helps in parallel to the ASP.net MVC.
Check out the podcast : Hanselminutes Podcast 264 - This is not your father's WCF - All about the WebAPI with Glenn Block by Scott Hanselman for more information.
Related
I have worked with both technologies yet I’m about to build a new backbone services layer and thinking about WCF vs Web-Api.
The idea is to create a layer of services that will be consumed by both internal .NET components and by front applications.
The following are issues are not relevant to this case:
TCP, UDP
Proxy generator
WS-* standards like Reliable Messaging, Transactions
I'm considering about 2 approaches:
Web-api for app front application above n-tier WCF services
Web-api for app front and for a flexible services layer, thus avoiding HTTP hop between services
Our system is financial oriented, some services will operate as data services using the using some kind of OData and some will perform complex financial transaction (using complex types).
I've read about the new stuff that was recently added to Web-Api 2 and it seems to be a leading platform. I've Googled a lot about pros and cons and that WCF is still alive (or frozen).
A few of the relevant references:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
http://msdn.microsoft.com/en-us/library/jj823172.aspx
Under the assumption that all the services are on the same LAN and this is targeted to enterprise system, what would you recommend and why?
Here's the question... Do you need transport layer flexibility or are you fine with them being http(s) only services? If the services are HTTP-only and (as you say) you don't care about proxy gen and WS-* then I can't for the life of me think of a reason why you'd use WCF.
The programming model for REST / plain old http(s) is just so much leaner, the MVC "style" much more natural and not to mention that WCF can just get really complex really fast, makes me think that I would need a really good reason to choose WCF in 2013...
Not to throw a spanner into the works, but have you considered Service Stack:
https://servicestack.net/download
That's what I'd be using... (btw I'm not affiliated with them in any way / shape / form).
If you need multiple endpoints/transport protocols, or the ability for other applications to consume your services in .NET and work with them as you would any other referenced library (via web reference and a SOAP endpoint) the WCF should be your choice.
If you're looking for something lightweight and convention-based and/or you're looking to create a RESTful API, and HTTP(S) is an adequate transport, then Web API is the way to go. In this case, if you want the strong typing that you'd get with a SOAP web reference you'd probably be wise to write a reusable library that acts as middleware for consuming the services and providing data.
I've the good fortune of being able to kick off a new project with the tooling of my choice, which is ServiceStack. The Architecture is very solid and the product was out before web api was even a glimmer in someones eyes. That being said, it would be a great plus, if I could also recreate some legacy SOAP endpoints and route then through this service instead of have two apis running at the same time. Is there a preferred way to do such a thing?
Thank you,
Stephen
Not sure about what migrating legacy SOAP endpoints over to ServiceStack entails.
But ServiceStack's SOAP support works like all the other REST, Web and MQ endpoints and Content-Types, where it automatically exposes SOAP endpoints around your services Request and Response DTOs allowing it to be called via SOAP 1.1/1.2.
The inherent limitation in SOAP means that only Services that support POST (i.e. Post() or Any()) are available to be called by SOAP. For services that use any other HTTP/REST Verbs it will be disabled in the metadata pages as seen in the SocialBootstrap API metdata pages. See SOAP Limitations for other things you should be weary of.
The metadata pages also contain links to your services WSDLs and XSDs, e.g:
/api/soap11/
/api/soap12
XSDs: /api/metadata?xsd=1
If you want to host legacy .asmx SOAP services in the same application than you should host ServiceStack on a /custompath so you're able to use it with any other ASP.NET Web, MVC or other web services frameowrk.
Should I leverage an ASMX service or the ASP.NET Web API for my two simple API's?
I want to create two simple APIs in my ASP.NET MVC project. One takes in 3 parameters (currentUserID, DataType, ActionName). It returns them and an XML string of the data they have requested. The API is consumed by client-side JavaScript code. The other API receives an XML string and uses that on the server side to perform actions on the database.
I just answered a related question:
What is the future of ASP.NET MVC framework after releasing the asp.net Web API
Basically, the frameworks provided by Microsoft to develop Web Services are:
ASMX. XML Services based on SOAP.
WCF. Web services based on SOAP. These services were the evolution of the traditional ASMX services and basically they focused to separate the service itself from the transport protocol. That's why you can expose the same service using several endpoints and therefore several protocols (TCP, HTTP, Named Pipes, MSMQ, HTTPS). This flexibility came with the configuration problem. One of the main complaints in the community about the WCF is the tedious and extensive configuration
WEB API. Based on HTTP not in SOAP. This new API is a new framework to create services. The main difference with the other two predecesors, is the fact that it's based on HTTP and not on SOAP, therefore you can use several HTTP features like:
It contains message headers that are very meaningful and descriptive - headers that suggest the content type of the message’s body, headers that explain how to cache information, how to secure it etc.
use of verbs to define the actions (POST, PUT, DELETE..)
it contains a body that can be used to send any kind of content
It uses URIs for identifying both information paths (resources) and actions
WEB API is focused on writing services to expose them via HTTP (only on HTTP at the moment). If you want to expose your service using another protocol, then you should consider using WCF.
WEB API is based on MVC (if you want to know the reasons why it's based on MVC, they are simple)
Another goal of the WCF Web APIs was to incorporate known concepts that would help developers to overcome some of the drawbacks they faced with WCF, such as huge configurations, overuse of attributes, and the WCF infrastructure that did not support testing well. Thus the Web APIs used IoC, enabled convention-over-configuration, and tried to offer simpler configuration environment.
ASP.NET MVC infrastructure with its elegant handling of HTTP requests and responses, and its support of easy-to-create controllers seemed like the proper way to go for creating this new type of services.
Take the following points into consideration to choose between WCF or WEB API
If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.
For a more detailed comparison:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
It seems you are really doing much with Views so I think Web API would be more concise solution at this point.
If possible, I would use an Web Api Controller in mvc4. You can return an generic ienumerable list or model and it will automatically output the data to whatever format is requested such as xml or json. Its pretty amazing.
On our services, we configure several endpoints, allowing us to publish the same interfaces to SOAP 1.1 and 1.2 clients and HTTP clients consuming either XML or JSON. Now that the WCF REST team has been merged into the ASP.NET team to create the Web API stuff, what will this mean for us in the future? Will it still be supported to expose WCF interfaces as XML/JSON services? Should we move the REST endpoints to the Web API framework? Will this be the last shift of the MS REST stack?
Good question. I don't work for Microsoft and I don't have any inside information but my understanding is that WCF will be able to expose XML and JSON forever. In fact if you are merely exposing JSON or XML endpoints you are not doing REST. The real question is do you use the HTTP verbs (DELETE, PUT, POST, GET) as part of your API or you are simply exposing methods that are equivalent to your SOAP methods. If you are using the HTTP verbs it may be a good long-term strategy to migrate the REST part to WebAPI. If you are not then you can happily use WCF (go ahead tell your cusomers you are using REST for marketing reasons, to marketing people it's just a buzzword anyway).
If you are using the HTTP verbs it is not that hard to have both WCF and WebAPI. All you need to do is remove all logic from the service itself and expose it as a business layer methods. Then both kids of services can use these methods, call them in the appropriate way and shape the results.
To answer this, you need to have a little history on the ASP.NET Web API.
Initially the ASP.NET Web API it was the WCF Web API, a project on Codeplex extending WCF to make it easier to support a REST-style service. WCF was entirely built on SOAP as its core messaging type, so using HTTP as anything other than a transport-layer protocol required a different approach, with a different set of attributes and generally didn't mesh well with the rest of the framework.
The WCF Web API was extending the WCF framework in all the ways required to support HTTP as an application-level transport mechanism. It was introducing request routing based on the resource URI, dynamic formatting according to the Accept headers and the other things which were previously missing from WCF.
However, it became clear during its development that these technologies already existed within .NET, in the MVC stack. Thus, the decision was made that rather than having two competing sets of technologies, they move the work over to the ASP.NET MVC team, and the ASP.NET Web API was born.
If you are doing a REST-style service, the ASP.NET Web API is much better suited to your needs than the WCF framework. The WCF team will not be progressing their support for the REST-style architecture; these features of the WCF framework are effectively subsumed by the Web API, where it finds a much more natural fit.
Should you re-write your services to use the new Web API? Well, the REST features of WCF aren't going to suddenly stop working. You should only consider the move if it gives you some features you're after (like dynamic content-format selection), or if you're looking to continually develop your API (as the Web API is significantly easier to use than WCF).
I'm new to .Net and do not understand the difference. Can someone point me in the right direction?
ASP.NET Web services was developed for building applications that send and receive messages by using the Simple Object Access Protocol (SOAP) over HTTP.
WCF is for enabling .NET Framework applications to exchange messages with other software entities. SOAP is used by default, but the messages can be in any format, and conveyed by using any transport protocol.
You can view ASP.NET web services as a subset of WCF services.
Here is a link comparing the two frameworks.
it is quite easy to know the differences.
ASP.NET Web Method is called ASMX [because of the file extension] (check 4GuysFromRolla about this, they have a good tutorial)
That technology makes you expose functions as a Web Service so you can connect it from everywhere and use it. But... you can't protect the data between server and client, you can send big files clear and know what happend, etc...
[Note] you can protect the access to the web service using certificates, but it is complicated but normally, in ASMX we use username / passsword.
in WCF, you are in the different world about Web Services,and this s the best technology in .NET to expose Services (can you see the difference... Services! not Web Services), WCF does not need IIS to run, it can run as a System Service on the server, using a console ambient (like command line), etc, so we say that WCF is a Service not Web Service. Remember ASMX need IIS to run.
with WCF you can use SSL to encrypt the communication (to do that in ASMX you need to use WSE - Web Services Enhancements), you can send big files and securely (to do that in ASMX you need to use MTOM - Message Transmission Optimization Mechanism).
you can set the transmission preferences just changing one line of code, the security is much higher, etc, etc :)
hope you get a better general overview with this, but there is much more.
bottom line: to expose Web Services that you do not need to protect, you can use ASMX, no problem at all, but if you need to protect the communication somehow, do it in WCF!
link: you can read here some performance comparative between the 2 services
They are two different frameworks for writing services. WCF is generally more flexible and provides configurable options for what protocols are used, how the service is hosted and a variety of security options. ASMX offers SOAP based services. Generally WCF is also more performant. In general ASMX is easier to use and generally has less of a learning curve.
Here is a MSDN forum discussion on the topic.
Here are the getting started pages for ASMX and WCF.
In addition to the above responses, WCF was created to replace .NET Remoting in .NET 3.0 and beyond. In addition to SOAP, REST, POX, etc. web services in various formats (e.g. XML and JSON), WCF also offers MSMQ and Named Pipes. ASMX, as mentioned above, provides only SOAP-based XML web services.
You would need to delve into .NET Remoting for other types of communication protocols. For additional information, you should check out Pro C# 2008 and the .NET 3.5 Framework. It's a great resource, and you can get the chapters from the previous books that cover .NET Remoting, and other replaced features.
Here's a new, big, difference: Microsoft now considers ASMX web services to be "legacy" technology. See "XML Web Services Created Using ASP.NET and XML Web Service Clients".
Web Services
It Can be accessed only over HTTP
It works in stateless environment
WCF
WCF is flexible because its services can be hosted in different types of applications. The following lists several common scenarios for hosting WCF services:
IIS
WAS
Self-hosting
Managed Windows Service
They are two different things all together. WCF is a more generic framework through which you can write one service type component and deploy it in many ways (even as an Asp.Net Web Service).
Here's a brief thread about this http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/2d6a7ff2-f15c-4599-a389-a81cfffcc852/
I had the same problem.
I found the book Microsoft Windows Communication Foundation Step by Step to be really good.
If you just want to do the traditional webservice thing using WCF, then Chapter 1 of that book will show you exactly how to do that (write service, test, deploy, use service).
Its written for VS2005, but I'm using vs2008 and found it even easier.
There's a lot more to WCF, but that book is a good start.
Main Differences between Web service and WCF are listed below.
Web Service : Web Service is an application that is designed to interact directly with other applications over the internet.
1) [WebService] and [WebMethod] attributes defines a web service and methods.
2) It Can be accessed only over HTTP.
3) Hosted in IIS.
4) Support security services.
5) Can not be multithreaded.
6) Only Used Soap or XML.
7) System.Xml.serialization name space is used for serialization
WCF :Windows Communication Foundation (Code named Indigo) is a programming platform and runtime system for building, configuring and deploying network-distributed services.
1) [ServiceContract] and [OperationContract] attributes defines a web service and methods.
2) Accessed through HTTP, TCP, MSMQ, P2P, Named pipes
3) Hosted in IIS, Self-Hosting ,WAS and Windows Service.
4) Can be multithreaded via service behavior class.
5) System.Runtime.Serialization namespace is used for serialization
6) Supports different type of bindings like BasicHttpBinding, WSHttpBinding,WSDualHttpBinding etc.
7) Support security services, reliable messaging, transactions, AJAX and REST Support