If it was decided to use WebAPI to create a service layer to be used for a variety of clients. What would be the best way to architect the web client?
As WebAPI is web-friendly it would be possible to consume this directly from the client using javascript. However I would worry that this can get messy fairly quickly and javascript is not the easiest technology to unit test.
An alternative would be to use the HttpClient class to call the REST services from MVC controllers. Is this a valid approach?
I suppose that the two approachs above could be combined but I would worry that this would get messy. Would you agree that it would be better to go with one approach or the another?
Sorry I have seen many posts on whether to use WebAPI or MVC but none on combining the two.
Thoughts?
Yes, absolutely. It’s just that this code should not be put in your controllers but rather in your DAL layer, because controllers should not know where the data comes from (flat file, database, Web API, …).
So there are 2 approaches:
Which approach you choose would really depend on your specific scenario and requirements. Do you need to support interoperable clients other than your MVC client application? In any case start by defining a service layer in a separate assembly containing your domain models and stuff. Then you could always expose this service layer through a Web API (or a WCF service or whatever) or directly reference it from .NET clients.