Strategy for a central web API application to serve multiple .NET interfaces
I want to finally decouple all my ASP.NET MVC projects.
They use several approaches as time went on and I learned:
- Standard MVC, controller actions return individual views to the browser.
- Controller actions returning partial FAT views and jquery refresh pages.
- Controller actions returning only JSON / XML and jquery data perform UI update
Now I want to move to more dynamic interfaces using heavier JavaScript approaches, putting libraries like Knockout, Angular, Backbone etc into the game But I also want to be flexible and fast enough if I just want to return the finished partial view from my actions with a controller.
So, I was thinking about centralizing my business layer NOT as shared projects in my MVC projects, BUT had a central web interface endpoint over my business layer and DAL that would serve my various front ends (it could be MVC, console app, reports, etc.)
It:
DAL → Business Layer → WEB API
After that, I want to know how to connect to the WEB API outputting from different points:
-
Pure JS: Directly from WEB Api endpoints with ajax calls
2.NET applications (MVC, WinForms etc): How exactly?
My question is mostly about # 2 above. I want specific use cases on how to consume my central WEP API from inside Windows Forms or MVC controller actions
source to share
This is called service oriented architecture .
For # 2, you have the following options to call RESTful services from a .NET client (be it ASP.NET MVC or WinForms):
- Using HttpClient .
- Use RestSharp . It is a helper library that covers most of the basic operations, including request / response serialization and deserialization. Please note that in newer versions the JSON.NET support has been removed (for some reason I don't remember now ... in the discussion in google groups anyway).
Anyway, I recommend looking into the async / await pattern, which HttpClient fully supports. It will make your life a lot easier, especially for WinForms stuff.
Oh # 1, there is nothing stopping you from having a JavaScript frontend in your web API. Just be careful with CORS as I am guessing you might need it (having multiple web clients, possibly deployed on different domains).
source to share