How do I share the URL of my application with another application in Bluemix?

How do I share the URL of my application with another application in Bluemix?

I have two applications on Bluemix and I need to give the URL of one application to the other one.
$response = http_get(“”);

Hard coding the URL in my source code seems like a bad idea… What if the url changes?


Solution 1:

Hard coding the URL or any credentials in the source is bad practice. In Bluemix, you can pass these credentials to your application using the VCAP_SERVICES environment variable. This is same environment variable that holds credentials for Bluemix services.

You are essentially creating your own service visible to your org and space by creating a user-provided service.

Create a new service that provides the url to consumers of this service:

$ cf cups myOrdersAppService -p "url"
Creating user provided service myOrdersApp in org **** / space ****

And then binding this service to the application that wants this “url” information

$ cf bind-service myOtherApplication myOrdersAppService

myOtherApplication can how get the url by parsing the VCAP_SERVICES environment variable. For example, in PHP:

$services = getenv("VCAP_SERVICES");
$services_json = json_decode($services, true);

for ($i = 0; $i < sizeof($services_json["user-provided"]); $i++){
    if ($services_json["user-provided"][$i]["name"] == "myOrdersApp"){
        $ordersHost = $services_json["user-provided"][$i]["credentials"]["url"];
        $response = http_get($ordersHost);

You can use this same method to share credentials of any external services (like databases). When using the microservice architecture, this feature becomes extremely useful.

$ cf cups myExternalDB -p "host, username, password"
username> myusername
password> mypassw0rd

For more details, check out this doc:

Solution 2:

I agree with Ram’s suggestion to retrieve service parameters via VCAP_SERVICES, especially when it specifies information intrinsic to the binding of a service to your application like credentials. However, for more mundane configuration properties (e.g., what languages are supported and where are the translations located? What URL should be used for invoking this REST service?), traditional methods like passing them on the command line, retrieving them from a configuration file, or getting them from environment variables specified by the admin at deployment time are perfectly legitimate.

Related:  Not able to inject java object while writing Annotation based Method Interceptor using Guice framework

Pat Mueller’s Keeping secrets – how your cloud application should access credentials and other private data nicely summarizes the options and tradeoffs. Most importantly, he underscores the importance of not hardcoding sensitive information, especially given the likelihood that code will be stored in a repository where it’s not readily evident who will have access, unlike a deployment script maintained by the system admin.