ASP.NET Web API: Design Practices for Clients

Question

For people who follow the fairly new ASP.NET Web API , they know that this is a good framework for building well-designed and appearance-oriented HTTP services that can span many different clients using standard XML or JSON content types.

I recently developed a large API for use with both web and mobile clients. I noticed that in the ASP.NET web API template provided through Microsoft NuGet web API packages, they take a very minimal approach to views with a slightly beautiful home page.

It made me come back. Mostly because I would suggest that the web API is designed for just that, the web API and nothing more.

In other opinions, is it standard to develop a web client (which interacts with your API)

• Inside a web API project?

  Or

• Outside of the web API project for splitting the web client, is it the same as your mobile or desktop clients?

The second choice seems logical to me in terms of maintainability and cleanliness of the code, but there may be other perspectives that may be useful when developing in ASP.NET Web API. What do you think?

Answer 1

Great that you use the web API!

You are right about your first problem, which conceptually makes sense to separate the web API from the submission. I would recommend either using the project type "Empty" in the dialog box of the new MVC project, and then adding API controllers. Or add the NuGet packages yourself to an empty web project. Packages should not add any views to your project.

As for clients, I highly recommend separating the client library into a separate project for maintenance. It’s good that you have common data types that you share between the client and the web API. In this case, this is a common template for moving your models to a separate dll, and both clients and the web API refer to types in this library.

A couple of reasons why you want the client and the web API to be separate (and there are many more):

• If you are distributing the library, you want to distribute the client code, not the web API code.
• You want to create a clean contract between the client and the server and avoid the client depending on the server implementation or vice versa.