Most applications, be it Facebook or a business app, make at least some of their data available for other applications to consume. The type of API architecture a service provides has a big impact on how developers need to program their apps.
The standard way: Pull API
This is also called “Polling” and it’s basically the same as refreshing your inbox every 5 minutes to check for new mail.
As a developer, if you want to find out whether an API has anything new for the user, you just need to call and ask.
Generally you can poll the API anytime, and as often as you like, but some larger applications typically have limits on how often they allow you to call their API.
Providers resort to this kind of throttling because API calls are expensive, and if allowed too often could even slow the app down for other users. It takes the server a few hundred milliseconds to receive each of your requests, verify and process them and send you the result – multiplied by thousands of users that are doing the same thing.
But even for you, as a developer, pull APIs can be expensive. For example, say you make an app that shows your 1000 customers the stock price of your company. You want the quote to be near real-time so you refresh it every 15 minutes. Doing some simple maths you’ll realize that your servers will have to call the stock API nearly 100,000 times a day.
Of course the stock prize at least changes continuously, but many use cases may not. Checking for a new task, a new comment or a new calendar invite even just four times an hour, means you’re checking each API 96 times per day. Probably you won’t get new tasks, comments or invites that often, so many of these API calls will yield no updates.
It is estimated, that whenever a service’s data doesn’t change continuously (like a stock quote or the weather), then 98% of poll requests are wasted.
Editor’s tip
Even if you have only a pull API to play with, there are some neat tricks applications do to lessen their load, e.g. caching or scheduling. Creating a Digital Assistant can help integrate business APIs and minimize the unsuccessful API calls for your servers.
The efficient way: Push API
A much faster way to monitor for updates is to reverse the roles: have the source application send out an update when it has something new. This is called a Push API, and is generally referred to as a HTTP request or a webhook.
A webhook is a specific URL your application gives to another application with the instructions to send the update this way whenever something new has happened. Then all your application has to do, is monitor it’s own URL which is much less resource-intensive and nearly instantaneous.
When you use a Webhook there is no waste of server processing power. The source knows to only make a call when it’s got a new event to share, and the recipient app can listen to it’s own URL with next to effort at all.
Webhooks are therefore considered to be the better API standard for any application that doesn’t continuously change it’s data.
New You can set up a webhook to trigger notifications in your Digital Assistant. Set up now
Webhooks are especially useful as a notification service. So anytime you don’t need a full list of all your tasks, but want to be send any new tasks. This kind of push architecture is used for many event-based updates.
Two examples could be receiving new sales leads from a 3rd party platform (left), or an update is sent whenever a website build has finished (right).
Some companies combine both pull and push approaches in their APIs, and have endpoints to receive full lists of user’s tasks, items, etc; as well as offering push services to notify other applications of updates.
Even faster but less popular: WebSockets
Since recently browsers support what is called TCP/IP WebSockets. This allows servers to push data directly to the browser through a connection that stays continuously open.
The WebSocket protocol is utilizing a close relative of the HTTP protocol that allows browsers to receive websites from a server. But with WebSockets the server and client can actually execute a handshake in order to start an open and permanent channel through which they can exchange WebSocket “envelopes”.
This enables the server to push updates towards the clients asynchronously: The client is basically letting the server know what types of information it would like delivered and the server then sends back ‘envelopes’ in relative real-time.
While incredibly fast, this technology is mostly used for communication within the client and server of the same application, and is not that popular for implementing integrations between applications from different companies.
