Should we call Web API from MVC application in same solution?

Question

I am working on a project in MVC that has mobile application so one thing is clear that we have to use Web API so it can used in mobile application.

After creating API when we started to develop Web site we are confused and had discussion on whether to use API or directly access to the Business object. And we ended up after having opinion form more experienced developer to consume Web API instead of using Business object directly.

I'm having confusion regarding to this solution structure.

1) Why we should use Web API and make HTTP request (which is time consuming) to get or put data instead of business object directly which is in same solution.

2) After having arguments they said what if client wants to host API and web on different cloud server and apply scaling only on API or may be he want to have different url for accessing API and Web (which is some what logical). So in that case should we call Web API from MVC application in same solution?

3) If we're hosting API and Web on different hosting so it means our Web will use WebClient and have HTTP call on each navigation. Is it right?

4) If we'll business object form both API and Web hosting on different server then if something change in BL will need to update build on both server.

5) Or we should create only one project for API and can add views or html pages to develop Web interface so in that way we can directly call API from ajax.

As per my knowledge #5 is the best solution or API is only for 3rd party access. If we have DB, EF, data layer and business layer in same solution then we should not use API to make HTTP calls and directly access business object. (correct me if I'm wrong)API is needed when mobile application or desktop or any one want to access application so we can have same repository and data layer.

In my scenario I've to create API as we also have mobile application, and in project API side we called business layer (separate project) and business layer communicate to data access layer (separate project). So my question is if we host our API and web to different servers then calling API which is a HTTP request may take longer rather than using method from business layer as we create the project and we've .dll of business layer. In API controller we just convert out put of our business to json format.

I've searched on internet but didn't get convincing answer. I've found a blog http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx discussing same point but again in that blog my question is why we need to consider scenario #3?

Answer 1

I think you have answered your own question in writing, but really this boils down entirely to what your requirements are, and perhaps more importantly, what the strategy for your application is.

First of all, using Web Api over accessing Business Objects directly (by which I think you mean through viewmodels etc) only makes sense if you are controlling access of data client side.

If you only have a requirement for consuming data from client side within a particular application, then hosting Web API within the same project makes sense. Sometimes, for instance when building a SPA or rich-client web app, then using Web Api within the same projhect is sufficient, as they are only intended to be consumed by that application.

Where you see a requirement for different versions of the same application (mobile, tablet, web etc), then moving the Web Api to a separate project makes sense, as each application can then access the same API. This Web Api would contain your data access and business logic layers within it. This allows complete separation of your projects then, and provides maximum reusability, and ensures consistency in data between different versions of your project. Obviously with this set up, your Web Api layer is seperate and can be tested/deployed/scaled separately.

So in summary, you need to consider your requirements and assess the technologies available to you to achieve them. Using the above I hope you understand where Web Api fits in and what it can provide.