Is it possible to use a self hosted signalR server with an MVC(4) application such that it is totally seperate from the signalR server?
I tried Tim and Patrick's beautifully executed SignalR intro tutorial, and was wondering if I could try that? And even if I could, would that offer any performance advantages over an integrated service as is metioned in the tutorial.
It is absolutely possible to self-host a SignalR 2.0 server with OWIN and accessing this server from within any Website (which may be a MVC application). The only thing you need is to enable CORS (app.UseCors(CorsOptions.AllowAll); in your Startup file of the Owin Host) since it's not on the same domain as your Website. Obviously you can't use SignalR within the MVC application itself this way (e.g. to publish messages).
I'm using a self-hosted ASP.NET Web API 2 and SignalR 2 server with OWIN to serve data to clients. You can find an example server using this scenario here. Tho advantage in this approach is to have your views & styles sepparated from your data and business logic. Making everything very easy to cache and scale.
Related
I'm self hosting web api using owin on client-server application based on MVC architecture. I see a lot of code examples that shows that the Startup class with the configuration, and the Program class with the Main method that start the owin self host "using (WebApp.Start(url: baseAddress))" - are at the same project. Should I desperate owin self host to one project so the WebApp.Start will be in one project, and web api with Startup claas to another one, with all the controllers and so?
The common answer is that it depends. Usually self host applications is very simple to provide some simple functionality. In that case since both parts are simple there is no need to separate them (host code and Asp.Net Mvc) and they can be placed in one project as an application layer. But if you are trying to add some complexity to host code (e.g. some warm up of Asp.Net Mvc app), then may be you should split your host code and Asp.Net Mvc app code in to two projects.
Found that it might be good idea inspired by separation of concerns: the self host should not know about the server and the opposite. Owin and web api have different job so they need to be separated.
We are starting a project which will consist in:
Web project (ASP.NET MVC)
IOS app
and both will consume data from a .NET WEB API service.
The WEB API service will expose a POST Method with the url "user/create". But i don't know how can i avoid another apps for making post to this url? I know i need a security protocol, but i wanted to know which one you recommend me, and if you have, an article where is it explained.
Thanks
web api 2 provides oauth authentication. You will need to get a token from the token end point of web api and pass that token in subsequent requests.
You should find lot of online resources if you search for web api 2 oauth.
We did something similar recently using OWIN OAuth 2.0 Authorization Server
Reference this ASP.NET page for details. Sample code is included as well for several different implementations.
For our purposes, we used the Client Credentials Grant section about half-way down the page. Our implementation involved server-server OAuth (Web API to MVC), but I bet it's pretty similar to have iOS connect. The only thing I would caution is to somehow encrypt the login credentials on the iOS side, and I'm sure there is a way to do that.
So you want the WebAPI to only be used by the MVC page? The best architectural method is to separate the two rather than leave both in one project. Why? Because the MVC app is a experience layer for humans. The WebAPI is an experience layer for the MVC app. Move it back where it can't be accessed.
You can add on tokens, etc, but the MVC app sits on the server, but is accessed on the client computer. The wider the scope of the application (ie, intranet or internet or something in between?), the more difficult the problem and the harder it is for your users to access the application. Moving the WebAPI internal and leaving the MVC app exposed guarantees external users cannot use the API.
The main reason WebAPI and MVC exist together in a single project (still a mistake in most instances, IMO) is you are exposing both to the same audience. If that is not your intent, don't do it.
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.
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.