Salesforce API's Explained
Have you been lurking around Salesforce and heard whispers of API's? Perhaps you're a developer, and like me, have been searching for a concise summary of the different API's offered by Salesforce. Whatever the reason, welcome to the blog (yay!), where today we're answering what an API is, what API's Salesforce has on offer, and which one should you choose. Let's jump right on in.
What is an API?
API stands for Application Program Interface. This means it's the way that you will interact with an application. A great way to think about API's is as a doorway connecting two applications. In one room let's say you have your interface for an app your building, and in a neighbouring room you have your database with all the juicy data stuff. In order to connect the two together, you need an API - a door. Otherwise there's just a great big wall in-between the two. Not very useful.
Now Salesforce, as we know from our 'What is Salesforce' blog post, is just a great big online database. This means having an API would be very useful for getting specific or very large amounts of data. But hold on. Why do we need an API in the first place? Surely we can get everything we want from the Salesforce interface without all this mumbo-jumbo? And why are there so many different types of APIs for Salesforce? Do not fret my friend, all shall be revealed.
Why do need an API for Salesforce?
Firstly: API's are important for keeping data up to date. Imagine that you want to get all of the custom fields from all accounts in Salesforce but there's no API. To get this information, you might have to contact your Salesforce admin and ask for a copy of that data. They could send you a spreadsheet or a list, but it would very quickly get out of date. A much better solution would be for you to have your own query, or door into that data. That way, you can access it anytime you like and it will always be up to date.
Secondly: It gives you, a nifty Salesforce developer (or soon to be, am I right) the power to manipulate the data however you like. This means you can take data from Salesforce and put it in your own code or applications. This is great for super customised use or summaries. SO MUCH POWER.
What types of API's are there?
Salesforce has a whole suite of API's:
-
SOAP API
-
REST API
-
Apex REST API
-
Apex SOAP API
-
Bulk API
-
Metadata API
-
Chatter REST API
-
Streaming API
-
Tooling API
In this article, we are going to be covering just two of the most popular ones: SOAP API and REST API.
REST API
WHAT IS REST?
The name 'REST API' comes from RESTful web service principles. It stands for REpresentational State Transfer, and was originally introduced as a way to help build large-scale distributed web systems. A heap load of modern companies use RESTful services, including Twitter, Amazon, Facebook, eBay, Yahoo, Wikipedia, and Google. What sets RESTful services apart from previous services such as SOAP, is the high level of abstraction which makes is extremely scalable. It also blends very well with HTTP protocol, which is continues to gain popularity. According to (Pautasso, Zimmermann, & Leymann, 2008) RESTful services are based on four key principles:
-
Resource Identification through URI - Any data or resources you want to get using REST API's can be done using URI's. URI's are just fancy ID's for different sets of data. Did you know that a URL (like www.google.com) is actually a form of a URI?
-
Uniform interface - REST uses a fixed set of CRUD (create, read, update, delete) commands
-
Self-descriptive messages - Data can be mainpulated using REST into heaps of different formats such as HTML, XML, plain text, PDF, and JPEG.
-
Stateful interactions through hyperlinks - Every interaction in REST is stateless, which means that requests are self-contained. This helps developers to decide their own states for requests which will help to point the code to valid future states.
Overall the major reason that REST API's are so popular today is because they work extremely well with existing well known standards such as HTTP, XML, and URI. It's easy to use for developers since there's no need to build custom client-side software. It also scales well due to built in support for caching, clustering, and load balancing. Finally, it provides good opportunities for optimisations due to the many lightweight messaging formats (JSON, plain text).
REST IN SALESFORCE
-
Great for web and mobile apps
-
Allows CRUD (Create, Read, Update, Delete) + searching + querying + org limits
-
Supports XML and JSON
-
Works well with JS and React
-
Lightweight and inexpensive to use
-
Low effort from developers; no need to develop custom client-side software
-
Weakness: confusion on best REST practices
SOAP
WHAT IS SOAP?
SOAP stands for Simple Object Access Protocol and is the big brother of REST. Unlike REST which has options for JSON and plain text messaging format, SOAP only uses XML. It can do everything REST can do and a little bit more. It has more options for customisation, but is not as easy to pick up straight off the bat. Like REST, there is no concept of state in SOAP services. One of the big advantages of SOAP is protocol transparency and independence. When data is transferred using SOAP (ie. has a SOAP header) and is being handed through a variety of middleware systems, aspects such as encryption and reliable transfer can be made independent from the systems the data is going through. SOAP also separates business and technology requirements from the machine-processing requests, making it great for legacy systems which might not always use Web-friendly protocols.
SOAP IN SALESFORCE
-
Great for server to server interactions
-
Suited for big cooperations that might have legacy systems
-
Uses a Web Services Description Language to define parameters
-
Supports XML only
-
Better for large amounts of data than REST
-
Weakness: harder to set up initially, steeper learning curve
References:
Pautasso, C., Zimmermann, O., & Leymann, F. (2008). RESTful Web Services vs. "Big"' Web Services. Proceeding of the 17th International Conference on World Wide Web - WWW '08. doi:10.1145/1367497.1367606