I really stucked in MVC + Angular 2 project in the first Step. The problem is, How to connect controllers and actions with Angular 2? Is there any routing needed?
I have done with all setups with Visual Studio 2015 to work with Angular 2. And it successfully works. But i really doing my projects in ASP.NET MVC 5 (Not ASP.NET Core). Here i dont know how the Controllers and Actions work with Angular. How can i route (navigate) to several controllers and actions in my project.
Since MVC consists of several controllers and actions. There will be many views for several actions and for every action there will be a GET(View) and POST(Form Submit) method also.
If anyone work with Angular 2 + ASP.NET MVC let me know how the Controllers and Actions are getting connected.
It looks like you are building your first SPA that communicates with a REST API.
For starters, you should get two things straight:
The ASP.NET MVC is your REST API. It will expose endpoints that can be requested via HTTP calls.
Your Angular 2 is the SPA (Single Page Application), which will make HTTP calls to the REST API you wrote in ASP.NET, and that API will give back responses of whatever you want. You can then use that response data to your liking in your Angular 2 frontend.
That being said, the first step you want to do is make sure you can properly access your API endpoints. Download a tool called Postman and test this with ease.
Ideally, you want to make this API a JSON API, because that will be the easiest thing to work with for your frontend. Plus, it's basically the de facto standard. But as always, use what works best for your use case.
Once your endpoints are working as intended, what you need to do is make some AJAX calls in your frontend that will hit those server endpoints. For Angular 2, you can use the Http package.
You will undoubtedly come across a CORS (Cross Origin Request Sharing) browser error when making the calls to your server. This is basically the browser refusing to send requests to your server until your server explicitly says you are allowed to make requests to it, assuming you are not on the same host and port.
The above was a really brief and limited-detail breakdown of what you need to do. For an example of putting it all together, check out my Angular 2/Golang chat room app. As you will see from this file, I expose some endpoints to allow create/read/update/delete actions for Todo's in my Go server. And the Angular 2 code is in this directory.
One last tip: If you are serving your front end files and exposing your API endpoints all on the same ASP.NET server, as opposed to having one ASP.NET server for the REST API, and one for the serving of UI files, then two things are true:
You need to have a catchall route in the server that will serve your index.html. You can see an example of this in this file. You'll notice a long that starts with r.NoRoute...that is where I say "no route was found so far, therefore serve index.html and let the Angular 2 handle the routing from there".
You no longer need to worry about CORS errors
Hope that helps!
Not actually, you will create and Expose APIs (WEB API) in your MVC project and your Angular 2 will consume those APIs.
Related
I have a web api returning json and I have Mvc website consuming that web api. I want to make api calls on the clientside using Jquery, not in the mvc controllers on the serverside. Therefore I don't want to publish them as 2 different application with 2 different domains as it will cause cross site scripting.
ex. mywebsite.com for mvc webapp
mywebsite.com/api for web api
Ok I figured out how to run them under same domain as explained nicely here
But I believe all of these solutions requires deploying the webservice and web api separatly even they run under the same domain?
I want to publish only mvc webapp and api should be published together with it. is it possible?
for example something like "nopcommerce" project is doing with Nop.Web and Nop.Admin? When publishin Nop.web also includes nop.admin and nop.admin is reacheable with the url like nopcommerce.com/admin
or must it be on the same server as the app calling it? I am new to web api so i am going through some tutorials, but they all assume the web api is part of the mvc app. Also, they show the calls to the api being done with javascript, but I want to make the calls in my MVC app controller. Is this possible?
You can host a Web API anywhere.
The only special thing to have into account when the Web API isn't in the same server that a web site that uses it, is that, by default, the Web API doesn't accept requests from a different domain. For example, if the web site is in "server1.com" and the Web API in "server2.com", then the calls to the Web API from the web server will be rejected.
If this is the case, you need to configure the Web API server to enable CORS (cross origin resource sharing), so that it accepts requests from a different domain. If you want more info about this, please look at this document:
Enabling Cross-Origin Requests in ASP.NET Web API 2
The Web Api can live wherever you want it to. Is typical to see a limited API used mostly to handle AJAX for the MVC application live with the MVC application, mostly because it makes it simpler to construct URLs to the endpoints. If you host the Web Api externally, then you'll have to hardcode the API endpoint URLs, as there's no way to use something like Url.Action to generate them automatically, any more. Regardless, it's a perfectly acceptable way to handle things.
You will probably at least want to add the base URL for the Web Api as an app setting in your Web.config, though. That way, you don't end up with hardcoded references to a particular domain strewn all about your app. That makes moving your Web Api to a different domain much easier, especially when talking about going from development to production.
It is also entirely possible to use a Web Api within your actual controller actions. You'll just need to use something like HttpClient to connect to it and issue requests.
I am developing an MVC5 application and use Entity Framewerok 6 code first on this. Now we we will also develop an android application that will interact with the MVC application (CRUD operations) by using the web services. At this stage I want to be clarified about the issues below:
1) I think WebAPI is better option for us as we use the services on android apps. What do you suggest?
2) In order to integrate WebAPI to an MVC project, which changes should be made? On the other hand, can we use the same controller and data layer methods (i.e. SaveChanges, etc.) by making some modifications i.e. inheritance? Or do we have to create a seperate methods for web services? Could you give an example by code?
3) Does integrating WebAPI to the MVC project affect the MVC project's abilities or methods? I mean that is there any disadvantage integrating WebAPI to an MVC project?
Any help would be appreciated.
1) That's a good idea. Web API is easy to implement and consume
2) You don't need to make changes to intergate Web API in your application: just start using it. As you want to expose CRUD operations from EF a good idea would be to implement ODATA services. Or use something like Breeze (depending on how you want to consume the services). See "MVC and Web API" bwelow
3) Web API doesn't affect at all the MVC part, unless you make a mistake setting the routes. Although they run in the same host, they work completely independent of each other.
MVC and Web API
Unless you need to do something special, like exposing Web API in a different URL or "domain name", MVC and Web API are implemented in the same web application project. To start using Web API in your MVC project simply add a new controller. Perhaps you'll have to include also the WEB API route configuration, and some other Web API configuration.
If you want to expose the EF model throug Web API you simply have to follow the instructions in the link to create an ODATA controller, which will expose the EF model as a RESTful service, allowing you to execute the CRUD operations to the EF model through URLs.
NOTE: What you want to do is a very frequesnt pattern in MVC applications: MVC is used for generating the views, and Web API fos exposing functionalities that can be easily consumed from the views usin Javascript + AJAX. Don't be afraid to use it. You'll find no problems at all
I have a rather complex solution which I implemented using ASP Web API, among others. I have 3 projects in my solution worth mentinoing right now. One is a WebAPI containing only api methods. Other two are are the backend and frontend for my application. The backend uses a SPA approach loading mostly empty shells for views and filling everything with ajax acessing the API. The frontend on the other hand because of SEO concerns was decided to be implemented by more traditional means, aka most stuff is rendered server side. My question is, is it possible and good practice to simply call the web api methods from the frontend controlllers and send the results to the view? I don't see a point in duplicating most code in the regular controllers since it's all done with the api.
Any samples on this? I've been searching but couldn't find much.
If you need to call Web API service from C# code (MVC controllers or elsewhere), HttpClient or WebClient can be used to call the services over HTTP.
If you need to simply reuse code, it should be abstracted into a class library (DLL) and referenced from the Web API and MVC projects.
I've run into this same situation and have used the Web API controllers from MVC controllers for a little while at least. You can do this simply by creating new objects of the Web API controllers then calling the appropriate methods off of them. I found this method works fine initially but creates the dependency that means your Web API can't change without also changing the MVC controllers as well.
My advice is to put as much functionality on your models that makes sense with partial classes, and if that is still inadequate then create another logic tier that contains all the shared business logic. You should not have duplicated logic in your MVC and Web API controllers, they should just serve as the glue to get the data served.
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.