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.
Related
I have an MVC application that uses MVC Controllers to return views. Now I want to expose an API to other applications to consume, as well as returning JSON data types for some SPA features in the same MVC. What are the differences between adding Web API Controllers to my MVC Project vs adding a whole new Web API Project?
returning JSON data types for some SPA features in the same MVC
For that case, I'll place Web API inside existing MVC. By doing so, you can share business logic, services and even models.
In my case, I have SPA silos using AngularJS, and both MVC and Web API live happily in the same web application, and share business logic and data access layers.
It is worth noting that you can share Authentication cookie if you keep MVC and Web API together. Otherwise, it is pain in the neck to authenticate in both places at the same time, because Web API is token based and MVC is cookie based by default.
FYI: In new ASP.Net MVC 5, there won't be separate MVC and Web API anymore.
The only difference between the two is reusability and good design practice. I highly recommend to use it in a separate project. Then, later on, you will be able to reuse it without much or any effort.
Another advantage to segregate is the impact on testing required for any changes made. If you keep the projects different then if later on you change anything, the domain for the re-testing efforts would also be just the second project.
For a new SPA Web App which will initially have very little user interaction and incrementally will have new features which will require lot of user interaction. This app is targeted for mobile devices. I am using this weird combination of technologies.
AngularJS + jQuery Mobile - for Client Side - MVC framework + SPA framework.
ASP.NET MVC - Server side MVC Framework - which seems unnecessary.
WCF REST Services (from 3rd party) - Do not have any control here, just consuming it. These services returns JSON data. All business logic resides here. Application do not have any feature outside of this.
Once application loaded at client side all service calls will happen from AngularJS to REST Services.
The main role of ASP.NET MVC, is just initial request load only. Even user session is handled between AngularJS and REST services.
But I foreseen eventually application will be complex to handle all the stuff at client side. So looking to push some complex processing which is easy and efficient to get done using ASP.NET MVC and .NET Sandbox. I cannot ask REST Service to do this because as i mentioned it is 3rd party.
In dilemma,
1. Should i maintain user session on server side as well?
2. How can i utilize ASP.NET MVC best possible way?
Thanks for any suggestions.
Your dilemma is justified and valid. When I go with angularJs, my big question is , do i need to csthml file or shall i use the html file.
I always go with cshtml, hoping that in future there may be scenario where i may have to leverage the server side capabilities of the mvc.
Currently I am working on the same combination of technologies stated above and with modularity of arranging js codes(angular controllers) i don't see any issues. I am bit curious on what complexities you would be adding to the contoller as you have stated that all your business logic is done by the third partly controller.
If you are looking for security aspect, I would suggest you to write a custom actionfilter which uses httpmodule to do the custom security handling.
With MVC , sessions should be a BIG NO . At lease in my organisation it so.
I'm developing an ASP.NET MVC 3 application. I need this application to make use of an API I also need to implement. The API should both be available from ASP.NET MVC controller actions and Ajax. Now it is quite easy to make an API using ASP.NET MVC, but is it possible to use this from other ASP.NET MVC website actions? I guess the WCF is quite easy to use as it is just a service reference.
Other users of the API could be Windows Phone and iPhone.
Update:
Many only sees the API as a place where you consume data, but what about the part where you want to execute commands or do stuff, like add customer or change foo?
You may want to check our new WCF web API that was announced at PDC. We recently released a big upgrade. WCF Web API is designed specifically for allowing you to expose APIs to a range of clients in a pure HTTP manner. It is lightweight, offers a nice configuration story (no configuration files) and also is much easier to test.
You can download the bits at wcf.codeplex.com. It includes various samples, and there is also a set of NuGet packs for getting you started. Search for webapi.all on NuGet.
The way I like to do this is with RESTful controller actions. You can return JSON and use your calls with JavaScript on your own site. Other websites would almost certainly understand JSON and so they'd be able to consume your API pretty easily. This is much easier to write and test than a heavy WCF layer.
Check out this question for some example REST frameworks for MVC:
ASP.NET MVC REST frameworks
One of the newer ways of accomplishing data feeds is using OData. Scott Hanselman has a great introduction to it in Creating an OData API for StackOverflow including XML and JSON in 30 minutes.
It allows you to even throw LINQ queries into your URLs to retrieve exactly the data you need.
Open Data Protocol (Official site)
Open Data Protocol (MSDN, Microsoft)
WCF JSON binding was really terrible last time I used it. WCF also comes with all sorts of crazy rules about streams and how you have to use [MessageBody] attributes for everything.
It was a real PITA to me.
I knew I've answered something like this before:
What is the best way to implement a RESTful architecture in .NET today?
I'm developing a web app. This is more of a line-of-business app rather than a web site. I'm using ASP.NET MVC, SQL Server 2008, and I've purchased LLBLGen. I need to provide an some sort of API to third parties. For instance, if this was a medical app, third parties might need to CRUD patients, retrieve complex reports, engage certain kinds of workflows, etc.
What is the best way to do this with MVC without going to the architecture astronaut route. Do I need a whole "web service" type layer or can I re-use my controllers in MVC? Does it make sense to have this kind of API exposed through MVC? Optimally, I need a solution that involves the least amount of code repitition. I've found some stuff on doing REST with MVC but some of it is rather ambiguous and I'm not sure if it makes sense. I need a reasonable API but I'm not required to follow all the tenets of the REST religion or anything like that. I just need some sort of API in addition to providing the HTML front-end to the site, be it REST, SOAP, whatever.
Also, what are some options for dealing with URLs? Not everything in the app maps to something like site/products/product-id. Some of it involves engaging complex workflows, etc.
If you're going to have a web site and a web service then I would consider separating the data access and entities layers out from the MVC.
That way, your web service can do the same things that your website can. I would have a service layer that they both interact with. After which point the calls then go to the database and return the objects, and neither the web service nor the website should be able to interact with this layer.
This concept is also known as Separation of Concerns.
You can't/shouldn't reuse your MVC controllers in your web service. If they're so alike that they're indistinguishable, then consider writing your website to be a client of the web service, rather than being part of the same solution.
A Guide to Designing and Building RESTful Web Services with WCF 3.5, this article explains the foundations of REST and how it relates to WCF. MVC uses REST as the architectural model. I am guessing one can use the .NET MVC to create web applications that have both a front end and an API point, but I am not sure if the safe way of building the API is to build it with WCF and then use it in the MVC as a controller.
Please comment if the question is not clear, I will add or modify the text.
Theres actually a third option, ADO.NET Data Servies. Anyway, here how I see them.
MVC REST: Gives you full control over how to expose your data, you have to write all the code to get it up an running tho, e.g. serialization, deserialization, all the CRUD methods etc etc. Worht metioning that this being an MVC site means you are limited to exposing your service via IIS over HTTP(S)
WCF REST: More automation than MVC, a much more solid frameowkr than MVC REST, i.e. caching, security, error handling etc (basically all the stff you'd have to write yourself using plain MVC). Being WCF, you can host this in a variety of ways (e.g WS-, TCP) etc.
ADO.NET DATA SERVICES: The quickest way to get up an running with everthing ready to use, all you need todo is configure the global.asax, however you have to use an Entity Data Model, which you many not want to.
Personally, I would use either ADO.NET DATA SERVICES or WCF REST to build an API, consue that API in MVC site and then expose that API either directly, or by passing it through another layer.
ASP.NET MVC can serve as a REST endpoint for light services work, so I guess the answer to your question depends on how you define "safe."
Clearly WCF is designed specifically for creating REST endpoints, with all of the security implications that are implied thereof, whereas ASP.NET MVC is designed to create REST endpoints which can be used by ASP.NET MVC itself.
The following article shows how to create a web service using an ASP.NET MVC controller:
Create REST API using ASP.NET MVC that speaks both Json and plain Xml
http://msmvps.com/blogs/omar/archive/2008/10/03/create-rest-api-using-asp-net-mvc-that-speaks-both-json-and-plain-xml.aspx
See also the following article from Phil Haack, which discusses an SDK the WCF team put together for users of ASP.NET MVC:
Rest For ASP.NET MVC SDK and Sample
http://haacked.com/archive/2009/08/17/rest-for-mvc.aspx
They are two different sets of technologies, only related by being built on .net
MVC is used to create websites and provides a model where URLs are routed to controllers and controllers deliver views to the user as the user interface.
WCF is a set of libraries in .net that are used to abstract the type of service (is it hosted in a windows service, as a webservice in IIS etc.) as well as the protocol (HTTP, TCP, MSMQ etc.) from the client and server which are communicating.
An MVC website may use WCF to connect to a web service, but that is just one of many options.