Can you trust your API provider?

In just a few short years, the number of 3rd-party APIs on the web has exploded. Everywhere you look, it seems like just about every important service and app these days has an API available for developers to tinker with.

But can you trust them? How do you know that an API provider is serious about their supporting their developers and won't change things on a moment's notice?

I've spent the vast majority of my career - almost 25 years now - building and promoting developer platforms. I even had my own software company for a while where I was the consumer for an API platform that I myself had helped build, so I've been on both sides.

In this post, I've put together a series of questions that you can ask yourself before you fully commit to an API to try and gauge how much you can trust it - and the provider. Now, I'm going to invoke professional courtesy here and not call out any third parties by name since I work for Google, but I will use some instances from my personal experience to show what I feel are good examples of API stewardship.

An API that doesn't directly support a provider's revenue or strategic goals can be more easily curtailed or changed by the provider if it begins to go in a direction that they don't like.

1. Does the API directly support the provider's revenue stream or strategic product goals?

This criteria is important, but not always easy to assess. Let's take a few Google examples for illustration (again, full disclosure here - I work for Google). The Drive API directly supports Google's main goal for Drive - that is, to increase the adoption of Drive. To that end, the Drive API gives pretty deep and wide access to the service, and makes it easy for developers to integrate directly into the Drive UI itself. Google even calls out apps that use Drive in the Chrome Web Store.

Another good example is Apps Script, the API for Google Docs. Here again, the main motivation for Apps Script is to enable developers to create features that Docs itself doesn't yet provide or address scenarios that are too niche for Google to spend much time on, thereby increasing the appeal and adoption of Google Docs.

In both of these cases, the API exists to further a strategic goal - the adoption of the product in question. As such, developers that adopt the API help further the strategic goal, ensuring that the interests of both the developer and the provider are aligned.

An API that doesn't directly support a provider's revenue or strategic goals can be more easily curtailed or changed by the provider if it begins to go in a direction that they don't like.

2. Does the API give you access to "the good stuff"?

This is also a pretty good indicator of how much you can trust the API. If an API only provides superficial access to data or capabilities that really aren't that valuable, then you have to wonder about the intentions of the provider or what they might do in the future.

APIs that give rich, deep access to the important features of a service or product indicate that the API provider cares enough to think through how the API will be used and to devote engineering resources to the development and maintenance of the API.

An API that only gives you the ability to develop ancillary, convenience features - what I call a "vanity API" - is a pretty good signal that the provider doesn't have a big commitment to the API or to its developers. It's a lot easier to close off an API that doesn't have deep hooks into the underlying service than it is to change one that's going to affect a lot of customers down the line.

Even if the provider doesn't close off the API, the risk is that you're just serving as a free R&D resource for them. If you make a convenience feature that's popular, there's nothing stopping them from just copying it and rolling it into their core service. Caveat developer.

3. Is the API being actively developed, with a vibrant community?

An API that is receiving regular updates and has a large, active community on Stackoverflow or other forums is generally going to be more trustworthy than one that doesn't.

Regular updates that include new features, samples, and bug fixes demonstrate responsiveness and attention from the provider, and an active community shows that there's a well-worn path where you can get support from sources other than the API provider.

4. Are you able to make money using the API, without the provider interfering?

This one is huge. If the API provider puts unnecessary or onerous restrictions on how you're able to charge for your product, then that's a big red flag on how much you can trust the API.

QuarkXPress sold for $895 at retail (back in early 1990s dollars). I kid you not, we actually had a plug-in developer who charged $75,000 for their product (now, obviously, this was not a consumer-facing thing. In this case the product was for large Atex pre-press systems). Did we care? Hell no. We thought it was awesome that someone was able to sustain a business like that on top of our platform. Of course, most of our developers charged a lot less, but the fact that someone was charging 100x our product's price was not a problem for us.

Now, you might have to upgrade your API usage to a paid subscription in order to make your own product charge-worthy, but that's actually a good thing - a provider that charges for enhanced API service is entering into a contract with you, which in turn makes it harder to change or discontinue that API.

5. Does the API Provider itself use its own API for shipping features?

This criteria is a bit asymmetric - if they don't use their own API for their features, that's not necessarily a bad thing. But if they do use it for their own features, that's a powerful indicator that they've got a big incentive to invest in the API.

