I am new to asp.net mvc world. So I have a question
I have already developed a web app using Asp.net MVC (also deployed on production).
Currently I am working on mobile apps. For this I need web services (restful).
For Restful web services do I have to make a new project (within existing solution) or can I incorporate Restful webservices into my existing (Asp.net MVC) project ? (I prefer 2nd option if possible)
If I have to make new project for Web Api, then how will I deploy both projects on production knowing that Web Api project is dependent on Asp.net-MVC project ?
One thing you need to understand first is whether it's a web service,wcf service or a Web API the only thing you need is to get a json/xml output which you can use in your mobile app.
Let say you have and asp.net mvc application which has some action methods, but you might be returning a View or PartialView which is not you want for a mobile app to parse. So you need to create an action method which returns JsonResult.
If you want to use all the RESTFul verbs like POST,PUT,GET,DELETE you can add another controller which inherits from APIController and write methods there, but either ways output is same.
So it's up to you what to do and how to proceed, only thing is with an APIController you will have some more verbs and code ahve some special returns like "Ok" e.t.c
Related
First time when I created Web API project(MVC pattern) and I created few API controllers and called from html page(Ajax call),I am able to call all APIs and get the data.
But second time I've created two separate solutions one is asp.net Web API and another is MVC Web application.
Now I'm running both the projects in my machine and trying to call web APIs from MVC application, it's coming 405 method not allowed client side error.
Can anyone help me with this scenario.
Anything extra I need to configure in my server Web API to be called from different application?
I currently have an Aurelia single page application I'm developing in WebStorm, and a backing Web API I'm developing in Visual Studio. In the dev environment, everything works fine, I just host my client application using WebStorm's server and point it towards my local web api url.
When I deploy the application, I need a way to initiate my client, however. Is it common practice to have my Web API's default route return my index.html page? For some reason it seems very strange to me. Is there a better way to first serve up my index.html? I haven't been able to find much online regarding the subject.
Thanks for any guidance.
What I've done in several projects is to build a single MVC + WebApi project.
This way you will be able to serve both the MVC part for your "index.html" and the WebApi for all your API needs.
So the MVC part is basically just a DefaultController with a Index method that returns the View that initializes my SPA.
In other words, the View for the Index method returns the content you normally would have put in your index.html file.
I have a client dashboard application, written in ASP.Net MVC 4 (not bound to this version, happy to upgrade). The website is hosted in Windows Azure.
Our clients would like to programmatically access this dashboard, via an API.
Affectively they would like to be able to perform all of the same functions which they normally carry out on the dashboard website, programmatically from code using an HTTP Restful Service.
....My instant reaction was to simply build an ASP.net Web API project, and separate out the shared services/libraries/components from the existing MVC project so that both the API and the MVC website can call the same code base.
Questions
Is it possible to simply create Web API controllers within my existing MVC website project, and expose them over HTTP?
If it is not possible to do "1.", will Azure play nicely if I have an MVC solution, a separate Web API solution, and a shared library project of common services and models? How will I ensure that Azure copies the shared library components into the cloud when I deploy the MVC solution and the Web API solution separately?
Update
Based on the comments, the following implementation of two separate controllers (the original MVC controller within the MVC project, and an additional Web API controller within the same project), does in fact work. Please note that based on the following LINKED ARTICLE, the below implementation would be a "pre-MVC 6" implementation. MVC 6 itself provides the ability to implement both API calls and normally MVC View calls, into a single controller (as opposed to separate controllers that inherit from different base classes).
public class ProductsController : Controller
{
//Products/Index
public ActionResult Index()
{
return View();
}
}
public class ProductsAPIController : ApiController
{
// GET api/productsapi/getall
public IEnumerable<string> GetAll()
{
return new string[] { "value1", "value2" };
}
}
To be fair - MVC or WebAPI, as far as your consuming clients are concerned, it shouldn't matter.
Both MVC and WebAPI can create JSON or XML outputs - it's just one makes it a bit easier (WebAPI serializes the relevant response based on the client).
But you can quite easily mix the two together, as others have said, it's as simple as Add New Item
The newest version of MVC (6) has now integrated both technologies into one solution. http://www.asp.net/vnext/overview/aspnet-vnext/create-a-web-api-with-mvc-6
This would be ideally what you are looking for if you can start a new project.
Question 1: Yes it is, just take a look at the article above.
Question 2:
Azure will be fine if you have a MVC solution and also a WebApi solution, but I think you will need to run them under different websites (I'm not 100% on this).
Yes it will work fine. The only potential gotcha is you have to clearly separate your WebAPI routes from your MVC routes (like, for instance having all WebAPI routes under a /api/... prefix, this is the default).
If you do decide to do two separate projects for whatever reason and want to have a shared library, the best solution is to keep that library in a NuGet package on a private feed. TeamCity supports this out of the box, along with other nice features (continuous integration/deployment).
I am developing a new large Web Application using ASP.NET Web API. In that, I want to separate all controller classes into one different class library from ASP.NET MVC project.. Please consider following options.
Case 1 : Keeping controllers in same ASP.NET MVC project
Case 2 : Separating controllers in separate class library
Is it right to go with Case#1 as I think this controller can be reusable by other projects or hosting in windows service instead of IIS Web Application.
Also if in future if I want to access Web-API methods from Android,IPhone native apps then does it works for me in both cases Case#1 and Case#2
Is there any performance issue with Case#2.
What would be the best practice to register multiple controllers in both cases using UnityContainer.RegisterType ?
Putting your Web API code in a different project than your MVC code should be a best practice. There is no reason not to do it.
I'm about to start a new project in ASP.NET MVC5, which has a bit of Web API too. I'll also need a Windows Forms client which will call the API. This client has a file system watcher that detects when a file has been changed, and will post the contents to the API.
When the API receives the data, it does some calculations, and ideally will send the results through SignalR to the browser and update the display.
I'm getting rather stuck trying to work out the authentication. I want to use Individual User Accounts, so the user can log in with the Windows Forms client (and get a token) and in the browser to view the data.
I've got as far as File -> New -> Project, and tried an MVC project with the Web API box checked, and a Web API with the MVC box checked. Looking at the two AccountController classes that these generate, they seem quite different.
I guess the options are
Try to get these two controllers working together
Call the MVC controller from the Windows Forms client
Have two projects in the solution and try to work out how to use SignalR to talk between them.
A better way?
I suspect the last one. I've not used Web API before, so I could be doing this all wrong. What approach should I take?
I would say, create 2 different projects, 1 for MVC 1 for API.
Use 1 BLL which is referenced in both of them and carries the logic for both of them and will not be dealing with separate controllers.
Of course if you need other layers like DataAccess or Repository, you have to create them once and they will be referenced in the BLL which is later referenced in both MVC and API interfaces.