Calling APEX Rest service using Postman

This post explains the setup of Postman REST Client.  Postman REST client is an add-on for chrome that can connect to Salesforce using OAUTH 2.0 password flow.  Using this method, you can get the access token to call your APEX rest service.  

This topic assumes that you already have Postman REST client.  In case you don't have Postman REST Client, you can download from Chrome Store

Setting up OAUTH

Open Postman and click on new Collection to create a new collection.  Then enter the collection name as shown in below

Click on Create to create a new collection.  This will create a new collection

Now, we are ready to get the access token from Salesforce using OAUTH.  Enter the Authentication URL to salesforce under Normal Settings of the Postman.  For Sandbox the Authentication URL is https://test.salesforce.com/services/oauth2/token and for production it is https://login.salesforce.com/services/oauth2/token.

Then select form-data is a method of POST to salesforce.  The following key value paris are necessary to post the authentication information to Salesforce.  

•  grant_type=password
• client_id=<clientId>
• client_secret=<clientSecret>
• username=<username>
• password=<password>

The values for <clientId> and <clientSecret> need to be configured as an OAUTH application in Salesforce.  For more information on the setting up app access, refer to sale force documentation here..  Save the script.  You have the script read.  Now, add the script to the collection you have just created, by selecting "Add to Collection" button.

To get the access token, click on the "Send" button to get the send the authentication request.  If the user name, password, client id, client secret is correct, salesforce will return a JSON structure that contains access token.

You can now use this access token in the Request header to process calls in Salesforce.

• Crete a new service by cloning the existing OAUTH service. 
•  Change the URL to your apex service.  The format of the URL will be:  <instance_name>/services/apexrest/<servicename>/<version>  In this example we will us helloWorld Service.  so the instance url will be <instance_name>/services/apexrest/helloWorld/
• Create a new Header Authorization parameter that has the access_token from the previous step.
• Set the Content-Type as 'application/json'
• Enter the JSON message in the Body to be submitted to Salesforce

The sample call to helloWorld Service in Salesforce is shown in screen capture below.  This service uses HTTP POST to post the message and the service responds back with the helloWorld in the respective language.

Now you can test your web services by click of a button.  Happy development!

Environment specific variables in SalesForce

If you are developing web-service callouts in development or sandbox and moving them to production, you have to manually change the properties of the out-bound webservices.  For example, you are developing a callout that updates the customer information to an external system when a new customer record is created in SalesForce in Sandbox.  After completing the testing of the callout, you would want to move your apex code to production org.  But, the end point, authentication details of the outbound service will be different than the one in test environments. 

Unfortunately, SalesForce doesn't provide the flexibility of configuration/property files that Java provides.  Luckily SalesForce now provides Custom Label functionality that can be used for this purpose.  

I normally define the endpoints, authentication details as custom labels in sandbox and production orgs.  The advantage is, 

• the apex classes need not change from sandbox to production.  
• The test cases run perfectly fine in sandbox and production orgs.  
• When there is a change in environment specific property value, you need not create a change-set or migrate your code.  
• Better Apex code development

To create custom labels

Setup->Create->Custom Labels

There are other way of externalizing the properties 

• Create Properties__C object and store the properties.  The disadvantage of this approach is you are maintaining an object for properties and issuing SOQL queries to retrieve the properties.  
• Using URLRewrite:  While this solves the purpose like the one mentioned above.  It involves find the parsing various formats of SalesForce's representation of the URLs, i.e.. different urls for internal users, portal users and sites users and you have to understand them
• Page References:  Using page reference to get the url is limited by developing VF pages and would not address the purpose of this discussion
• Get Organization ID:  Getting the org. id will also solve the purpose and you can determine based on the org. id which property to use.  But this can lead to issues when you have more than 2 orgs and also multiple outbound web-service environments