If you believe a recent report from analysis firm Gartner, in just two years, we’ll be overrun by citizen developers (normal, untrained computer users) building 25% of new business applications. A major facilitator for these newbies? Some have posited that cloud-based API mash-ups would be so easy to use, toddlers would soon be selling mobile apps. But now, San Francisco’s hottest Platform-as-a-Service company, Salesforce (which recently acquired Heroku), is running toward developers, not away from them. And a key to success, said ProgrammableWeb founder John Musser, is the developer—not user—experience.

Companies like MailChimp or SendGrid (for e-mail marketing and commerce) and Twitter, according to author Pamela Fox, do an amazing job at developer experience. Fox wrote Google’s “Developer Support Handbook” after four years as the go-between for the API developers and engineers for the Maps and Wave APIs. She notes that the experience starts with signing up (though preferably you don’t even have to), and that the more enjoyable it is, the more you’ll see innovative usage and external evangelism by developers.

That evangelism wasn’t hard to come by at Dreamforce. “Everything you see here? It’s all about people building on their APIs,” said Musser, gesturing toward the first-ever developer pavilion at the September 2012 conference put on annually by Salesforce. Musser’s company is a “Yellow Pages,” as he called it, of every API released since 2008, and he had just given a talk describing key API strategy moves.

“This whole building’s worth of stuff is about people using their APIs to build their creations,” he said, pointing to booths from telephony provider Twilio and cloud-based file sharing software company Box, among others. “Every SaaS service worth its salt has them, because APIs are the glue of SaaS. You don’t want to be an island.”

But are citizen developers using them? “Citizen developers? For the majority of APIs, no. What we are seeing is more and more companies consuming a greater number of APIs per company — four, 10 or 12 third-party services. The Salesforce API over here, the Google Map API here,” said Musser.

“On a technical level, I don’t see it happening much,” said Jeremy Glassenberg, platform manager for Box. “I’ve seen tools to reduce the amount of code you have to write, and connector tools, but you’re still expected to write your own code. We’ll see more dev tools to let developers code faster or get more code done, and maybe IFTTT [If This Then That] will gain traction, but I don’t think we’re at a point where consumers are coding.”

Salesforce’s original raison d’être was data-driven CRM applications, often built outside of IT. But the emphasis on developers at the conference made it clear that Force.com is going to be a powerful platform for mash-ups, and that developers are more eager to create and consume APIs than ever.

Salesforce dominated the API news at its own conference, especially around tooling, touch, social and mobile. The new tooling API generated excitement among developers yearning to translate the full IDE experience to Force.com. It joins a raft of existing APIs for Force.com: the SOAP Web Services API, the easier-to-use REST API, the Bulk API for manipulating data, the Metadata API, the Streaming API, the RESTful Apex API, and the Chatter API. Finally, Salesforce Identity was announced as an approach to letting enterprise apps access user context, interact with the social graph and eliminate siloed apps in the enterprise.

Adam Seligman, Salesforce’s vice president of marketing, launched the first developer keynote at this year’s conference, touting the “age of APIs,” the new dev zone, hands-on coding sessions, the app marketplace, and the 9 billion API calls by developer apps that Salesforce has fielded. It almost gets recursive, when you think about it, what with Salesforce customers using Salesforce APIs to build tools with which to build Salesforce apps.

Will they come and build it for you?
Brian Matthews, founder of BrainEngine, is thriving on that recursion. He’s also exactly the kind of developer/customer Salesforce loves. “I came over to Force from using Visual Studio. I haven’t used Eclipse in two or three years. We were just using all the APIs to replicate what was going on in Visual Studio in Salesforce,” he said in his portion of the presentation on the tooling API at Dreamforce.

“We were using every API and special URLs behind the scenes, but the new tooling APIs really allowed us to expand our vision. We’ve written our own custom parsers. Now we can show you classes and methods,” he said to applause at the show. Things like messages that tell you “when the method is expecting a string, you’re trying to pass in an object, or simulate stepping through your code; those give you more of that feel that I was used to from Visual Studio. Now that they have the tooling API, it helps us be able to set the breakpoints, view debug logs in our own live version as well.”

Interestingly, Matthews’ demo seemed to excite the audience even more than the proposals for a full-featured developer console with IntelliSense, refactoring, query data and testing features from Salesforce itself. “This is exactly what we want to see: people making Salesforce better,” said Josh Kaplan, senior product manager.

The features that Matthews described aren’t new to IDE users, and some of them, like the not-there-yet ability to rename methods, aren’t exactly cutting-edge. But they did make developers feel valued. “We’ve taken the things that come with the tooling API, and we’re matching things up in the execution log so they render out,” he said.

“We allow you to access all your heap dumps. You can also add a new monitored user and look at their logs and see their information during runtime.” And the motivation to build this VS clone was simple: “We build Salesforce solutions every day.”

