Webhooks vs. Polling: You're Better Than This
Polling and webhooks provide your application with a way of consuming new event data from an endpoint, but one is much more efficient.
Join the DZone community and get the full member experience.
Join For FreeThe ultimate goal of any API integration is the efficient sharing of data between apps to provide greater value to your users. In order to facilitate this, an integration must provide a method to detect changes, events, that occur in the endpoint application. Currently, two of the most popular event management tools are polling and webhooks.
Polling
The concept of polling is very simple: send a request for new events (specifically Create, Retrieve, and Delete events which signal changes in data) at a predetermined frequency and wait for the endpoint to respond. If the endpoint doesn’t respond, there are no new events to share.
Webhooks
Similar to polling, webhooks provide your application with a way of consuming new event data from an endpoint. However, instead of sending repeated requests for new events, you provide the endpoint with a URL, usually within the endpoint UI, which your application monitors. Whenever a new event occurs within the endpoint app, it posts the event data to your specified URL, updating your application in real-time.
Be Nice…to Your Servers
While polling and webhooks both accomplish the same task, webhooks are far more efficient. Zapier found that over 98.5% of polls are wasted. In contrast, webhooks only transfer data when there is new data to send, making them 100% efficient. That means that polling creates, on average, 66x more server load than webhooks. That’s a lot of wasted time, and if you’re paying per API call, a whole lot of wasted money.
Data is Always Old (Unless You Use Webhooks)
When using polling, the frequency of your polls limits how up-to-date your event data is. For example, if your polling frequency is every 12 hours, the events returned by any poll could have happened any time in the past 12 hours. This means that any time an event occurs in the endpoint, your app will be out-of-date until the next poll.
With webhooks, this problem is eliminated. Since events are posted immediately to your monitored URL, your apps will automatically update themselves with the new data almost instantly.
Developers Know Best
When over 160 developers were surveyed, 82% responded that they preferred webhooks over polling. Why? Beyond all of the advantages we’ve already discussed, webhooks are much easier to implement and maintain. For most endpoints, there is a UI tool for setting up webhooks, so coding is only required to define what event data should be transferred.
As an example let’s compare the code needed to create a webhook to the code needed for a polling framework in Marketo:
JS Result
EDIT ON
package com.marketo;
// minimal-json library (https://github.com/ralfstx/minimal-json)
import com.eclipsesource.json.JsonArray;
import com.eclipsesource.json.JsonObject;
import com.eclipsesource.json.JsonValue;
import java.io.*;
import java.net.MalformedURLException;
import java.net.URL;
import java.text.DateFormat;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.*;
import javax.net.ssl.HttpsURLConnection;
public class LeadActivities {
//
// Define Marketo REST API access credentials: Account Id, Client Id, Client Secret. For example:
private static Map<String, String> CUSTOM_SERVICE_DATA;
static {
CUSTOM_SERVICE_DATA = new HashMap<String, String>();
// CUSTOM_SERVICE_DATA.put("accountId", "111-AAA-222");
// CUSTOM_SERVICE_DATA.put("clientId", "2f4a4435-f6fa-4bd9-3248-098754982345");
// CUSTOM_SERVICE_DATA.put("clientSecret", "asdf6IVE9h4Jjcl59cOMAKFSk78ut12W");
}
// Number of lead records to read at a time
private static final String READ_BATCH_SIZE = "200";
// Lookup lead records using lead id as primary key
private static final String LEAD_FILTER_TYPE = "id";
// Lead record lookup returns these fields
private static final String LEAD_FIELDS = "firstName,lastName,email";
// Lookup activity records for these activity types
private static Map<Integer, String> ACTIVITY_TYPES;
static {
ACTIVITY_TYPES = new HashMap<Integer, String>();
ACTIVITY_TYPES.put(7, "Email Delivered");
ACTIVITY_TYPES.put(9, "Unsubscribe Email");
ACTIVITY_TYPES.put(10, "Open Email");
ACTIVITY_TYPES.put(11, "Click Email");
}
public static void main(String[] args) {
// Command line argument to set how far back to look for lead changes (number of days)
int lookBackNumDays = 1;
if (args.length == 1) {
lookBackNumDays = Integer.parseInt(args[0]);
}
// Establish "since date" using current timestamp minus some number of days (default is 1 day)
Calendar cal = Calendar.getInstance();
cal.add(Calendar.DAY_OF_MONTH, -lookBackNumDays);
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
String sinceDateTime = sdf.format(cal.getTime());
// Compose base URL
String baseUrl = String.format("https://%s.mktorest.com",
CUSTOM_SERVICE_DATA.get("accountId"));
// Compose Identity URL
String identityUrl = String.format("%s/identity/oauth/token?grant_type=%s&client_id=%s&client_secret=%s",
baseUrl, "client_credentials", CUSTOM_SERVICE_DATA.get("clientId"), CUSTOM_SERVICE_DATA.get("clientSecret"));
// Call Identity API
JsonObject identityObj = JsonObject.readFrom(getData(identityUrl));
String accessToken = identityObj.get("access_token").asString();
// Compose URLs for Get Lead Changes, and Get Paging Token
String activityTypesUrl = String.format("%s/rest/v1/activities/types.json?access_token=%s",
baseUrl, accessToken);
String pagingTokenUrl = String.format("%s/rest/v1/activities/pagingtoken.json?access_token=%s&sinceDatetime=%s",
baseUrl, accessToken, sinceDateTime);
// Use activity ids to create filter parameter
String activityTypeIds = "";
for (Integer id : ACTIVITY_TYPES.keySet()) {
activityTypeIds += "&activityTypeIds=" + id.toString();
}
// Compose URL for Get Lead Activities
// Only retrieve activities that match our defined activity types
String leadActivitiesUrl = String.format("%s/rest/v1/activities.json?access_token=%s%s&batchSize=%s",
baseUrl, accessToken, activityTypeIds, READ_BATCH_SIZE);
Map<Integer, List> activitiesMap = new HashMap<Integer, List>();
Set leadsSet = new HashSet();
// Call Get Paging Token API
JsonObject pagingTokenObj = JsonObject.readFrom(getData(pagingTokenUrl));
if (pagingTokenObj.get("success").asBoolean()) {
String nextPageToken = pagingTokenObj.get("nextPageToken").asString();
boolean moreResult;
do {
moreResult = false;
// Call Get Lead Activities API to retrieve activity data
JsonObject leadActivitiesObj = JsonObject.readFrom(getData(String.format("%s&nextPageToken=%s",
leadActivitiesUrl, nextPageToken)));
if (leadActivitiesObj.get("success").asBoolean()) {
moreResult = leadActivitiesObj.get("moreResult").asBoolean();
nextPageToken = leadActivitiesObj.get("nextPageToken").asString();
if (leadActivitiesObj.get("result") != null) {
JsonArray activitiesResultAry = leadActivitiesObj.get("result").asArray();
for (JsonValue activitiesResultObj : activitiesResultAry) {
// Extract activity fields of interest (leadID, activityType, activityDate, primaryAttributeValue)
JsonObject leadObj = new JsonObject();
int leadId = activitiesResultObj.asObject().get("leadId").asInt();
leadObj.add("activityType", ACTIVITY_TYPES.get(activitiesResultObj.asObject().get("activityTypeId").asInt()));
leadObj.add("activityDate", activitiesResultObj.asObject().get("activityDate").asString());
leadObj.add("primaryAttributeValue", activitiesResultObj.asObject().get("primaryAttributeValue").asString());
// Store JSON containing activity fields in a map using lead id as key
List leadLst = activitiesMap.get(leadId);
if (leadLst == null) {
activitiesMap.put(leadId, new ArrayList());
leadLst = activitiesMap.get(leadId);
}
leadLst.add(leadObj);
// Store unique lead ids for use as lead filter value below
leadsSet.add(leadId);
}
}
}
} while (moreResult);
}
// Use unique lead id values to create filter parameter
String filterValues = "";
for (Object object : leadsSet) {
if (filterValues.length() > 0) {
filterValues += ",";
}
filterValues += String.format("%s", object);
}
// Compose Get Multiple Leads by Filter Type URL
// Only retrieve leads that match the list of lead ids that was accumulated during activity query
String getMultipleLeadsUrl = String.format("%s/rest/v1/leads.json?access_token=%s&filterType=%s&fields=%s&filterValues=%s&batchSize=%s",
baseUrl, accessToken, LEAD_FILTER_TYPE, LEAD_FIELDS, filterValues, READ_BATCH_SIZE);
String nextPageToken = "";
do {
String gmlUrl = getMultipleLeadsUrl;
// Append paging token to Get Multiple Leads by Filter Type URL
if (nextPageToken.length() > 0) {
gmlUrl = String.format("%s&nextPageToken=%s", getMultipleLeadsUrl, nextPageToken);
}
// Call Get Multiple Leads by Filter Type API to retrieve lead data
JsonObject multipleLeadsObj = JsonObject.readFrom(getData(gmlUrl));
if (multipleLeadsObj.get("success").asBoolean()) {
if (multipleLeadsObj.get("result") != null) {
JsonArray multipleLeadsResultAry = multipleLeadsObj.get("result").asArray();
// Iterate through lead data
for (JsonValue leadResultObj : multipleLeadsResultAry) {
int leadId = leadResultObj.asObject().get("id").asInt();
// Join activity data with lead fields of interest (firstName, lastName, email)
List leadLst = activitiesMap.get(leadId);
for (JsonObject leadObj : leadLst) {
leadObj.add("firstName", leadResultObj.asObject().get("firstName").asString());
leadObj.add("lastName", leadResultObj.asObject().get("lastName").asString());
leadObj.add("email", leadResultObj.asObject().get("email").asString());
}
}
}
}
nextPageToken = "";
if (multipleLeadsObj.asObject().get("nextPageToken") != null) {
nextPageToken = multipleLeadsObj.get("nextPageToken").asString();
}
} while (nextPageToken.length() > 0);
// Now place activity data into an array of JSON objects
JsonArray activitiesAry = new JsonArray();
for (Map.Entry<Integer, List> activity : activitiesMap.entrySet()) {
int leadId = activity.getKey();
for (JsonObject leadObj : activity.getValue()) {
// do something with leadId and each leadObj
leadObj.add("leadId", leadId);
activitiesAry.add(leadObj);
}
}
// Print out result objects
JsonObject result = new JsonObject();
result.add("result", activitiesAry);
System.out.println(result);
System.exit(0);
}
// Perform HTTP GET request
private static String getData(String endpoint) {
String data = "";
try {
URL url = new URL(endpoint);
HttpsURLConnection urlConn = (HttpsURLConnection) url.openConnection();
urlConn.setRequestMethod("GET");
urlConn.setAllowUserInteraction(false);
urlConn.setDoOutput(true);
int responseCode = urlConn.getResponseCode();
if (responseCode == 200) {
InputStream inStream = urlConn.getInputStream();
data = convertStreamToString(inStream);
} else {
System.out.println(responseCode);
data = "Status:" + responseCode;
}
} catch (MalformedURLException e) {
System.out.println("URL not valid.");
} catch (IOException e) {
System.out.println("IOException: " + e.getMessage());
e.printStackTrace();
}
return data;
}
private static String convertStreamToString(InputStream inputStream) {
try {
return new Scanner(inputStream).useDelimiter("A").next();
} catch (NoSuchElementException e) {
return "";
}
}
}
Source: Marketo.
That's a lot of code! Within our polling framework, we are making GET requests to the endpoint at a certain time interval. We define how far back in time to look for changes, iterate through all of our lead data, and separate out leads associated with activities that occurred within our timespan. The more often we poll, the shorter the time period we have to loop through.
Theoretically, the framework should work the same way for every poll, but it's likely that it will need to be changed with future versioning of the endpoint.
Now let's see what we need for a webhook:
JS Result
EDIT ON
URL: "https://hooks.slack.com/services/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"
payload={"text": "DEVELOPER SITE ALERT: {{lead.First Name:default=edit me}} {{lead.Company=edit me}}, {{lead.Email Address:default=no email address}}" }
Source: Marketo.
That's it! Just provide a URL, specify a payload, and the rest is taken care of with a few clicks in the Marketo UI. In this example, Marketo posts an event to the URL anytime a lead visits a certain domain. The user's instance of Slack monitors the domain and posts the lead's name, company, and email address in one of its channels. Because the process is handled by the endpoint API, it is less likely that the webhook will break in future versions, unless the existing object names are altered, which is unlikely.
As the proliferation of the API economy continues, expect to see many more APIs begin to support webhooks. To stay ahead of the curve, check out the State of API Integration Report which goes into greater depth on the advantages of webhooks as well as which APIs support them.
Published at DZone with permission of Ross Garrett, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments