net core mvc web application, it also has web api controllers layer. Since these controllers now also need to be used from another application we are thinking about separating API and exposing it independently.
I would like to understand how best to do it, what will be the different options with it specially considering authentication/authorization? Do I need to implement Identity Server or it is a nice to have?
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.
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.
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 would appreciate if someone can provide some insight into which one is more beneficial.
RESTful service in WCF can provide the same functionaly as ASP.Net MVC Controller, i.e URLS can be formed appropriately using Controller/Action.
Is there real benefit of using one over the other.
WCF Rest service will provide..
1) Cert Authentication out of the box
2) Logging
3) Message Headers etc
MVC
1) Different Action Results out of the box
If someone has used or debated these two technologies . please let me know
UPDATE:
I went ahead with the MVC Model as it gives me lot of flexibility and I can use the same action to render different views with CustomActionInvoker, which is really cool!!!
-RN
WCF makes your service more manageable and offers more protocol options like TCP, Named Pipes, PerChannel, and MSMQ.
WCF gives you the ability to specify multiple methods of binding to the service through the web.config including restful urls, giving you greater flexibility. In conrast, mvc provides you with the ability to easily construct resful urls and output data via code in much the same way as you do a web application, which is really easy and requires minimal additional knowledge if you already know mvc.
My recommendation would be to go with wcf if the service is really important to the overall solution, likely to be called in a different or many ways or has or is likely to have special security requirements.
On the other hand I would go mvc if this is meant to be a quick and simple isolated solution or perhaps is just providing a different representation of data being output in an existing .net mvc application.
At this point in time, your best option is ASP.NET MVC. It provides cleaner access to the HTTP primitives you need to be able to design RESTful solutions.
The only significant advantages of WCF Rest is the ability to self-host the service and if you want to use ADO.NET Data Services to deliver OData/Atom services, then obviously WCF is your best choice.
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.