But will the race to build a genuine IDE story for Salesforce be fast enough? At Microsoft’s Visual Studio 2012 launch earlier in September, corporate vice president “Soma” Somasegar, facing the same multi-device imperative, touted a 12% improvement in time to market for its customers using the venerated IDE. Internally, Salesforce is agile, while Microsoft’s external tools are just now fully embracing agile practices. Salesforce needs developer buy-in to choose their cloud for data-driven enterprise apps, while Microsoft must convince developers of its currency for consumers in a modern, connected app world with no clear mobile platform winners.

To be sure, Redmond reaches a far larger population than Salesforce’s claim of 800,000 developers, and Microsoft offers both PaaS and traditional software. But it’s interesting to watch both grapple with the same issues of development speed and consumer mobility.

Make mobile your excuse
Outside of the Salesforce bubble, many companies are wondering how to get started with their own APIs. Mobile is proving to be a major motivation. National Public Radio, for example, uses a private API to internally develop mobile apps, while offering a public API with limited content rights that serves billions of stories per month. “In our experience, the biggest and most far-reaching impact of many private APIs is when companies use their API internally to build public apps,” wrote Daniel Jacobson, Greg Brail and Dan Woods in “APIs: A Strategy Guide.” “Using an API in this way tremendously increases efficiencies in extending products or features for customers. At a time when many companies are struggling to produce iPhone apps, companies with APIs have already released multiple versions of iPhone, Android, iPad and other mobile apps.”

“Just looking at the market today: Mobile is the big thing. For any SaaS company, after you write your platform, next you write the mobile app,” said Box’s Glassenberg. As a result of the mobile imperative, SOAP is becoming less popular, he said. “I was the first guy to write about Salesforce’s plans for REST APIs. Simpler is better, and RESTful is the craze of the day. SOAP is still there, but I see it more as a COBOL-ish thing. I do understand there are some benefits to the weight.”

But beyond questions of RESTfulness, the mobile, multi-platform opportunity is perfect for API-first development. “Current interface-first development processes create problems when developing complex service-oriented or multi-platform applications,” wrote Evan Tahler and Fiona O’Donnell-McCarthy at api-first.com; the two previously worked together at clothing retailer ModCloth. “Interface-first design favors simple MVC applications, which are meant to run (compile) on a single server. Interface-first development methodologies favor a single platform and cause problems when branching out.”

The API-first approach aligns around actions, which allows for reusability, simultaneous iteration cycles for front and back ends, and ensures that the app is data-driven.

If API-first development takes off, API makers and consumers are still wise to heed Pamela Fox’s advice. Too often, an API is passed over because its community pages are empty and support is nonexistent. Developers do want hand-holding when they use your API. That includes not only easy signup, but also guides, searchable reference materials, SDKs, pricing and clear terms of service. There has to be a community: a forum, blog, social media presence, e-mail list and an app gallery. There has to be evangelism and great support. And all of it can feed back into the API.

“Does API design impact support? Yes it does,” said Musser. “Take a look at Twilio’s error response. There’s a lot of detail in this 400-level response. The provider gives you, the developer, a link to where to go to research this error message.”

Poor error-handling is last, in fact, on Musser’s top 10 API worst practices, which are:

10. Poor error handling
9. REST APIs that ignore HTTP rules
8. Exposing your raw underlying data model
7. Security complexity
6. Unexpected and undocumented releases
5. Poor developer experience
4. Expecting an MVC framework automatically means you have a great API
3. Assuming that if you build it, they will come
2. Inadequate support
1. Poor documentation

“If you expect that because you use Rails you have an API, you don’t. What that is doing for you is you are exposing your raw data model. You have to work back from your use case that developers have,” said Musser.

DocuSign’s Mike Borozdin, director of integration development, recently blogged about creating a “Rubik’s Cube of development scenarios. We heard that while we had the most comprehensive set of functionality, it was sometimes hard to figure out how to get started. So we created a grid of the most popular scenarios that our customers and partners implement. When you click into a scenario, you get a high-level overview of the sequence of calls that your program will need to do. If you click on one of the steps, you will see a code sample with a detailed explanation for the key parameters. The feedback from our initial testing is that it’s much easier to get going and incredibly fast.”

And there are other things to think about: Throttling to prevent abuse or excessive load, but also possibly to meter the API for monetization. And also security, whether it’s OAuth 2.0 (“gaining traction,” according to Musser), requiring SSL (“The major APIs are moving to SSL only,” he said), OpenID Connect (“very early”), or two-step verification like Google does (“That’s brand new; there’s very little of that”).

Ultimately, Musser said, “A great API is a journey, not a destination. Salesforce isn’t done.”

Glassenberg agreed, noting that developers will want to start that journey as early as possible. “If your platform is going to be a significant part of your business, you want to pursue the API-first approach,” rather than hacking it later, he said.

He admired the work of Borozdin, and pointed to other API inspirations: FreshBooks, Twilio and Flickr. Meanwhile, Box is working on making its APIs more RESTful. “We invested heavily in APIs, but we started years ago. If you have a successful API, you have to keep talking to developers,” he said.