When I worked on Dreamweaver and then later on Microsoft Visual Studio, one of the things we were most proud of was the fact that we used our own API to deliver new features in the core product. It sent a strong message to our ecosystems that we cared enough about our API that we used it ourselves and considered it solid enough to deliver core features to our users.

6. Does the API Provider actively promote its developers?

Again, this one isn't necessarily a very strong indicator, but it helps to know that if you build a product that's based on an API that the provider will be there to help you promote it.

On the other hand, If a provider is squeamish about promoting its developers, that can be a bad sign. Ideally, you want to have a company that cares enough about the success of its API that it isn't afraid to call out developers who build great products on top of their platform.

Summary

Third-party APIs can be a great way to leverage the features of services that you don't want to have to build yourself, allowing you to focus on the value proposition of your product. Relying on them, however, introduces a certain level of risk. Hopefully, by asking yourself the questions that I've posed here in the post, you can minimize that risk and build a successful product.

In short, look for:

1. APIs where your interests and the provider's are aligned
2. APIs that give you access to the valuable, interesting stuff
3. Active development on the API with a great, supportive community
4. The ability to make money without draconian interference from the provider
5. A provider that uses their own API for new features
6. A provider that isn't afraid to promote great developers and apps

Now, to be clear, the answers to these questions aren't foolproof, iron-clad guarantees that you can trust an API to be there over the long haul or that the provider won't change things (or rip out the rug from underneath you). But if you think about these issues up front, they can help you avoid relying on API services that one day suddenly change their mind about your value to them as a developer.

Building a Customized News Service with Google Apps Script

A big part of my job involves staying on top of current technology events and news. There are several technology-related news sites that I read daily, and typically I scan them first thing in the morning for anything I consider to be important before reading other items of interest. It’s a bit tedious to open each site and read all the individual stories for the ones I care about, and even the blog readers I use aren't well-suited for a quick morning summary of important items.

I've been playing around with Google Apps Script for a while now, and I’m pretty impressed with the versatility and power available via the APIs coupled with the simplicity of creating and running scripts. So, I decided to see if I could write a script that would scan the news sites I read each morning and deliver a customized news feed to my Gmail inbox, along with a summary of my day’s calendar. I was originally going to try the same thing with AppEngine and cron tasks, but it turns out Apps Script is more than enough to handle this job. I’m pretty happy with the results, and in this post I’ll discuss how I created the script.

Overview

The script itself is pretty simple: it scans a set of news feeds, creates links to the stories, scans the headlines for specific words, and calls them out separately from the rest of the news. It also reads my calendar for the day’s events and tells me if I have any upcoming events that I have not yet RSVP’d to.

Getting started with Google Apps Script development is pretty easy; just make sure that you have a Google account, are signed in, and visit script.google.com.

To get this script to work, there are a couple of things you'll need to do:

1. Enable the Calendar API. From within the script editor, select Resources -> Advanced Google Services, then enable Calendar API.
2. You also need to enable the Calendar API from within the Google Developers Console. There's a link to do this in the dialog in step 1.

What It Looks Like

You create scripts using the Apps Script IDE, which is of course hosted in the cloud. It's not exactly Eclipse or Visual Studio, but it's very functional and gets the job done:

[click image for a larger view]

When the script is run, it delivers an email to the address of whoever the person running the script is. The screen shot below shows what the resulting email looks like:

[click image for a larger view]

At the top, I have my daily events including ones that need my response, followed by my curated top stories, then the rest of the news items.

The script relies on some global settings to work, which I've listed here:

The main function of this script is called deliverNews(). It looks like this:

The deliverNews function does several things:

1. Reads the Calendar for the day's upcoming events
2. Checks the week ahead to see if there are any events I have not RSVP'd to
3. Reads the news feeds and builds the Top Stories list
4. Puts the rest of the news stories into their own sections

Reading the Calendar

Let’s start by looking at the code to generate the calendar summary. The Google Apps Script API has an advanced service called Calendar. This service is a very precise wrapping of the actual Calendar REST API itself.

To get the events for the upcoming day, I use the Calendar service to retrieve the events using time bounds and a setting to expand recurring events into single instances:

The getEventsForToday() function returns a list of Event resources. I then just need to scan each event for the title, URL, and date and build the resulting list:


You’ll probably notice that I wrote my own convertDate function to generate a Date. Why? Because Apps Script returns dates as ISO Date strings. In ECMAScript 5, you can pass ISO Date strings directly to the Date() constructor to create a date, but as of this writing the version that Apps Script appears to be using doesn’t support this, so I made my own:


