I have an API that for firewall reasons can't sit on an internal DMZ and has to reside on the internal network. It was suggested that I build a 'shell' API that basically has all the same endpoints but just passes data back and forth between the APIs and Web App. enter image description here

So is creating another API to sit in the internal DMZ so I can pass messages between the DMZ web app and the Internal Web API the best way to achieve this? Or more to the point: what is the standard way to forward HTTP requests from the DMZ to Internal via an Internal DMZ?

Would an ideal way be to set up ARR on the internal DMZ to send to the internal API?

1 Answer 1


In my experience, using a reverse proxy like that provided by nginx was the easiest approach as it involved little more than forwarding relevant external requests through the firewall.


The problem with a shell or facade, as some call it, is the constant need to update in two code bases and on at least two servers as the code evolves. Making one API work well and securing it will be an easier task and reduce maintenance complexity. With nginx, you can limit the URL paths that will be proxied.

  • Thanks, it seemed like a crazy idea to recreate all the enpoints for an API again just to pass them through. I ended up going with a reverse proxy URL rewewrite module on IIS. Worked perfectly. Jul 13, 2015 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.