I've read from Scott Hanselman that a self-host console application of ASP Web API has 50% speed efficiency over a traditional ASP.NET MVC Web API project, since it doesn't have as much internal overhead.
My question is, what if I want to host a Web API in IIS? Can't use a Console Application, but still want to reap the benefits of not having the entire ASP.net framework overhead for only needing a simple web API?
It is 'theoretically' possible with OWIN. Some one asked the same question here.
Related
i was asked in an interview the following question about webapi
Why we need webapi?
I told "the services that are created in webapi can be used across wide range of devices like laptop, desktop, tablet and mobiles."
Then the interviewer asked why it cannot be done using web services and wcf?
I don't know the answer.
Can anyone let me know the answer.
Copying the title of your question into a search engine yielded the following link.
WCF and ASP.NET Web API
WCF is Microsoft’s unified programming model for building
service-oriented applications. It enables developers to build secure,
reliable, transacted solutions that integrate across platforms and
interoperate with existing investments. (ASP.NET Web API) is a framework
that makes it easy to build HTTP services that reach a broad range of
clients, including browsers and mobile devices. ASP.NET Web API is an
ideal platform for building RESTful applications on the .NET
Framework.
There is also a table detailing when you should use which.
There are so many things today? I'm looking to host web api in windows service but recently I come across this link http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
is this a new thing and should we use this OWIN, Please suggest?
Does this OWIN make thing more faster or what are the benefit to use OWIN?
OWIN makes things a bit simpler and cleaner when self-hosting.
You might want to check out the OWIN Web API 2 self host in windows service example on GitHub.
Web API is based on owin, and owin is an abstraction. Instead of those old times when web api team was responsible for making web api availble on several hosts such as IIS, self host, etc, it just relays on owin. Owin has several implementations based on IIS, ASP.NET, ASP.NET Core, Self Host etc.
For example see the following sample of running asp.net web api odata on asp.net core using owin & kestrel: https://github.com/ymoradi/OwinAspNetCore
After doing more searching OWIN and Kanata are just layers on top particularly WebAPI, they are rather an convenient composer from what I understand from here http://msdn.microsoft.com/en-us/magazine/dn451439.aspx
for my purpose, I use WebAPI ONLY, so I don't need all these extra things.
Good morning,
I am going to write a web service and I am not sure which framework would suit the situation best. I understand what Node and .Net are good at.
The client will call the services at the following stages:
App loads up - user logins in via Facebook API.
User can create an "entity". This entity will be stored in a database (SQL for .Net/ Azure table for Node) and also posted to a Facebook application (timeline stuff). User can make changes to this at any time.
User can browse Facebook Friends (Facebook API again).
Changes to the entity will be pushed to all users who have "joined" the same entity (SignalR .net/Socket.io Node).
That is the skeleton of the web services, there may be more Facebook calls or CRUD operations. Which Framework will handle this best?
Many thanks.
Aside from the mentioned WebAPI, also consider the excellent ServiceStack for building a webservice.
Any well-written code regardless of the framework will be able to handle it.
If you are a .NET developer I personally think type safety of C# is important so I would not go down the Azure node.js way since it will also force me to use Azure.
I would personally use ASP.NET Web API.
As long as you build your application on a solid framework, you'll be on the bright side (assuming you know how to set-up such an application in a secure and proper manner). For .NET i'd use the Web API and for node.js i'd stick with something like express/connect.
Just keep in mind that node.js and the frameworks based on it are still subject to heavy changes, whereas ASP.NET is production-safe since years.
As a bottom line, i don't think you're able to say "X is better than Y because of Z" in this scenario. It's a matter of personal preferences, infrastructure and your technical skills.
Has anyone seen any good examples of how I can use MVC3 and TableStorage with Azure account validation. Everything I look at seems to still be ASP.net or just a very basic example. I am surprised the Windows Azure site doesn't include more MVC examples.
What exactly do you need and what do you mean by "Azure account validation"?
As for Storage - the Microsoft.WindowsAzure.StorageClient.dll is a single assembly with common wrapping types around the Storage API. There is nothing technology specific. You can use storage client in any .NET assembly (well, not in Silverlight directly). But all operations over Windows Azure Storage are performed the same way regardless of whether it is a ASP.NET application, or MVC site, or WPF application, or WinForms application. So you may take the Azure Storage related code in your MVC application and use it as is. You just need an MVC3 Web Role, which is a standard and available project template since Windows Azure SDK 1.5.
I got a lot of theoretical answers from Google that WCF is better than Web Service etc. etc. But I want to know from the programming and implementation point of view. I am very new to coding and want to know that how do we implement all three of these technologies? How are they different and in which scenario we should used which technologies?
Thank you in advance.
A web service is an API that is hosted for access via a network connection - often the internet - and usually accessed over HTTP (or HTTPS).
WCF is a Microsoft .NET development framework that can be used to implement web services. That is, WCF-services are a subset of all web-services.
Windows services are a separate beast entirely: they are long-running programs that run on your local Windows machine, typically with no user interaction and on system accounts. They are used to handle many things in Windows, from low-level driver functionality to software updates.
You're really comparing apples and oranges. A web service is simply a program that you can "call" using the HTTP protocol. Typically, HTTP requests sent to the service contain some XML describing the method called and any parameters. The response from the service likewise contains XML with the return value and any output parameters. It's a little more complicated than this, but it gives you the basic idea.
Windows Communication Foundation (WCF) is a framework for building network services. You can use this framework to build web services if you wish. I suspect that what's tripping you up are the various Visual Studio project templates. You have one for WCF services and one for web services. The web service template builds a web service that runs inside of IIS. The WCF template gives you far more flexibility (you can make a web service as a stand-alone application, for example), but it is far more complicated.
If you're just beginning, I'd start with web service template and IIS-based web services.
MSDN is always a good reference:
Web Service Tutorial:
http://msdn.microsoft.com/en-us/library/8wbhsy70%28VS.80%29.aspx
WCF Tutorial:
http://msdn.microsoft.com/en-us/library/ms734712.aspx
I think its always easier to learn by doing.
Good luck