Web API in N-tier Design C#

0
votes

I'm accustomed to seeing an n-tier design pattern like the following: 1) Database (SQL Server) 2) Domain (EF) 3) Facade Service Layer (WCF) 4) MVC Web app (IIS)

In terms of Firewalls and protected areas, the Web Server and MVC app live in a public facing area (DMZ) in front of a Web Service, that lives behind another firewall that processes business logic and connects to the data layer, for an added layer of security.

Is there any reason or advantage to using Web API behind the firewall (not DMZ) to pass business logic back to the Website? I was thinking this is where WCF excels.

If for example a native mobile app was created and needed to access the server, would an additional WebAPI web service live in the DMZ (similar to MVC site), that would then connect back to an internal service (WCF) that does back in and business logic processing?

I'm sure it depends on the specific needs of the application, but as a general design pattern, should Web API live that area of the architecture?

Thanks!

1
wcfasp.net-web-api2n-tier-architecture
If your WebAPI is serving up data to be consumed by the client it probably lives in the same place as the MVC code, most likely in the same actual project. You would have both MVC and WepAPI controllers. – Mant101

1 Answers

0
votes

There is no 'general design pattern' you should use. What will consume the Web API? Is it just to be consumed internally, if so then hide it way and only allow access to what needs it.

One of the main advantages to a Web API is that loads of different clients can consume it, i.e. SPA, Mobile, other servers, etc. Therefore they are generally public and as Mant101 said, a lot of the time they live in the same project as your MVC implementation.

More importantly than where it live is maybe how do you secure it? How will applications/user authenticate themselves? Personally I would be thinking about this rather than which DMZ to put it in.

If you were to use something like OWIN middleware then you can provide different authentication methods to this API so it can be consumed by mobile and the like. If you really wanted to maintain something of the N-tier you could probably proxy the API somehow but try to solve it with network design rather than application.