Reasons to Integrate Salesforce is part of the blog post series: Integrating Salesforce With Other Apps – A Series!
Salesforce has a few different types of APIs that they support that can be used for many different purposes.For example, there’s an API called the Tooling API which is useful for manipulating apex, running tests, or etc.
What is an API?
API stands for Application Programming Interface. An API is a list of commands that allows different components to interact. In general, most automation makes heavy use of these lists of commands to connect and integrate. Mulesoft has put together a pretty good video explaining what APIs are and what they can be used for.
What are Salesforce’s API?
There’s quite a few different options that have been made available by Salesforce to integrate it in your business processes.For the most part, everything that can be done through a UI within Salesforce can be done through an API.
There’s a quite few different standards that exist for connecting software over the internet like SOAP and REST. Salesforce offers both Soap and REST options to developers.
What is SOAP
SOAP stands for Simple Object Access Protocol, but it’s hardly a simple protocol. SOAP is a heavily standardized messaging protocol that uses XML and HTTP to send data. It has been used for a very long time by large enterprises to send messages between services. If you have programmed in Java, Visual Basic, or .NET you have most likely used a SOAP API. Another way to know, is if you’re familiar with wsdl files which are usually used to enforce the contract between the API consumer and the provider.
What is REST?
REST stands for Representational State Transfer and is usually a lot easier to implement if your planning to send and receive messages. Roy Fielding originally conceived the idea in this paper. REST APIs have two major advantages over SOAP. The first advantage, which can also be a negative, is that REST can be a lot more dynamic than SOAP and doesn’t require generating WSDL files that have to be used to connect the client and provider. As I mentioned, this means it can also be a lot more difficult for the consumer because using the wsdl file usually allowed a lot of the necessary “plumbing” code to be automatically generated.
The other advantage, which is huge, is that REST can return JSON which is usually much smaller and in some languages a lot easier to consume. APEX, for example, is a lot better for consuming JSON than it is XML although it’s possible to parse XML files.
Salesforce SOAP API
Salesforce’s original API is called the “SOAP API” which has been around for a long time. Prior to Salesforce making Apex available this was commonly used to integrate Salesforce into business processes. It was and still is commonly used for DML operations like updating or creating records and for querying. I wouldn’t be surprised if it’s still the most used Salesforce API because once an integration is setup with SOAP, it’s generally rock solid and requires very little maintenance.
There’s quite a few things that can be done within Salesforce using the SOAP API, that aren’t always obvious. For example, the AJAX toolkit which can be used create and update records in JavaScript is actually using it.
MetaData API
The Metadata API is used for updating metadata. It’s usually used for visualforce pages, apex triggers and classes. Up until recently, a lot of IDE’s used the Metadata API to do changes. I believe the MetaData API is the second oldest API that Salesforce provides, it’s also SOAP based.
Apex SOAP API
The Apex SOAP API allows different apex methods to be made available using SOAP. Basically, custom methods you create can be called from within Salesforce or available externally. Basically, any apex method annotated with @WebService allows it to be called. I don’t think people are generally creating these too often anymore because Salesforce has made it possible to create custom REST Endpoints which are a lot easier to implement in most languages.
Tooling API
The Tooling API offers both REST and SOAP endpoints, and in a lot of cases, you might say it’s replaced the MetaData API. The Tooling API was designed to make software development, maintenance, and deployments easier. If your company is using Continuous Integration with Jenkins or something else you are most likely consuming the Tooling API. The Developer Console, and the Force.com IDE are both using the Tooling API in a lot of ways.
Bulk API
The Bulk API allows for much larger volumes of data to be imported in a single batch than the SOAP Api does. The Bulk API is a REST API and allows for records to be asynchronously processed in batches. Tools like Workbench use the Bulk API.
The Bulk API makes a lot of sense if you will be constantly importing thousands, if not millions of records frequently. If your company is only going to be importing or manipulating records infrequently it probably makes a lot more sense to just use the dataloader.
REST API
The REST API works a lot like the SOAP API, in that it’s primarily used for querying and manipulating data. The REST API usually makes a lot more sense to use than the SOAP API does although most older ERP and Finance Systems usually support SOAP over REST.
Streaming API
The Streaming API is an API designed for better performance and using less of the API limits. The Streaming API basically works by sending messages to a topic which your code can listen to about data changes. If your company is going to be data syncing, it usually makes more sense to use the Streaming API to get notified of data changes than to constantly poll Salesforce to see if there’s changes.
I haven’t really used the Streaming API, although I’m familiar with the concepts from using Amazon’s Simple Notification Service and using different notification providers like PubNub.
When deciding what API to use, make sure you understand the API limits and what can happen if your org goes over them. In some cases, it may cause all of your company’s integrations to fail.
