It’s not unusual for network administrators to lock down their server environments for security reasons and restrict inbound and outbound network activity. Basically, nothing can come in or go out without permission. As such, if your application requires an HTTP connection to call an external web service, then your network admin will most likely need to create a firewall rule to allow access to the service provider so that communication between your application and the web service may occur.
Most firewall rules are created to whitelist ports on a specific IP address. While opening up a port for a particular IP address will allow communication between the two endpoints to occur, most RESTful web services will make use of several IP addresses that point to geographically different data centers to help ensure maximum uptime and availability. So if your service provider has multiple IP addresses available then be sure to whitelist all of them in your firewall. Not only should you include all available IP addresses in your firewall rules, but you also need to make sure that your application utilizes proper failover code to use another IP address in the event that one responds slowly or becomes unavailable.
It is also recommended that you never hardcode a reference endpoint such as a domain or IP address. In the event of unexpected network related failure, a hardcoded endpoint will leave you vulnerable and leave you with no choice but to update your code. Depending on the complexity of your code and your deployment procedure, this could lead to more wasted downtime than necessary. Instead, it is considered a better practice to use an editable configuration location such as a database or config file to save your service endpoints. Using an easy to access editable location means that you can quickly switch to another service endpoint in the event that primary endpoint is unavailable.
Depending on how your failover code is written, using an external configuration location can also save your application from attempting a request to an unresponsive location. If your application is always attempting a call to a primary location first before failing over, then your application must first wait for the primary location to fail before attempting a call to the secondary location. Most default timeouts are around 30 seconds, so your application may be forced to wait for 30 seconds before switching to a secondary location, but with an editable configuration source you can easily swap out the bad location for a good one and save your application from any future failures.
Overall, here some basic tips for referencing a web service from a production application:
- Do not hardcode your reference endpoints.
- Do not reference by an IP address unless you are restricted behind a firewall. Otherwise always use the fully qualified domain name.
- If you are behind a restricted firewall then be sure to include all IP Address endpoints if more than one is available.
- Be sure to include failover code to make use of the available endpoints in the event that one or more may become unavailable.
Follow the above tips to help take full advantage of what your RESTful service provider has to offer and to also help ensure that you are doing everything you can to keep your application running smoothly.
