This question already has answers here:
What are the differences between WCF and ASMX web services?
(5 answers)
Closed 9 years ago.
its my first question on stackoverflow.
i have read a lot of articles that said developers should use WCF instead of web services, because it could be hosted on different hosting environment,etc...
but what i'm thinking of is that i can call web service form any project using HttpRequest.
so why i have to use WCF.
With WCF, the out-of-the-box binding is BasicHttpBinding, which is just SOAP, the same as .asmx web services. As a client, you can still access it the exact same way you accessed .asmx services - either by generating a proxy from the WSDL, or normal HttpWebRequest or whatever you were using before.
The benefit is all the additional options you get with WCF, like security, the possibility for different bindings, standalone hosting, and a whole lot more. Plus it's the direction the .NET community has chosen, so if you want to stay relevant in a .NET service-based world, you'll need to learn it.
There is a lot more to WCF than there is to an ASMX web service. If an ASMX web service suits your needs then it is fine to use one, however you might find that there are problems that are easier solved using WCF than and ASMX web service. There are also many things that you can do using WCF (remember its a framework not just a way of creating a web service) that you simply can't do using an ASMX web service.
Creating WCF services instead of ASMX web services even if they serve the same purpose may seem like added complexity for no added benefit but it is a good way to start to learn WCF.
You don't have to use Windows Communication Foundation. It is ultimately going to be your choice. Also the project may contribute to your needs.
However, the primary reason you would use Windows Communication Foundation would be the following reasons:
Provides a varying array of communication across several platfrms: HTTP, HTTPS, TCP, MSMQ, and Etc.
It provides additional Security.
It has a better means of Serialization and Deserialization.
It provides more code re useability.
Different forms of hosting.
Those are some of the keys, the most important was it's design to save developers time in web based communication. It also is a methodology to bring Service Oriented Architecture as well, for fully agile applications.
Another important note is to realize that Microsoft has limited support for standard web services; now that they've implemented WCF technology.
Hopefully that helps.
Related
I am working on a Visual Studio Application that references a WCF web service, and after some reading online I am pretty confused.
I have read that WCF is a framework for building a web service, but it is not an API. Is this true?
I was under the impression that Web Services are APIs; I always thought that APIs were Software as a Service (SaaS). Doesn't that mean that APIs and Web Services are pretty much the same thing? Or do I have the wrong idea?
Could this be a misconception of my understandings of SOAP and REST?
Basically I want to know whether a WCF built web service counts as an API, and why/why not?
WCF is an API that can be used to create APIS within your application.
Web Services usually involves creating an API within your application. There are valid APIs that are not Web Services, like the Win32 API.
Its possible to build a WCF web service with one web method for an application that would not be considered an API specifically since it does not contain a set of routines, protocols, or tools for building applications.
Review http://en.wikipedia.org/wiki/Application_programming_interface for what an API is.
According to wikipedia, yes, yes it is:
APIs often come in the form of a library that includes specifications
for routines, data structures, object classes, and variables. In other
cases, notably SOAP and REST services, an API is simply a
specification of remote calls exposed to the API consumers.
An API (Application Program Interface) is a way to interact with components of a system. It defines the operations that can be used to get data out or push it in.
WCF (Windows Communication Foundation) itself is a framework for building web services and other applications that need a communication channel to share data with other services/applications, it is actually a lot larger on what it can do. You can read more about it on MSDN. It is an API as it gives you objects that allow you to tell it interact with its' components.
REST and SOAP are just architecture styles that can be used to serve data via a service, it is defining how you should interact with the data rather than the components themselves.
I suggested we migrate from WCF to Web API due to it being easier to implement and got shot down pretty hard. Here were the objections raised:
WebAPI is just made for rails converts
We have no need for REST or 3rd party open source support, Windows 8 Store Apps with Microsoft backend.
WCF over net.tcp is "MUCH" faster and less overhead than HTTP(S)+XML or JSON
The end comment was "I cannot think of a single advantage of using Web API over WCF.
Funny, my last job at a big MS tech based enterprise changed from WCF to Web API and dev productivity skyrocketed, lots of bugs disappeared and we never had any performance problems, but I don't want to just say that, I want to respond with facts to his points. How would you respond?
WCF or ASP.NET Web APIs? My two cents on the subject:
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.
The whole article is worth a read.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I've spent a few months trying to grasp the concepts behind WCF and recently I've developed my first WCF service application.
I've struggled quite a bit to understand all the settings in the config file.
I am not convinced about the environment but it seems that you can do amazing stuff with it.
The other day I've found out that Microsoft has come out with a new thing called ASP.NET Web API.
For what I can read it's a RESTful framework, very easy to use and implement.
Now, I am trying to figure out what are the main differences between the 2 frameworks and if I should try and convert my old WCF service application with the new API.
Could someone, please, help me to understand the differences and usage of each?
For us, WCF is used for SOAP and Web API for REST. I wish Web API supported SOAP too. We are not using advanced features of WCF. Here is comparison from MSDN:
The new ASP.NET Web API is a continuation of the previous WCF Web API project (although some of the concepts have changed).
WCF was originally created to enable SOAP-based services. For simpler RESTful or RPCish services (think clients like jQuery) ASP.NET Web API should be good choice.
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.
In the scenarios listed below you should go for WCF:
If you need to send data on protocols like TCP, MSMQ or MIME
If the consuming client just knows how to consume SOAP messages
WEB API is a framework for developing RESTful/HTTP services.
There are so many clients that do not understand SOAP like Browsers, HTML5, in those cases WEB APIs are a good choice.
HTTP services header specifies how to secure service, how to cache the information, type of the message body and HTTP body can specify any type of content like HTML not just XML as SOAP services.
Since using both till now, I have found many differences between WCF and Web API. Both technology stacks are suited well to different scenarios, so it is not possible to say which is better, this depends on configuration and scenario.
Properties ASP.Net Web API WCF
--------------------------------------------------------------------------------------------------
End point (mainly) Http based SOAP based
Service Type Front End Back-end
Support caching, compression, versioning No
Framework ASP.net WCF
Orientation Resource Oriented Service Oriented
Transports http http, tcp, MSMQ, Named pipe
Message pattern Request reply request Reply, one way, duplex
Configuration overhead Less Much
Security lesser than WCF (web standard security) Very high (WS-I standard)
Hosting IIS IIS, Windows Service, Self hosting
Performance Fast A bit slower than Web API
In use from .NET 4.0 .NET 3.5
Note: The data is not only my view, it is also collected from other official websites.
WCF will give you so much of out the box, it's not even comparable to anything. Unless you want to do on your own implementation of (to name a few) authentication, authorization, encryption, queuing, throttling, reliable messaging, logging, sessions and so on. WCF is not [only] web services; WCF is a development platform for SOA.
Why I'm answering:
I took huge amount of time to understand the difference between these two technologies. I'll put all those points here that I think "If I had these points at the time when I was wondering around in search of this answer, then I have decided very earlier in selecting my required technology."
Source of Information:
Microsoft® Visual Studio® 2015 Unleashed
ISBN-13: 978-0-672-33736-9 ISBN-10: 0-672-33736-3
Why ASP.NET Web API and WCF:
Before comparing the technologies of ASP.NET Web API and WCF, it is important to understand there are actually two styles/standards for creating web services: REST (Representational State Transfer) and SOAP/WSDL. The SOAP/WSDL was the original standard on which web services were built. However, it was difficult to use and had bulky message formats (like XML) that degraded performance. REST-based services quickly became the alternative. They are easier to write because they leverage the basic constructs of HTTP (GET, POST, PUT, DELETE) and typically use smaller message formats (like JSON). As a result, REST-based HTTP services are now the standard for writing services that strictly target the Web.
Let's define purpose of ASP.NET Web API
ASP.NET Web API is Microsoft’s technology for developing REST-based HTTP web services. (It long ago replaced Microsoft’s ASMX, which was based on SOAP/WSDL.) The Web API makes it easy to write robust services based on HTTP protocols that all browsers and native devices understand. This enables you to create services to support your application and call them from other web applications, tablets, mobile phones, PCs, and gaming consoles. The majority of applications written today to leverage the ever present Web connection use HTTP services in some way.
Let's now define purpose of WCF:
Communicating across the Internet is not always the most efficient means. For example, if both the client and the service exist on the same technology (or even the same machine), they can often negotiate a more efficient means to communicate (such as TCP/IP). Service developers found themselves making the same choices they were trying to avoid. They now would have to choose between creating efficient internal services and being able to have the broad access found over the Internet. And, if they had to support both, they might have to create multiple versions of their service or at least separate proxies for accessing their service. This is the problem Microsoft solved with WCF.
With WCF, you can create your service without concern for boundaries. You can then let WCF worry about running your service in the most efficient way, depending on the calling client. To manage this task, WCF uses the concept of endpoints. Your service might have multiple endpoints (configured at design time or after deployment). Each endpoint indicates how the service might support a calling client: over the Web, via remoting, through Microsoft Message Queuing (MSMQ), and more. WCF enables you to focus on creating your service functionality. It worries about how to most efficiently speak with calling clients. In this way, a single WCF service can efficiently support many different client types.
Example of WCF:
Consider the example:
The customer data is shared among the applications. Each application might be written on a different platform, and it might exist in a different location. You can extract the customer interface into a WCF service that provides common access to shared customer data. This centralizes the data, reduces duplication, eliminates synchronization, and simplifies management. In addition, by using WCF, you can configure the service endpoints to work in the way that makes sense to the calling client. Figure shows the example from before with centralized access of customer data in a WCF service.
Conclusion:
i) When to choose Web API:
There is no denying that REST-based HTTP services like those created using ASP.NET Web API have become the standard for building web services. These services offer an easy, straightforward approach for web developers building services. Web developers understand HTTP GET and POST and thus adapt well to these types of services. Therefore, if you are writing services strictly targeted to HTTP, ASP.NET Web API is the logical choice.
ii) When to choose WCF:
The WCF technology is useful when you need to support multiple service endpoints based on different protocols and message formats. Products like Microsoft BizTalk leverage WCF for creating robust services that can be used over the Web as well via different machine-to-machine configurations.If, however, you do need to write an application that communicates over TCP/IP when connected to the local network and works over HTTP when outside the network, WCF is your answer.
Be Warned:
Web developers often view WCF as more difficult and complex to develop against. Therefore, if you do not foresee the need for multiprotocol services, you would likely stick with ASP.NET Web API.
There is a comparison on MSDN about this
WCF and ASP.NET Web API
For me, the choice was about Who the clients are, and where are they located?
Within the company Network and .NET based clients : Use WCF with TCP binding (Fast communication than HTTP)
Outside the company Network, and use diverse technologies like PHP, Python etc: Use Web API with REST
Business speaking, WebApi lacks of a WSDL, so the developers should document all manually. And if, for example, the WebApi operation returns a list of objects then, the client should creates the objects manually, i.e. WebAPI is really prone to errors of definitions.
The pro of Webapi is its more lightweight than WCF.
Regarding the statement "WebApi lacks of WSDL" there are several ways to generate Rest client. One popular approach is Swagger UI / (Swashbukkle Nuget). This gives a rich interface to understand the REST end point's input and output schema and online tool to test the end points.
JSON LD (Json Linked Documents) is another emerging standard which will further improve the JSON based REST developer experience by exposing the JSON schema with better semantics.
With wcf we can configure and expose the same service support for multiple endpoints like tcp, http.if you want your service to be only http based then it will be better to go with web API. Web API has very less configuration when compared to wcf and is bit faster than wcf. Wcf also supports restful services. If you have limitation of .Net framework 3.5 then your option is wcf.
I would like to access to multiple web services with a WPF application (Facebook, Twitter, etc...).
I'm not familiar at all with WCF and I was wondering what should I use and why (pros and cons) ? WCF or something else more traditional (like HttpWebRequest) ?
Go with WCF! It's the way to go, it's the present and future of Microsoft's "connected systems" strategy. You can attach to just about anything using WCF - and contrary to Khalid, I don't think it has a really high learning curve.
Get yourself a good book - I recommend Learning WCF by Michele Leroux Bustamante - check out her samples, play with those.
Also check out online resources:
WCF Developer Center on MSDN with tons of articles, screen casts etc.
Dotnet Rocks TV: Keith Elder Demystifies WCF
Dotnet Rocks TV: Miguel Castro's Extreme WCF
That should easily get you started! There's a ton more stuff out there.
Watch those two DNR-TV screen casts - they show how to really understand what is needed in terms of WCF configuration. It's really not rocket science! But unfortunately, the "Add Service Reference" and svcutil.exe both have a tendency to create awfully and overly complicated configs - that's not necessary.
More online resources for WCF REST and Twitter:
MSDN Developer Center for WCF REST
Pluralsight Screencast library on WCF REST
Screencast: Using HttpClient to consume Twitter in under 3 minutes
Why be "traditional" when you can get WCF to do some of the work for you?
If you're accessing a number of services, you'll be writing a lot of duplicate code. You might then refactor the duplication into a framework for calling the services.
WCF already is such a framework, so why write your own?
I've developed with both WCF and straight web requests.
WCF can be great when developing web services, but there is no guarantee that all third party services will be implementing a protocol that works with WCF (add service reference or svcutil).
Also WCF has the advantage of being hosted anywhere you want, like Console, Web site, WPF application, or Windows Service. When it comes to configuration there is a high learning curve with WCF, so understand that going in.
More and more third party services are adopting a REST interface. This means most of your calls out will be done using the HttpWebRequest. Once you make the call to the service, you will have the issue of deserializing the data coming back (XML, JSON, Key/Value Pair, Fixed Length). If it is XML or JSon, look into using the XmlSerializer or DataContractSerializer.
So if you are writing your own web service (calls coming in), go ahead and use WCF. If you are consuming a web service (calling out to a service i.e. Twitter) you most likely won't have the choice to use WCF.
Ok, all these methods of getting data in a Silverlight control are confusing me.
I've looked at ADO.Net Data Services, Web Service and Silverlight-enabled WCF services.
I'm just not sure when one is appropriate to use over another. What pros/cons do each offer?
I've built a web app, and a Silverlight control. I will be adding one of those 3 options to my web application and consuming it from my Silverlight component.
From the silverlight perspective, WCF is heavily constrained anyway, so most of the usual benefits of WCF don't apply. However, it is still a fairly nice, consistent programming model.
WCF is primarily a SOAP stack, so it is very good at presenting data as rigid operations. ADO.NET Data Services is a REST stack, and allows very expressive queries to be performed dynamically over the wire.
I don't know how it is in Silverlight, but a regular ADO.NET Data Services proxy (the bit on your client app) has very rich support for both query and data changes back to the server. Note that applying changes requires either a: Entity Framework, or b: lots of work. But you should get query and update very cheaply with this approach.
With WCF, you get a much more controlled stack, so you will need to code all the distinct operations you want to be able to do. But this also means you have a known attack surface etc; it is much harder to exploit a locked down API like a fixed SOAP endpoint.
Re regular web-services (pre-WCF): only go down that route if you want to support very specific legacy callers.
I know this is old, but I just wanted to add my 2 cents.
I would highly recommend using WCF; and use the WCF Service Library project over the Silverlight-enabled web service. They are both essentially the same, but the Silverlight-enabled web service changes the binding to basic instead of ws*. It also adds an asp.net compatibility mode attribute.
WCF is usually faster: See "A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies" # http://msdn.microsoft.com/en-us/library/bb310550.aspx
WCF encapsulates asmx, wse, msmq, enterprise services, and remoting.
WCF services can be included and run within iis, windows forms, etc.
WCF isn't restricted to using HTTP, but with minimal configuration can also use tcp, named pipes etc.
complex data types are easier to expose and serialize.
WCF just scales really well. Plus, they can be used to incorporate workflows from WF.
There's probably not a wrong technology to use, but it seems as if Microsoft is going to be moving forward with WCF. Plus, it's just so much easier to write one code base that can be exposed so many different ways with just a few configuration changes to the WCF service.
I recommend not using the Silverlight-enabled web service, just because the programming structure is set up a little better with the WCF model, but this is probably a matter of opinion.
If you have to choose between a web service and a WCF service, my advice is to go with WCF. It's more modern and more powerful technology. As for ADO.Net Data Services - you can use that if all you need is to retrieve/commit some data from/to a database back on the server.