It's more a structural question than a technical one.
I made a classical Web App with ASP.NET MVC.
I works well, the server responds with HTML when I send him an URL. Ok.
I now want to make a mobile application (Android) to access the same data.
Maybe there is a way to use the controller's methods which already return the objects I'll need.
So the question:
Is there a simple way to make a REST API from a ASP.NET MVC WebAPP?
Once again, I think that the controller's method will be pretty much the same. It just has to not return HTML but XML for instance.
I'm a newbie in the Web services technologies.
Add webapi project to your solution
Configure web api controllers
Reuse MVVC classes to access database
Return necessary data - webapi will return it in json and in xml (depends how client will consume it)
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.
How does MVC and web API work together in an application?
Are you supposed to use javascript binding (with knockout.js and ajax calls) and just use MVC for the actual container page?
Or do you call web API from the MVC controller (like a WCF service layer)?
The integration of MVC and web API just isn't clear to me.
Should I use Web API if I regulary require HTML to be returned (i.e. I want to work with Partials)?
I'd like to use web API so I can scale my app though (return HTML from one side, but remain with an API that can return/process XML)!
Thanks for clearing it up :)
This picture below from the link explains clearly how MVC and Web Api work together:
Technically, you can call from MVC to Web API, but it is not really the best practice since:
Calling from MVC to Web API will across the network (distribution), this makes your application more complex.
Web Api is REST Api, it is not like WCF which is heavily SOAP Api (although WCF support REST Api). So, from JavaScript you can call the Web Api easier using ajax.
Here's how I set up my latest MVC and Web API application: There's the regular model layer (*M*VC) and I have created a service layer for the business rules. The controllers of my MVC application call the service layer to process data from and to the views.
My Web API application is a external interface to the methods on the service layer, therefore both the controllers on the MVC application and on the Web API application call the service layer. I hope this helps.
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 am quite familiar with ASP.NET MVC and know that a controller’s method can respond with XML and JSON apart from other things (i.e. behave like a restful webservice). I am just wondering whether I can make a controller method behave like a soap web service which responds with a SOAP XML response to a POST request? Maybe it is just question of responding with XML but this would be more like a restful web service. I want to avoid having to implement a separate web service project if possible. Any feedback would be very much appreciated. Thanks.
Christian
You don't need to implement a separate web service project. All you need is to add a WCF service endpoint (.svc file) to your current web project. Also you are saying that you expect SOAP response after a GET request which of course doesn't make much sense because in the SOAP specification requests should be POST.
I believe your thought is to create a single deployable MVC Web Application that can respond to both SOAP requests and RESTful requests (maybe even more?). I have thought about this myself, however there is no point in re-inventing WCF as it can do both without any additional programming. The ASP.Net MVC assemblies were not designed to function as a web service, and although it can, probably shouldn't be when other technologies exist that were designed specifically for that purpose.
I want to expose a service on my site that any users can call and get a JSON response. In the end, I want the users to be using this service as much as possible.
My site is created using the asp.net MVC framework and i was wondering whats the best way to do this...
I think most would say it's obvious to use a web service (*.asmx) that returns JSON format, but i know that I can just create a url that users can call and have it return JSON format as well (e.g: calling "http://mysite.com/GetList" would return JSON list). In asp.net, using the return Json() method.
What are the advantages/disadvantages doing it this way vs. a Web Service which is specifically intended for this ?
I don't know that most would say use a .asmx web service. Personally I haven't made a .asmx web service in a while and I would go for the MVC approach. The only things I'd be worried about would be:
future changes to the data, url, and/or parameters passed in.
Making the controller too big or cluttered, in which case you could create a separate API controller.
To me the advantages are that it's more consistent with the rest of your app, it's simple and easy to work with, and there's not much to configure.
A web service would expose a WSDL.