Next, I need to find events that I have not RSVP’d to. I use the Calendar service to retrieve events for the current day, then scan each one to find the attendee record that corresponds to my email address. If found, I check the responseStatus feed, which will be "needsAction" if I haven't responded to it:

Getting the News

There are two parts to this portion of the script - one is getting the news headlines and generating the categorized results, the other is extracting the headlines that are important and elevating them to the Top Stories section. To do this, I use the UrlFetchApp service to retrieve the data content, then the XmlService to parse each feed.

The code uses UrlFetchApp to read each feed and XmlService to parse the result into a document tree that I can use to extract each item’s title and link. Right now, the script only parses RSS 2.0 feeds, but since practically everyone supports that format, it’s what I decided to code to. Adding support for ATOM would be easy enough as well.

Now, by itself, this would result is a pretty large set of headlines, and I don’t want to have to scan each one to see if it is important. Instead, I have the script look at each headline for a set of keywords that I’ve defined. If a headline contains a keyword, then that headline is put into a special array. If the headline didn’t contain a keyword, it gets added to the feed’s category normally.

Sending the Email

Now all that’s left to do is send the email. The GmailApp service is used for this, and it provides the ability to send an email with HTML content. Let's revisit the last part of the deliverNews function:

At this point in the script, the string variables calEventsStr, topStoriesStr, and feedsStr contain the HTML code for each of the sections. All that’s left to do is put them together into one result and send that content via the GmailApp.

Automating the Script

Now I have a script that can be manually run whenever I want to generate the email, but that’s obviously not ideal. What I really want is a script that runs for me on a pre-set schedule. Google Apps Script makes this possible by enabling what are called “Triggers”.

I want my email delivered to me every morning before I wake up. To do so, under the Resources menu, select “Project Triggers”. This will bring up a dialog that lets me set a timed trigger:

[click image for a larger view]

In this case, I have my Trigger set to run daily between 6 and 7 in the morning. That’s really all there is to it - you just choose the function you want executed and when you want it run. Apps Script does the rest!

The full script code is available here if you want to download it and modify it for your own needs.

Are Chromebooks the Future of Computing?

I was recently pointed to this article on Tech Republic, which asks if Chromebooks are the future of computing. I’ll come back to that question in a bit, because I want to address the larger, more encompassing one first - are lightweight, web-centric operating systems the future of computing?

Haven’t we been here before?

Let me preface the rest of this post by saying that I’ve been in this industry for some time now - almost 25 years. I can remember when computers were machines that you had to get into via a terminal, such as VT100, often over a dial-up line. Then, along came the desktop computer, popularized by the Apple II and IBM-PC, and the tech press of the time trumpeted that individual personal PCs were the "computers of the future". And for a while, the pendulum swung away from mainframes, and personal PCs ruled.

And boy, did they rule. Just about every electronics company had their own PC: Texas Instruments (Bill Cosby was even their spokesman), Atari, Panasonic, Commodore, Acorn… the list is too long to enumerate here. Eventually, though, there was a shakeout, leaving just Apple and the PC clone industry.

Then the web came along, and the pendulum started to swing back toward server-centric computing, with the client (in this case, a browser) playing a lesser (though still significant) role in the user's computing experience. The idea of having apps and data accessible from almost anywhere once again became vogue, and we even had a massive investment bubble to go along with it.

Here we are once again though, with personal devices delivering a very rich, local computing experience while connected via a cloud-backed service. Today's devices, whether they are iPads, Android tablets, or laptop PCs, work great when offline but truly shine when connected.

That, I think, is the far more important lesson to be learned here rather than whether one platform or another is the "future of computing." The key thing you need to focus on is the trend, not the current state of where things are.

What Do "Most People" Really Need?

Stop and think for a moment about what tablets (whether iOS or Android) do and how they work. They don't have a generally accessible file system in the sense of normal PCs. In fact, they don't have several of the characteristics of what you would call a traditional fully-featured computing device. Most of them aren't expandable, they don't have as much RAM as traditional laptops, there's no mouse, most don't have a physical keyboard, and yet these things are flying off the store shelves. Why? Because they perform almost all the functions that most people need on a daily basis, and they are great second- and third-devices to complement a home's primary computer. They send and read email, play games, take photos, play videos and music, compose documents, etc.

