I'm looking for the difference summary between ASP.NET MVC Web API and WCF Service.
I've seen this question What is the difference between Asp.Net Web API and WCF Service?
and this question WCF vs ASP.NET Web API too, but they don't summarize what I can achieve with the one, what I cannot achieve with the other.
Both can be contacted via url, I first thought that was a difference between them.
So in short:
What can I do with WCF what I cannot do with ASP.NET Web API and visa versa?
this list is by no means exhaustive.
Things WCF does that you cannot do (with ease) using Web API.
Supports SOAP based XML format.
Supports strongly typed data contracts.
Supports a single point of metadata information exchange using WSDL etc.
Supports varied bindings like TCP, Named Pipes, MSMQ, even UDP etc.
Supports varied hosting options like console apps, WAS, IIS, Windows Services.
Supports one way messaging, duplex, message queues out of the box.
Supports multiple authentication schemes like Windows, Forms, Certificates etc.
Things Web API does that you cannot do (with ease) using WCF.
Supports the full features of HTTP. (Uri based access, Http Requests/Response, Http Caching etc.) To do this in WCF you need to additional work to configure it as REST service etc.
Is Lightweight with minimal configuration.
Supports the Routing, Controller/Action MVC paradigm, Model Binding etc.
Basically Web API is an easy way to do RESTful services over Http without knowing much about Web services.
To do the same in WCF, you need to do additional work in terms of httpBindings, UriTemplates, Verbs etc. And that means, understanding WCF first. And then using WCF to implement a RESTFul service over http, which is what Web Api provides out of the box.
This is not a summary per se. Its a sort of practical guide I hope.
For me it ultimately boils down to how simple I want my front-end application code to look like, and also something to do with how to achieve maximum productivity.
Traditional WCF over http is SOAP based messaging protocol. You add a service reference in your project, and Visual Studio takes care of generating the proxy classes. And you work with the instance of the proxy classes. So when you are writing your front-end code, you have intellisense to help you. Don't be fooled. This is just the IDE making life simpler for you. Underneath its pretty complicated. But my productivity is boosted to a degree. I don't have to write proxy classes. Hence, this is what I'd opt for a c# based front-end.
Alternatively, if I had to deal with a Webapi endpoint, I do not have the luxury of any IDE generated proxy classes. Therefore I'd have write code for everything. Typically I use the HttpClient classes to talk to my web api end points. Hypothetically, I could write a proxy classes to talk to web api. But it isn't as simple as in your wcf case where they were auto-generated for you.
On another line or reasoning, if my front-end was JavaScript, then my only best bet is have the web service hosted over web api, rather than wcf. If I were to talk to wcf endpoints from Js, that would be a PITN.
So it ultimately rests on your product plan, design, project schedules, etc software development plan. All the best.
Related
I'm going to start a new AngularJS Project blended with Microsoft .NET. Now I'm confused which one should I select, WCF Rest or Web API ?
My Angular App has a Login Module and a Main Application. Only the authenticated user can access the Main Application. In Web API we have to use Token System or Owin Auth, but some blogs are saying its not so secure. So, I am totally confused which should I choose ? which one is efficient and secure ?
WCF Rest
To use WCF as WCF Rest service we have to enable webHttpBindings.
It supports HTTP GET and POST verbs by [WebGet] and [WebInvoke]
attributes respectively.
To enable other HTTP verbs we have to do some configuration in IIS
to accept request of that particular verb on .svc files
Passing data through parameters using a WebGet needs configuration.
The UriTemplate must be specified
It supports XML, JSON and ATOM data format.
Web API
This is the new framework for building HTTP services with easy and
simple way.
Web API is open source, an ideal platform for building REST-ful
services over the .NET Framework.
Unlike WCF Rest service, it uses the full features of HTTP (like URIs,
request/response headers, caching, versioning, various content
formats)
It also supports the MVC features such as routing, controllers,
action results, filter, model binders, IOC container or dependency
injection, unit testing that makes it more simple and robust.
It can be hosted with in the application or on IIS.
It is light weight architecture and good for devices which have
limited bandwidth like smart phones.
Responses are formatted by Web API’s MediaTypeFormatter into JSON,
XML or whatever format you want to add as a MediaTypeFormatter.
Kindly assist me, which one is efficient and secure?
Nancy
Lighter-weight than either web-api or WCF
Convention-based, low on ceremony
As fully featured as WebAPI in terms of HTTP support
Supports Razor view engine
Supports OWIN pipeline
Comes with its own IOC out of the box
Initially when I built an application, there was only a requirement to expose an endpoint using WCF. Now, there is a requirement to expose another endpoint using REST therefore I have used .Net Web Api to do so. The WCF endpoint is hosted in a Windows service therefore I have hosted the Web Api endpoint in the same service. Are there any issues in doing so? Any performance considerations? After some exhaustive searching, I couldn't find any substancial information on the topic.
Are there any issues in doing so?
It may be better to expose the rest API via WCF using webHttpBinding rather than introduce WebAPI into the mix. I'm not aware of any problems this would cause per se, but in terms of solution simplicity I think it makes more sense to take advantage of WCF's multiple-endpoints-to-one-service-contract mapping capability.
I did consider this but I've read a lot of bad reviews about using WCF
to expose RESTful endpoints. Moreover, it appears Web Api is the
preferred technology as mentioned here:
WCF vs ASP.NET Web API
Agreed. If you were starting from scratch then I wouldn't hesitate recommending WebAPI over WCF (actually I would recommend using Nancyfx over WebApi any day of the week).
You can expose your service as HTTP with about 10 minutes work using WCF, assuming you wish to expose the same operations as are currently defined on your service contract, as you have already have the soap endpoint.
Plus you will end up with a simpler solution without the considerable bloat of asp.net/owin.
I'm just starting a project where I would like to use Kendo UI (based on jquery) with C#. A few weeks ago I was successful in handling requests using Web Services (asmx), was pleased with the results and performance, and was able to create forms quickly.
Since this is a new project, I thought I could look into different concepts such as MVC and WebApi. I found MVC to be the most complicaded so I went for WebApi and started playing with controllers and requests. So far what I'm finding (don't judge me, I'm new to these new concepts), is that Web Service seems to be simpler and more flexible.
So I guess what I'm looking for is... what are the main advantages of using MVC vs WebApi and even vs Web Services. Are there any downsides to Web Services? Would it be a bad practice to have my data layer controlled by Entity Framework, all models defined, and my requests handled by Web Services?
Any clarifications are welcome. Thank you.
In a broader sense, Web API is used to create Web Services ! It uses HTTP as its standard for creating services (instead of SOAP like in asmx) as its more open and any type of client like a mobile app, desktop app, web app etc will understand HTTP protocol. Another advantage is that u can easily use JavaScript/jQuery to communicate with your Web API. With SOAP web services, its a nightmare!
Kendo UI and Web API is a great combination. We have recently created a mobile iPad app using this combination and it worked like a charm. We also used Entity Framework with oracle as back end DB and it never gave any issues.
Webservices are nice if you have the need for it. A need as in needing that logic/data in more than one different type of application (such as web, and a mobile app, and a desktop app). (Or if you want to sell the service you're providing)
Using a webservice for ONLY a website which you don't except to expand to other things is complete overkill.
Furthermore, the MVC framework and the Web Api framework are pretty similar except web api is used exclusively for webservices. Coding in both of them will be the difference between white bread and wheat bread.
Please forgive me for this basic and a little theoretical question as I dont know much about web services.
I m not refering WCF service, I am reffering simple service in .net / C#. I want to know how to know is it soap or rest service ?
How we can change this type from Soap to Rest and vice versa ?
Thanks
XML Web Services (aka classic/legacy ASMX web services) should not be used for active development. If you must, there is a nice walkthrough on MSDN for adding Web references in more recent versions of Visual Studio (> 2005).
On the other hand, if your web service is truly Restful then you won't be able to create the equivalent of a service reference to it. You'll need to either use the HttpWebRequest, WebClient, or the new HttpClient from .NET 4.5 (also available from the Rest starter kit which is depreciated as well).
As an alternative if you are looking to implement a client that is able to handle both situations, I would recommend HttpWebRequest to POST to the SOAP (non-WCF) service. The problem with this method is you'll likely have to wrap the request in the SOAP wrapper yourself. Luckily there are examples of doing so on the net that you can at least use as a starting point.
ASMX services are build upon SOAP. REST is simply a HTTP based, You can access(or call) your business resources the way you access the normal URLs.
For ex in products catalog system, by using asmx you create set of functions to add,update,delete products. like addProduct(),updateProduct, etc..
But in REST, you will be having single point of access, like http:\mysystem\prodcuts. To retrieve,add,update,delete products, you will be using respective HTTP verbs (GET,POST,PUT,DELETE) on the same URL.
so,technically it's not possible to convert asmx(SOAP) service to rest...
I am starting development of the new project and since I am new in the WCF world I want to ask your advice.
I am going to implement web-service which will provide data for WPF client and for ASP.NET site. Web site and web service should be hosted in the Windows share hosting (not didicated server) and this fact is bothering me. WPF client and web site will provide almost the same functionality for the user, so I want to implement all logic inside web service not to duplicate it in the client and web site.
Not sure what is the best way to implement such web-service - REST, SOAP or something else? Please, help me with selecting technology for web-service creation, I just want to get direction for optimal solution. 10x.
Update: Sorry I did not wrote details. Service will be something like on-line shop with admin panel, so web service will be used for getting products and for adding new product to the system. It does not support tons of customers, it's just solution for small web-shops.
since you are developing a Web based solution and a WPF client, i would recommend the following options for your WCF services:
REST Option - This option is good if you have some complex Ajax architecture on the client using Json and stuff, or if you want to expose your services publicly. In this case the option is to expose an HTTP endpoint using webHttpBinding on your service. Since your deployment will be on a shared web server, you can host your service inside IIS. I would recommend considering a SSL option for security.
Soap Option - This options is the easy one, and should be more familiar to most developers, since it acts like a usual web service. In this case i would use an HTTP endpoint with wsHttpBinding on the service for enhanced security. Since your deployment will be on a shared web server, you can host your service inside IIS. I would recommend considering a SSL option for security.
Whatever solution you choose you will be able to accomplish your goal to have simple SOA architecture in place and will have centralized services for your CRUD operations.
I hope this answered your question.