As a Salesforce Administrator you’ve probably heard the term ‘Salesforce APIs’ many times and you know that they’re something to do with programming but have never really been sure what they are and when/how to use them. Sound familiar?
Well let’s break it down and get our heads around the basics of the topic. We’re all familiar with the idea of a UI or User Interface which is the way that we send commands like View or Save to our Salesforce org and as Admins, we do so via the graphical Web UI by, for example, clicking on the Save button. API stands for Application Programming Interface and it’s simply another way of sending commands to Salesforce, only this time there’s no graphical UI to work through, instead developers use the APIs to send commands like View or Save to Salesforce programmatically by writing platform code.
There are several different APIs that developers can use; which one they choose will depend on what it is that they want to do. In this blog I’m going to focus on the 4 main data APIs that developers use to programmatically manipulate Salesforce data; the REST API, the SOAP API, the Bulk API and the Streaming API. There are of course several other APIs like the Metadata API which developers can use to manipulate things like objects, fields & page layouts etc. or the Analytics REST API to work with things like datasets, lenses & dashboards.
REST API
The REST API can be used to retrieve data from the database by querying or searching, and also allows us to perform DML (Data Manipulation Language) commands such as Insert, Update, Delete, Upsert & Undelete in code. The commands & functionality are exposed to our code via REST resources and HTTP methods and the REST API supports both XML & JSON which are two highly structured data formats used for moving data around. Because the REST API’s request/response framework is lightweight it makes it a great tool for developers to use when authoring apps for both the web and mobile.
SOAP API
SOAP stands for Simple Object Access Protocol and is an industry standard protocol that allows the various elements of an app to communicate with each other. The Salesforce SOAP API is powerful functionality exposed to developers as web services and uses something called a WSDL (Web Services Definition Language) file as a kind of contract between the API and the consumer to determine the location of the web service and the methods that it makes available to the consumer. The WSDL is written in XML. In fact, the SOAP API only supports XML and does not support JSON. Whilst most of the SOAP API functionality is available via the REST API, because there is this formal WSDL contract between the API and the consumer, SOAP can be better for authoring integrations between servers.
Bulk API
The Bulk API is a special version of the REST API which has been optimised for working with particularly large volumes of data and by large volumes, I mean more than 50,000 records at a time. The Bulk API processes data asynchronously meaning that a single large batch of data is broken down into multiple smaller batches which are then sent to multiple servers for processing at the same time. Once the request has been made, you don’t need to wait for the response to come back before you can get on with other work (unlike with synchronous processes). And because multiple batches are processed at the same time, there’s a speed benefit to working with the Bulk API. So, if your requirement is to load large amounts of data into your org the Bulk API is the way to go.
Streaming API
If you want to programmatically set up notifications that occur automatically when changes are made to your data, then the Streaming API is the one to choose. The Streaming API utilises a Publish/Subscribe architecture where notifications are published to a channel and users can subscribe to that channel to receive the notifications. It works a little bit like a radio transmission where a radio signal is broadcast irrespective of whether anyone’s listening, and people can receive the broadcast by tuning in to the right channel. The publisher (that’s broadcasting the signal) and the consumer (who’s listening to the signal) don’t need to know about each other and don’t have any dependencies on each other. As a result, with the Streaming API the need for your app to continuously make API requests by polling for changes is massively reduced. Thus, if the app you’re building would need to constantly poll for data changes, the Streaming API is a great choice.
If you want to know more about Salesforce APIs or need some help with Salesforce, just contact us!