Making Third Party API Calls From Lightning Components
5 minute read
There are many APIs, public or available in the enterprise service catalog. The traditional way is to use server side capabilities in our application to make requests, process and deliver to the browser. In this article we’re going to see this approach and a different one, using the Content Security Policy (CSP) available in Lightning components to make this calls directly from the browser.
Making API calls to third party API from Lightning component in client-side
Browsers apply a same-origin restriction to content requests. This restriction prevent the browser running from one domain (origin) from getting content retrieved from a different one. This article describes the mechanism to make client-side cross-origin requests in from Salesforce Lightning components, following the specifications defined in Cross-Origin Resource Sharing (CORS).
First we’re going to analyze the behavior, for that we build a simple Lightning component to make third party API calls providing an Url, here we go:
Now we have this form and can use it to test all the possible scenarios, to check the errors retrieved by the browser in each case, and we can see how to configure the things to make this kind of calls:
Errror 1: Url not allowed in CSP
For example if we provide a url not allowed, as https://www.yahoo.com, the code tries to invoke the XMLHttpRequest, but the error that we’re going to get is this one. In fact, the browser blocks the callout.
Error 2: Url allowed in CSP but without permissions in thirdparty server
To avoid these problems in the configuration, the first thing is to create the entry for the thirdparty url in Content Private Policy (CSP). Go to setup and in the quick find box type “CSP”. Create a new entry and provide the url, name and description, once you have it configured, you are allowing to perform callout requests over that domain:
Plus to this the thirdparty service have to authorize this kind of callouts, to understand that we are going to see the type of the call that is doing the Lightning component, note that the used method in the request is OPTIONS, the response manage the authorization using the headers Access-Control-Allow-Origin (for the domain), Access-Control-Allow-Methods (HTTP methods) and Access-Control-Allow-Headers (other headers like Content-Type for example)
Making API calls to third party API from Lightning component using an AuraEnabled proxy class
Sometimes it is not possible to modify the behavior of the thirdparty API provider to authorize requests from our salesforce organization, then the alternative is to use the AuraEnabled Lightning Controller using Apex on the server side where this kind of browser restrictions does not apply and then provide to the browser the result, acting as a proxy. For this article we developed a simple Apex proxy class that can be extended from your Lightning AuraEnabled controllers to provide this proxy functionality.
Here we have a simple Lightning component who generates a form to collect all the HttpRequest parameters and call to a generic proxy, available in our git hub repo GitHub repository apex-http-proxy-for-lightning
The proxy can be deployed from github directly to your org, and you only need to create your own @AuraEnabled controller, here an example.
And provide a simple JSON structure from the Lighting Component:
It will return a simple JSON structure too, to manage in your Lightning Component. Don’t forget to add an entry in > Setup > Remote sites to provide the entry for the domain, it is needed to allow the Salesforce org to connect to external domains.
The sample controller only needs to call the HttpService.send method and expose the method with @AuraEnabled to provide access to the Lightning Component: