Configuring access to a web service in production, test and development environments

I'm developing an API in the form of a .NET web service. Third parties will consume the API, and so will my own website. The servers and developer workstations hosting the API must support four different ways of accessing the API:

1. Third parties must be able to access the API on my production web server using a secure (HTTPS) URL visible outside my private IP space.
2. The production version of my website must be able to access the API on my production web server using a secure (HTTPS) URL visible inside my private IP space.
3. The test version of my website must be able to access the API on my test web server using a secure (HTTPS) URL visible inside my private IP space.
4. A developer's local copy of my website must be able to access the API on the developer's computer using a non-secure (HTTP) URL visible on the local computer, avoiding the need to configure a local IIS site to support SSL.

Here's how I fulfilled all four requirements:

IIS:

• On the live web server, I created a website with IP address x.y.z.134*, ports 80 and 443, no host header.
• On the test web server, I created a website with IP address x.y.z.130, ports 80 and 443, no host header.
• On my local computer, I created a website with IP address "All Unassigned", port 80, and host header "oosapi".

Hosts file:

• On the live web server, the hosts file includes the entry "x.y.z.134 oosapi.localupmenus.com".
• On the test web server, the hosts file includes the entry "x.y.z.130 oosapi.localupmenustest.com".
• On my local computer, the hosts file includes the entry "127.0.0.1 oosapi".

*IP addresses are masked to avoid divulging my private IP address space.

You might wonder why I didn't just use the name "oosapi" in the hosts file for all three environments. The answer is that I wish to use SSL on the live and test web servers. My SSL certificates are for the domains localupmenus.com and localupmenustest.com, not oosapi. If I used oosapi, an "invalid certificate" warning would occur, and .NET would refuse to connect to the web service.

In the web.config for the my website, one of three keys identifying the URL for the web service is uncommented:

• On the live web server:
• On the test web server:
• On my local computer:

(An interesting side note: A Google search for "dynamic web reference" turns up many articles that suggest setting the web reference's "URL Behavior" property to "Dynamic" in Visual Studio. There's just one catch: A Visual Studio web site, as opposed to other project types, doesn't support the "URL Behavior" property. Fortunately, the answer is simple: for a web site, the web reference URL is automatically stored in web.config, and it's just a matter of editing that web.config key to suit each deployment environment.)

The above handles requirements #2 - #4. That just leaves requirement #1. For third party access, I created a DNS entry in LocalUp's GoDaddy account, mapping oosapi.localupmenus.com to 74.116.125.134. That's the public IP that corresponds to the private IP x.y.z.134.