I'm looking at putting together a REST based system which still has a standard browser style access. My desire is to have both of these on the same machine, but what are my options?
Use IIS to host both the web-site and the REST service (different URIs, e.g. http://mysite.com/ and http://mysite.com/api
Use IIS and some magic I don't yet know to have two domains mapped to the same machine but different services (e.g. http://www.mysite.com and http://api.mysite.com
Combine the two technologies into a single service (that perhaps uses routing tables to direct the requests to MVC or WCF where appropriate).
My preference would be the third option, this would allow me to have a single code-base and single repository accessing. The WCF page on codeplex mentions in its release notes, "not tested with MVC3" - is this suggesting that this is a possible approach?
I'm not keen on using MVC for the REST implementation as it is intended that the majority of interaction with my site goes via API, so I want that as the focus.
I've ported the contact manager to use MVC 3. It definiately works though we've not done exhaustive testing. The one thing in general to cognizant of with regards to web api is that both MVC Routes and Service Route are greedy. If your default route is first then MVC will try to grab your HTTP Service requests. One thing you will want to do is put your Service Route first before your MVC routes. If you run into additional issues, you may need to use custom routing constraints.
In http://webapicontrib.codeplex.com there is a sample that works with MVC 3. It is in the Samples/experimental folder. However, it was built with a custom version of WCF Web API. I don't believe it needs to be though. I've been meaning to get the author of the sample to switch it over.
Related
I am quite perplexed over the use of Web Api in a MVC application being developed at my company.I recently joined the project and wondering why they are using this.The application uses JQuery AJAX functionality to pull data for each Tab in a MultiTab Page without refreshing it.
The application here is neither providing data service nor consuming any Web API service.This can be easily achieved without using REST verbs.It is directly connecting to database like a typical web application.
I am holding back myself to raise this question with the team since I haven't used Web API much but has a conceptual idea.
Am I missing something here ?
Microsoft's Web API MVC technology is typically used for external components to interact with the system - not generally a requirement for a standard MVC Web Application.
With that said, I'm not perfectly clear on the architecture. A few points of note:
jQuery AJAX is a perfectly valid (and usually preferred) method to retrieve information for tab pages - it provides a SPA (Single Page Application) "feel" to the site and generally improves performance all around. This does not mean that they're using a Web API
MVC is a framework used for many web applications, including Microsoft's Web API projects as well as ASP.NET MVC Web projects. The use of MVC doesn't mean that they're using a Web API.
A RESTful approach isn't just for Web APIs. Indeed, many find it a cleaner approach when using regular MVC Web Applications, as it tends to be more semantic to what actions are actually being performed (GET to get a view, POST to post data, DELETE, etc.) There's no real reason not to use REST verbs (which are actually just HTTP verbs, but called "REST" when we use them in a certain way). The use of HTTP verbs doesn't mean that we're using a Web API.
To conclude, The MVC Web API framework is it's own technology that's similar to MVC Web Applications, but more geared towards working with non-visual requests and responses, instead tailored to programmatic interfacing.
If this is indeed a Web API being used and not a case of MVC practices that you happen to be unfamiliar with, then yes, I think it's a good question to raise (at least from a technical standpoint - politically, maybe not, but we can't answer that for you).
A typical setup is to have multiple projects, one of which is a Web Application, which makes use of shared project(s) for domain/business classes and data persistence. Additionally, a Web API project is often used to provide access to the system for external components, but this is a separate "presentation layer" project from the aforementioned Web Application.
There may be cases where a Web API application is written as the core interface between the internal system and the rest of the outside world, where the MVC Web Application then interacts with the Web API, but this is a corner case that should only be done with specific reason, in my opinion (unless I misread, this seems to be the case you're stating?)
Using both MVC and WebAPI together in a ASP.NET Web application is quite common. Whilst you can provide HTML through WebAPI and you can provide JSON through MVC it's much cleaner to use the best technology for each.
WebAPI in particular lets you define an API once and then generates JSON, XML, ... for you based on the request.
I've a web site developed using MVC 4 ASP.net application. I'm new to .net platform & I want to add web service which would return me operating system name of users device based on certain input.
Assuming I've logic to capture OS information using inputted data, how do I go forward in building this web service?
Do I need to have a complete separate solution file which will have a web service or in existing MVC 4 asp.net application itself, should I create a new project which would be of type "WCF Service Application"? Again I don't know much about WCF service either, if I use it, how would the URL be accessible, etc?
Can anyone give me some insights?
Note: I've also a separate REST web service which is a completely separate solution with separate projects but deployed on same IIS.
Thanks in Advance!
You don't need to create a WebAPI project just for what you described (i'm assuming one or a few end points).
Simply use MVC controllers that return JSON for example, this way you deal with a single framework.
Reasons to move to Web API is if you need support for CORS, need content negotiation for results etc. From what you are describing it's completely fine to stay with MVC.
I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:
MyApp.Core - the app core, contains the domain models etc.
MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.
MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)
MyApp.Web.Infrastructure - web implementation
MyApp.Web.UI - ASP.NET MVC standard application.
This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.
When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.
I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
- Why should someone not just use the Services in the controllers and instead use an API?
- In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
- If I should use WCF, or ASP.NET WebAPI?
Thanks for any feedback and help!
First, regarding your projects, is there a need to split up MyApp.Web.Core, MyApp.Web.Infrastructure and MyApp.Web.UI? Sure they may be separate responsibilities, but sometimes dependency hygiene trumps encapsulation. You can always leave them in separate folders and namespaces. I wouldn't extract something into a separate project unless I needed to reference that as a library from elsewhere.
As far as the application service, that also depends on your needs. If the only place that would call that application service is the ASP.NET MVC app, then there isn't much of a need to extract an application service. There are some benefits however. One is that you don't have to worry about all of the dependencies required for a service - you just references it via Url. And of course you have the ability to call the service from places other than the controller, although the MVC controller can act as a pure HTTP service as well. You also have the ability to deploy updates to a specific service without releasing the MVC app. But you do have the burden of maintaining a separate service. If you do go that route, go with the WebAPI, WCF is just too much abstraction.
I'm wondering if it's possible to service up WCF services via MVC. I've seen a few posts about this as it relates to RESTful services, but I'm not looking to create a RESTful service.
I've also seen this topic covered as far as serving up .svc files from MVC, but I'm not looking for that either.
Basically, I'm just looking to expose my WCF services via MVC, instead of a typical Wep App type structure with svc files.
so instead of having ttp://localhost/MyService.svc, I would just have ttp://localhost/MyService and that would go to a controller that would return the data.
Is it possible to have a "servicehost" controller? I would assume that the biggest obstacle to this would be that IIS handles the service a certain way based on the .svc extension - would some kind of custom handler have to be set up for something like this?
Any thoughts?
You can do this without MVC (or, it seems, with it too)
http://geekswithblogs.net/michelotti/archive/2010/08/21/restful-wcf-services-with-no-svc-file-and-no-config.aspx
http://geekswithblogs.net/michelotti/archive/2010/09/22/wcf-rest-services-inside-mvc-projects.aspx
I would appreciate if someone can provide some insight into which one is more beneficial.
RESTful service in WCF can provide the same functionaly as ASP.Net MVC Controller, i.e URLS can be formed appropriately using Controller/Action.
Is there real benefit of using one over the other.
WCF Rest service will provide..
1) Cert Authentication out of the box
2) Logging
3) Message Headers etc
MVC
1) Different Action Results out of the box
If someone has used or debated these two technologies . please let me know
UPDATE:
I went ahead with the MVC Model as it gives me lot of flexibility and I can use the same action to render different views with CustomActionInvoker, which is really cool!!!
-RN
WCF makes your service more manageable and offers more protocol options like TCP, Named Pipes, PerChannel, and MSMQ.
WCF gives you the ability to specify multiple methods of binding to the service through the web.config including restful urls, giving you greater flexibility. In conrast, mvc provides you with the ability to easily construct resful urls and output data via code in much the same way as you do a web application, which is really easy and requires minimal additional knowledge if you already know mvc.
My recommendation would be to go with wcf if the service is really important to the overall solution, likely to be called in a different or many ways or has or is likely to have special security requirements.
On the other hand I would go mvc if this is meant to be a quick and simple isolated solution or perhaps is just providing a different representation of data being output in an existing .net mvc application.
At this point in time, your best option is ASP.NET MVC. It provides cleaner access to the HTTP primitives you need to be able to design RESTful solutions.
The only significant advantages of WCF Rest is the ability to self-host the service and if you want to use ADO.NET Data Services to deliver OData/Atom services, then obviously WCF is your best choice.