Using web.API with MVC seems very easy to setup, you leave the WebApiConfig.cs as default, create a new web.API controller, and then in your javascript you can call $http.get("api/...").
I want to be able to do the same using service stack instead of web.API. What makes it slightly more difficult is that the service stack api is in its own project. At the minute I can call the endpoints within MVC using the jsonServiceClient. However calling client side with Angular requires me to call the full FQDN which causes cross site scripting issues.
How can I configure my MVC project so that I can call my service stack endpoints from AngularJs's $http.get method like this:
$http.get("api/...")
rather than:
$http.get("http://localhost:2540/api/...")
You can accomplish this by creating an alias in IIS under your web project and naming it API and pointing to your ServiceStack project.
You may run into issues in the future with this if you need to scale out your solution, but as long as you don't need to do that, you should be ok.
Related
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 am creating a fresh ASP.NET MVC4 website using a proprietary API that tells me I need to include <trust level="Full" legacyCasModel="true"/> in my Web.config file. When I do this, however, the application exceptions out with the message "Dynamic operations can only be performed in homogenous AppDomain" I have poked around a bit and it seems that this has to do with some dynamic calls not being allowed.
My question is: Does that mean I have to abandon MVC altogether and make my site with Web Forms?
Perhaps you can move the code which calls the API to separate DLL, make your calls there and expose that DLL as a web service (or .NET Remoting or whatever works). Then, from your MVC web-app, call your new web service in order to reach the proprietary API.
Basically, wrap the API calls in a (local) web service call.
This approach would allow you to use MVC instead of WebForms. It does add some complexity and overhead, but I think the pros (ability to use MVC) outweigh the cons.
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 trying to learn wcf on practical example. I followed scalable wcf solution tutorial and my service works ok, client from my console app. works ok. But what I want to achive is consuming my service trough js from mvc view (razor) page. On my client console application I'm accessing to proxy with
IService proxy = new ChannelFactory<IService>(Configuration.MyServiceActiveEndpoint).CreateChannel();
List<MyObjectDto> data = proxy.GetMyData();
...
how to practicaly achive this creating proxy client from mvc view page (without adding service reference). Thank you
You don't do this.. you really really don't. This completely breaks the entire point of Model-View-Controller (MVC). The controller should be the one accessing the WCF service and returning the data to the View.
Check out servicestack.net for the cleanest and best web service implementation in .net. No config, easily callable from jQuery, and returns json by default. Easy to get started with NuGet Mvc 3 package.
The tutorial you are using already registers an endpoint with the enableWebScript behavior - you should get a js proxy generated automatically when you access http://server/virtualdirectory/X.svc/json url. Include that js file in your mvc view.
If you host the wcf service in the MVC web app you can use Url.Content:
<script src="#Url.Content("~/X.svc/json")" type="text/javascript"></script>
Then just invoke the service from js - use the javascript from this post as an example: http://dotnetslackers.com/articles/ajax/JSON-EnabledWCFServicesInASPNET35.aspx
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.