Meet Pat Patterson, Developer Evangelist Architect at Salesforce. Patterson lives within the developer community, explaining to developers how to build applications that run on, or integrate with, the Salesforce platform.
ALL THINGS API INTERVIEW WITH PAT PATTERSON, DEVELOPER EVANGELIST ARCHITECT AT SALESFORCE. You may have see him on stage at 2014’s Dreamforce and Kin Lane’s API Strategy event, as well as conferences like Defrag & Glue.
Read the All Things API Series Also as a developer advocate within Salesforce, Patterson is bringing insights and concerns of the community to product management and R&D. The Global Developer Evangelism team is the bridge between external developer community and the development team at Salesforce.
Q: How did you get to where you’re at today?
A: Most of the preceding decade I was at Sun Microsystems. At Sun, I was working on OpenSSO, a single-sign on/web access management project. I was the community lead on the open source project. The whole area of identity and access management overlapped with Oracle’s product line, during acquisition I left. I spent a year at Huawei before joining Salesforce in 2010.
Q: Why are the 3 I’s [Identity, Integration and Internet of Things] top of mind?
IDENTITY: Identity is really core to every interaction to any online system. Even if you just using Salesforce from browser, you login. You have account, you have permissions, there is policy that says what data you can see, and what data you can modify.
The nature of identity management extends very naturally to integrations and world of APIs. If you have an app that calls to Salesforce, you want to authenticate into the their identity. You want to know who’s calling and what they want to do. You get to grips with protocols like OAUTH for authorizing applications access to APIs.
INTEGRATIONS: Salesforce has a rich set of APIs, doing them since 2004. We had first started with a RTC API, then SOAP, and when I joined in 2010, the REST apis were released. So I’ve seen the APIs really mature over the years.
The REST API is our effort towards of record by record access. You can update individual records, you can run a query and get back a set of records. With the SOAP APIs, you trade off the simplicity of REST for the power to work with collections of records. You can update a whole set of records in one API call.
The Bulk API is oriented towards bulk operations such as uploading and downloading many records. Basically it’s enabling users who have hundreds of thousands of transaction records that need to get into Salesforce, you would use the Bulk API directly. It lets you upload that raw data and then get a token back. You send the token and Salesforce will tell you if the import succeeded or failed. You can run that asynchronously to determine whether the import was successful, whether any records failed validation, etc.
The Streaming API allows you to get notifications from Salesforce of events within the system. You can subscribe to the notifications from an app based on events. For example, if an opportunity is closed, then the app can trigger some activity in another system.
So we have a whole collection of APIs that really enrich the developer experience in building with the Salesforce Platform.
INTERNET OF THINGS: Internet of Things is really exciting. I started getting into IoT 2 or 3 years ago when people started hooking up devices to Salesforce. One of the first examples I saw was a developer named Kevin O’Hara hooking up a flashing light to the Salesforce API so that when an opportunity closed, a light would flash in the office. Very simple, kinda fun. Going from there, we would see use cases like, a device that can detect a fault, like the temperature goes out of bounds. When that fault happens, a case in Salesforce Service Cloud would be opened. The power there was that the devices would open cases themselves, a process would be eliminated for a person to call into support. Really cool to see how the devices are talking to Salesforce
Q: Why is the trend of the industry moving to REST important?
A: So yeah, a huge, industry-wide trend is the move to REST. Salesforce introduced their REST API in the Winter 2011 Release (October 2010). In the 4 years since then, there has been a hockey stick adoption. Anyone that I have worked with that is starting a new project, it’s overwhelming likely they’ll use the REST API. REST is so straightforward and easy to use. You don’t need a library to handle the protocol, as you would need with SOAP.
We’ve gone to an API-first strategy so that we can mobilize our entire company. The intent is that customers can run their company from Salesforce1, our mobile app. To do that, everything in Salesforce has to be available via APIs.
Q: With such a proliferation of APIs, what do developers do to drive adoption?
A: One best practice: When you design an API, write the client first. Put yourself in the external developers shoes, and write the way you would want to use it. Build the API from the outside in.
Consider version one of many APIs, often developers just expose the details of internal fields. Even if it’s passing JSON over HTTP, it’s really complicated. My advice is to think from the outside, “If I want to get something done in an ideal world, what code would I write? Let that drive the design of the APIs, so that the APIs insulate the external developers from your implementation details.”
Q: Are developers open to developing applications with an API-first strategy?
A: YES! The reason is, consider the power and flexibility that it gives to developers. The exposed functionality of APIs generates huge possibilities. A great example is that our APIs give developers access to data and metadata, such as schema and code. This is important for developers: they can create their own schema in Salesforce via APIs and even upload Apex and Visualforce code.
We have a browser-based interface and Eclipse plugin for developers to choose from, but, because all the metadata is exposed, when developers don’t want to use Eclipse, they can choose to use their own interface.
A great example is that one of our community users, Joe Ferraro, created a plugin for Sublime, which pushes code to Force.com. That idea didn’t come from our own product development, but from within our external community. Joe couldn’t push code from his favorite text editor, so he figured out a way to do so using the Metadata API.
Providing that flexibility to our external development community gives them the ability to build integrations that we never even considered within the company.
Q: When considering “All Things API”, what resonates with you?
A: By expanding all things API, we’re able to start making all things available via APIs. We had a saying at Sun Microsystems, “The smartest people work elsewhere.” So if you make those APIs openly available, you’re thus enabling all those smart people.
Q: What’s the next set of challenges you see in the coming year?
A: One area Salesforce is thinking about is Internet of Things and when devices need to have their own identity, rather than relying on humans. It’s a complex theory to start thinking about. Are they going to use existing protocols, are we going to need to create new ones? Let’s say on individual person is managing thousands of devices, the devices will have their own credentials. Smart cars are an easy example. That car will need to have it’s own identity, since you’ll likely allow others to drive it. Multiple people will be associated with a single device. These types of challenges are surmountable, but need some careful consideration to get things right.
Q: Last, what’s a fun project you’ve worked on in the Salesforce Evangelist community?
A: I hooked up Salesforce to Minecraft, a project I called Forcecraft. The purpose was to pull data in from Salesforce and start building a world based on events happening in the CRM. Each time a new account was created, a high-rise building popped up, the floors would account for the number of new opportunities being generated, and the contacts in Salesforce were the people wandering around the game. There would be levers in the buildings to close out opportunities.
Of course the point wasn’t to encourage Salesforce admins to manage their CRM through the Minecraft interface, but rather visualize the power of API integrations.
Read other All Things API Interviews: