I'm building a messaging application that needs to receive messages from the web. Originally I was going to run this application as a Windows service and have a web wrapper using ASP.NET MVC that could be accessed by clients to send messages to the application. But I am now learning about the Web API which is much better suited for this task but the question remains whether it makes more sense to include the base application as part of the Web API self-host framework or if I should leave it as a Windows service and wrap a Web API application around it.
Is there really a difference? Was the Web API designed to combine the concept of a service layer and a web interface into a single framework? I'm not sure how scalable/robust a self-hosted application can be compared to a Windows service. Will the Web API self-host method limit me in any way that the service method won't? What about a Web API application hosted inside IIS such that my base application will be running inside IIS? I'm not sure of the specifics of performance that I need (such as memory or CPU) at this point so would it be easier to start with IIS and then if needed, convert it into a self-hosted/windows service if the need be? I hope these questions make sense (although I'm not sure if they do).
I'm new to Web API so I'm just trying to wrap my head around these concepts.
Related
I have a WPF application that needs to send and fetch data to and from a web application. Web application is built using ruby on rails.
What's confusing me at the moment is does the WPF application need to have a web/wcf service on it's own to talk to the rails web application web service. If not how can i fetch and send data to and from the rails web application web service.
Please note that I have done some digging around google and here but am still confused since most of talk of creating a asp.net application first. A step by step best guess scenario/example would really be helpful.
I've got a stand alone WCF service providing REST services. As time goes on, I'm feeling like MS is going to reduce support for WCF and REST services, and I've already had to code in a bunch of hacks to get somethings working like CORS. Additionally, implementing https is another hack since it requires using OS functionality. (i.e. you have to install the certificate using an external application, which doesnt' make the service very self contained)
In anycase, I'm considering either a move to ASP.NET REST API and OWIN, or Java/Spring. I wanted to first see what it would take to move to ASP.NET REST, since I figured that should take the smallest amount of work, but I haven't found any good examples.
There's a pretty straightforward example on the asp.net site.
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
setup a self-contained project i.e console app or windows service
initialise and setup you routes
create your Controller / API stubs
deploy
Regarding SSL, whether it's IIS or Apache you will have to configure it on the web server regardless.
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.
Good old Microsoft documentation at it's finest. Does anyone know of any resources that explains how to deploy Web Api with Asp.net Web Forms application. I have the web api in a separate class library and I call using jquery. I don't want anonymous users to be able to access this service only the application. Do I want to use self hosted? How do I lock the service down? Awesome examples showing how to use, tons of videos but nothing on deployment.
You don't have the right architecture for what you are describing, but what you have is right.
If you are calling web services from the client side (using jquery) then your web service must be public facing.
What you are describing is a web or WCF service in a service oriented architecture. That service would most likely live on a different server and be on an internal network, etc. Even if it's on the same server your requirement is that it is not publicly accessible - thus none of your jquery would work since that request is being initiated by the user and users can only make requests to public facing services.
The comments about using forms authentication to protect your service calls are right. jQuery will include the forms authentication cookie for you when it makes AJAX calls so you shouldn't have to change much on the client side.
I have written a windows forms (.NET C#) application that encodes video and is essentially a GUI for ffmpeg.
The requirement has changed, and we now want to move the UI to a web page and have the encoding done as a windows service.
The following requirements also apply:
Two-way communication between browser's web page and service (i.e. start encoding using web interface and have service notify progress back to web page)
Service should be ported to Mac OS X too
UI should be a standard webpage (should consist of HTML/CSS/JavaScript/Flash etc...)
I was thinking of WCF for the windows service, but I have zero WCF experience.
Will WCF provide a good basis for 2 way communication between the web page and the service?
Also, I need to think about porting the service to Mac OS X, and I noticed that WCF is only partially implemented in Mono (see http://www.mono-project.com/WCF_Development).
Will this be an issue? Does anyone have any experience with WCF development in Mono?
What would be the best route to meeting the requirements above?
I would love to hear any suggestions...
EDIT
I should clarify - this is not a web application, it will run entirely on client side.
Service should run client side and interact with a webpage inside a browser (which is also client side).
If you want a UI in HTML – which is what a "UI to a web page" would mean to most – then WCF is the wrong approach. WCF is for creating highly interoperable (WS-* standards) clients and/or servers; not for web pages.
Better looking at ASP.NET MVC. This is a very different model to WinForms,1 but allows easy moving from from rendering a UI into HTML to generating XML or JSON for a Web API (behind AJAX from a Web UI or a native client).
As I understand it ASP.NET MVC is substantially supported on Mono; and this should become easier with much of ASP.NET being open source now.
See also this answer from yesterday.
1 WinForms would be less of a move, but it would then be harder to do the API side without another technology shift (albeit ASP.NET WebForms and MVC can be easily mixed in one Web App).