Now, wait a second - don't most of those characteristics sound like Chromebooks? The only difference was that most apps were Web apps, but that all changed last September when Google added the ability to install local, offline-capable native apps on Chromebooks.

When Chrome Apps happened, the last real remaining barrier to Chromebook adoption fell away. The Web is always introducing new features, and since Chrome updates every 6 weeks, a Chromebook owner always has the latest runtime and all the new features to go with it. Developers don't need to wait very long for end users to have the capabilities to run the latest apps, and since Chrome also runs on Windows, Mac, and Linux, the addressable market is huge.

Back to the question

So, are Chromebooks the "future of computing"? I don't know, and I don't think anyone else knows for sure, but what I do know is that consumers have clearly voted in favor of computing that is simple, secure, always-up-to-date, and works wherever they are. Tablets clearly fit that bill, as do modern smartphones, and increasingly, so do Chromebooks.

"Ah", you say, "but didn’t we go through the era of the netbook once before?" My answer to this is simple - Chromebooks aren’t netbooks. Again, let's go back to what made the iPod, then the iPhone, then the iPad super-successful: the ecosystem. People don’t buy "devices" anymore. They buy ecosystems. Consumers want to know that if they buy a particular platform they won’t need to worry about whether it will be supported or whether they can get what they need for it - both in terms of software and accessories.

The main problem that netbooks had was that there was no ecosystem - there was no central software store, no predictable update schedule, no place to bring your device when it was on the fritz, and your friends had different machines so it was hard to share their content.

Chromebooks don't have any of those problems. There's a full, rich ecosystem in the form of the Chrome Web Store, the Web itself, and even Google Play (Chromebooks can play all your Play content like movies and music). There's a set of big, established players supporting them. Content is now vastly standardized, and all your favorite Web apps work just fine (Chromebooks even support Flash, without the security hassles).

Now, sure, they aren't for everybody - but neither were the earliest personal PCs. You had to be a pretty savvy user back in the days of the IBM-PC and even the Apple II. Chromebooks don’t yet fit the bill for people who need to do heavy development or who need to run complex systems, but all of that is just a matter of time. Remember - a lot of the criticism you hear about Chromebooks was similar to what was leveled against Gmail ("no enterprise would ever use that!") and Android ("that ecosystem is way too fragmented!") and Google Docs ("it’s not Office!").

The future of computing is one in which the user is the center, not the device. Operating systems that get out of the way, not ones that insert themselves between you and your work. Simplicity, not complexity. Security, not anti-virus programs. So far, Chromebooks fit all of those. But even if Chromebooks themselves turn out not to be the "future", the directional trend itself is pretty clear.

Don’t be the frog in the pot

Before closing, I want to remind everyone about the parable of the boiling frog. The story is simple, for those of you that haven’t heard it - essentially, if you put a frog in a pot of boiling water, it jumps out right away. But heat the water gradually enough, and the frog will slowly boil to death, unaware of the drastic changes in its surroundings because of the slow nature of the change. The story is somewhat apocryphal, but it’s an apt metaphor for people who aren’t willing or able to notice the changes around them and adapt.

With that in mind, consider the following timeline:

• 4 years ago, Chromebooks didn’t exist.
• 3 years ago, Chromebooks were just a curiosity. Back then they didn’t even have a proper desktop or windows - only browser tabs. Many people wondered what they would ever be useful for.
• 2 years ago, Samsung’s Chromebook suddenly started dominating Amazon’s top-seller list, and Google announced that over 2,000 school districts had adopted Chromebooks. People said "well, for some consumers they make sense, and schools clearly benefit from these devices, but they’re not for mainstream users."
• Within the last year, Chromebooks were in over 5,000 schools, the Pixel was demonstrating what a high-end Chromebook could be, there were 3 new OEMs making Chromebooks, and you could buy them in a variety of mainstream stores. Oh, and Microsoft finally took notice and decided to start advertising against them.
• Today, 6 of the top 15 best-selling laptops on Amazon - almost half - are Chromebooks. Every single OEM that makes a PC has now signed on to produce Chromebooks. Even HP, whose CEO Meg Whitman has said "Chromebooks have surprised us", is now making two models (so far!). There are new Chromeboxes on the way, and even enterprises are starting to replace their existing PCs with ChromeOS devices. The Chromecast, which runs a simpler ChromeOS, has literally taken off.

Focus on the trend, not the current state of the world. The water is starting to boil, folks.