Kin Lane

Rise of Mobile Backend as a Service (MBaaS) API Stacks

Mobile is fueling a lot of API growth right now. Or is it APIs fueling a lot of Mobile growth right now? Either way, APIs and Mobile go together like chocolate and peanut butter (or Nutella as my girlfriend would say).

With this growth in mobile, we are seeing a rise of Mobile Backend as a Service (MBaaS) providers, delivering a basic stack of storage, messaging, notifications, user management and other essential components for mobile developers.

The goal of MBaaS providers is to make it very easy for developers to setup and operate a backend for any application. After delivering the essentials like storage, messaging access, push notifications, etc., it makes sense that now developers will need easier integration with the data and resources available in web APIs.

MBaaS provider Kinvey is doing just that. Using ql.io, a declarative, evented, data-retrieval and aggregation gateway for HTTP APIs, they are bringing web APIs to developers, like GeoPlaces data using Google Places, product data from Ebay’s Product API and social data using Twitter.

Kinvey is baking in the most popular and valuable web APIs right into the Kinvey SDK, making data from APIs as easy to access, as data in your local Kinvey data store. Kinvey will deliver an abstracted layer on top of each API, storing data into tables, making them accessible using common queries like SELECT, FROM and WHERE. They will even let you do JOINS on multiple data sources, allowing you to mashup and improve API data performance.

Kinvey will take on the heavy lifting associated with the differences between APIs and maintain access between different API versions. I’m assuming with the amount of work involved, Kinvey will be only delivering the most valuable of web APIs or at least the most stable.

Sounds like API owners need to start building relationships with Mobile Backend as a Service (MBaaS) providers, as this might be the doorway to the next round of growth in your API adoption. Especially if MBaaS providers can truly make APIs a more local, native experience for mobile developers.

Thoughts For Federal Agencies About to Deploy Web APIs

I wanted to publish some thoughts, on what Federal Agencies responding to the Executive Order 13571 issued on April 27, 2011, and the White House CIO’s, “Digital Government: Building a 21st Century Platform to Better Serve the American People” strategy should be considering.

These thoughts are in the business and marketing aspects web API deployment, with light thoughts in the technical areas. My speciality is not with technical deployment of APIs, I recommend agency leaders visit API-Craft, an industry forum with some seriously smart API industry leaders discussing the finer, technical points of web API deployment.

Where I would like to share some thoughts is in the business of deploying and managing Federal Agency APIs. Insights evolved over 20+ years in the technology field, but exclusively spending the last 2 years studying the business of popular APIs like Twitter and Facebook, and larger API providers like Google and Amazon Web Services.

I’m sharing my thoughts, not to benefit any company, but because I strongly believe in the transformative powers of Web APIs. Web APIs have the power to change the way our Government operates both internally, and with the public. Barack Obama’s mandate, “requiring agencies to establish central online resources for outside developers and to adopt new standards for making applicable Government information open and machine-readable by default”, marks an important point in history.

We can’t screw this up!

While much of the discussion around this announcement on Twitter, Reddit and Hacker News is positive, there is a lot of skepticism around whether the government can succeed. With this post, I wanted to share some thoughts on the essential building blocks we’ll need to make this work.

Technical Building Blocks
I will only speak lightly on essential technical building blocks that need go into Federal Agencies Web APIs, but there are a couple I consider essential:

• Access - Idenitying proper access levels for web APIs, leaving open when possible, requiring keys when needed and implementing oAuth when it makes sense give users control over which applications access their data
• REST - The dominant approach to deploying web APIs, building on top of the existing structure of the World Wide Web. REST has proven to robust enough for most any web API while keeping it simple and intuitive for access by a wide audience
• JSON - I’m not advocating for getting rid of XML, but JSON is the accepted standard for API communication. JSON needs to be adopted as the default for federal agency web APIs

There are plenty of other technical considerations, but I’ll leave that for other experts to deliver on.  Next lets get users, onboarded and using each agencies APis.

User Onboarding
There are a lot of challenges for the average web API developer faces when trying to integrate, initial onboarding has to be quick and painless. There are a couple of essential building blocks that assists in user onboarding:

• Landing Page - A single landing page for everyone to access federal agency APIs, providing single click access to everything you need to get up and running with the API
• Self-Service - API access needs to be self-service, enabling anyone to discover and integrate 24 / 7 without assistance from any agency staff
• Account Management - Allow users to quickly register using common single sign-on using my Twitter, Facebook or Google accounts, and provide users with easy to understand account, key, application and API usage management tools

Next for a developer to successfully go from onboarding to, API integration, it will require an essential set of resource building blocks providing everything they need to understand the API interface, and begin using:

• Authentication - Give users a quick introduction to API access including which endpoints are open, keyed or require oAuth for usage. Also provide links to support technical information about authentication
• Documentation - Provide simple, complete and up to date documentation for every Web API endpoint.  Also consider deploying interactive, smart documention using a technology like Swagger
• Code Samples - Provide sample code for each API endpoint in all the common languages including PHP, Python, Ruby, .NET, Perl, Java, Objective-C, all provided as Github repositories
• Starter Kits - Provide as many ready to code sample applications and starter kits to show developers what is possible, all provided as Github repositories
• Mobile - Provide mobile specific code samples, SDKs and other resources supporting mobile specific development

After you’ve provided the essential technical, onboarding and resource building blocks, you need to make sure your your agencies API area has the necessary communication building blocks, allowing you to effectively communicate with users about your API, but also give your users a voice in API operations:

• Blog - A blog is an essential communication tool in API ecosystems. Make sure the blog is active, and provides an RSS feed
• Forum - A forum will provide a platform for you to communicate back and forth with API users, providing a rich knowledge for future users, and also opening up the possibility of users helping other users
• FAQ - Provide a simple, realistic and complete list of the most frequently asked questions. Also keep it a living list, truly reflecting which questions get asked every month
• Contact - Establish some way users can directly contact the agency for support
• Twitter - An active Twitter account is a required communication tool
• LinkedIn - A presence on the top business social network is important
• Facebook - An active page on Facebook helps with communication
• Google+ - Google’s social network can help with developer interaction

With proper communication building blocks in place, next make sure and address the legal considerations around the web API:

• Terms of Use - Clearly let users know what is expected when they access the agencies web APIs
• Privacy - Establish clear privacy policies for all people and companies involved
• Licensing - Provide data, API interface and code licensing for everyone to see

With legal expectations set, make sure and think about branding for the agency. While these web APIs are the federal government, for them to be successful, the word needs to get out that our government does such a find job making data available. There are some common API branding building blocks emerging to accomplish this:

• Branding Requirements - Establish a base understanding of how to properly attribute the agency in compliance with overall usage requirements
• Logo - Provide a single place to find a selection of approved graphical logos and HTML or JavaScript code snippets users can use when adhering to branding requirements

After baking in some user implemented marketing for the agency, with API branding, make sure and provide some operational building blocks that help API users understand what is going on with the agencies APIs and where they are going:

• Roadmap - Give users a clear roadmap of where the agency is going with it’s digital strategy, providing insight as far in the future as possible
• Changelog - Provide a real-time list of changes made to the API and its supporting building blocks

Providing real-time communication on your API operations is important to establishing trust with developers. If you just make it part of your daily operations, it isn’t that much more work.

Non-Developers
While planning the digital strategy for your agencies web API make sure and consider non-developers. One reason for the success of web APIs is that it uses REST, which uses the technology driving the existing World Wide Web, making RESTful APIs potentially familiar to non-developers. With the right building blocks, web APIs become accessible to a wide variety of users:

• Embeddable - Buttons, widgets and badges that are provided on top of a web API provide a copy and paste method for non-developers to quicky make use of the data and information available via an API
• Media - Provide a section dedicated to media, helping media on two fronts 1) to understand what an API does in plain english 2) to put a web API to potential use in their data journalism efforts
• Educational - Provide information and resources that facilitates API usage by any level of academic research and projects
• Platforms  - With introduction of Google Docs, Google Big Query and other big data processing solutions, the opportunity for API integration on these platforms is growing. Provide templates for using agency APIs within these platforms

Everything suggested up until now, truly supports a digital approach, to each agencies digital strategy, but in these environments, the need for face to face and human interaction can be critical to building understanding, awareness and ultimatley a community around a web API.

Events
Events are a great way to build awareness around an API, there are several common event building blocks that are used in the industry:

• Annual Conference - Establish an annual event where each API stake holder and any user can rub elbows and share their thoughts about web APIs
• Road Show - Develop a road show that goes from city-to-city, providing a town hall format for understanding each agencies digital strategy
• Meetups - Attend existing developer meetups and gathers that are already occuring in cities around the country
• Hackathons - Sponsors, attend and put on hackathons that encourage hacking around federal agency APIs

I think that represents my thoughts on the essential API building blocks federal agencies should consider while formulating their digital strategy. The only other area I would offer more details on, is around API evangelism and developer advocacy. Who will be in charge of getting the word out about an API? Will this be a single person or shared responsibility? An API Evanglism strategy is critical to the success of an API, but I think I will cover that in another post.

Scrolling back up the page, this seems like a lot, and potentially counter to my wishes that we start simple and make sure this is a success. My goal with these thoughts is to provide a potential business framework that could be adopted across all agency deployments.

These building blocks are derived from reviewing the API operations of hundreds of existing public APIs, including industry heavyweights like Google and Amazon. While some APIs like Twitter deal with API management at massive scale, Google and Amazon provide models for managing large numbers of web APIs.

Make sure and spend some time and look at how Google or Amazon is organizing their developer community.  If any developer could go to any of the over 100 agencies, or the over 1000 domains, and find a consistent experience shared across ALL agency web API areas, like they do at Google or Amazon APIs, the chances for success of this iniative is much greater.

I hope someone in one of the agencies reads this, and understands the importance of this moment, and that an API is more than just a CSV or XML dump at a web address. That, with the right business approach to deploying and managing we can truly transform how government interacts both internally, inter-agency and with the public. Opening up the federal government to a whole new era of democratic participation, government transparency and interoperability.

Tracking Federal Agencies Progress on API Deployment

I’m excited about Barack Obama directing all federal agencies to have an API. The President has given federal agencies 90 days to create a page on its website, located at www.[agency].gov/digitalstrategy, to publicly report progress in meeting the requirements of the Strategy in a machine-readable format, and implement the requirements of the Strategy within 12 months.

As I said in my post, I wanted to setup a page to monitor this activity. I found a dataset of federal executive branch Internet domains, thanks to Anthony Sutardja, one of my readers. In the dataset there are 1467 domains, with 106 distinct agencies running those domains. The President states “executive department and agencies” in his directive.  I can’t imagine we are going to see digital strategies in 90 days for all 1467 domains? I’m assuming it will occur within the top level agencies first. But I’m very curious see which agency domains follow, so I’m going to leave all of them up.

I created a script that will poll www.[agency].gov/digitalstrategy for each agency. I will run this every night this year. The script checks the HTTP status code for the page, records it with a time stamp, and the we’ll see who returns HTTP status code 200(OK) first. Quick note: It’s interesting to see which agency doesn’t properly use status codes, but that is another issue.

Anyone want to wager on who is first, and how many of the 1467 meet the requirements for posting their strategy and ultimately implementing APIs? Personally I’m hoping for CIA and the NSF. Think of the mashups you could make!!!

I all seriousness, this is extremely important. If agencies meet these requirements, we can see a radically different federal government in the coming years. As one of my readers and friend said on the post yesterday, “It looks like the Jeff Bezos mandate that he did 10 years ago!”. If you don’t known what I’m talking about, read “The Secret to Amazons Success Internal APIs”.

You can visit the Federal Agency API Deployment Tracker page for more detail, I will keep the link prominent in the right hand feature area of this site, for the rest of the year.

Healthcare Imaging API

There is a new API edition to the healthcare industry this week. lifeIMAGE launched an API that can be used by developers of healthcare applications, to enable the secure exchange of medical images and related patient records.

Norman Young, President and CEO of ClearCanvas, said “We were founded on the simple belief that medical imaging informatics should be accessible to all. Now, using the lifeIMAGE API, users of our FDA-cleared diagnostic viewer will be able to instantaneously share images that are in front of them with any one.”

The healthcare is industry that is ripe for API adoption, so I’m always looking for “healthy” new API stories for the space—lifeImage API is perfect. You can find out more about the API at www.lifeimage.com/api.

An API Could Be The Fancy’s Kill Move Against Pinterest

Pinterest and The Fancy are locked in a deathmatch, if you hadn’t heard? Compete wrote back in February that The Fancy was poised to take over a chunk of Pinterest’s traffic with their new webstore. Fast forward 5 months, The Fancy has just launched an update to their iOS which includes the ability to purchase products from the mobile app with just one click.

Nice move! The Fancy is definitely an easier and cleaner looking site than Pinterest, and with a monetization move, The Fancy could gain even more market share against Pinterest.

Now if The Fancy wanted to seal the deal and put a death nail in Pinterest’s coffin, they should launch an API, and make The Fancy a platform. Don’t just open up API access to your content—open up API access to your new commerce layer as well.

Once you have this mapped out, deploy a well crafted suite of embeddable objects, like share and buy buttons, along with essential widgets—all with the commerce layer built in.

Developers and non-developers will make sure The Fancy becomes ubiquitous across the web, and because you chose to consider monetization, while making your platform play, and included developers in this model, the entire platform will be sustainable and outlast anything Pinterest can come up with.

API Monetization: API Affiliate Network API + Google URL Shortener API

In my quest to understand the monetization opportunities via APIs, I’m studying the possibilites around tracking, and now monetization of content and URL’s served up via APIs.

The other day I considered wrapping URLs for another layer of metrics in your API, and today I’m thinking about how to evolve API monetization beyond advertising, defining entirely new API driven conversion events where both API owners and consumers, can realistically make money.

I first talked about an advertising network dedicated to APIs and developers last year, and everytime I come back to it in my Evernote list, I can’t help but consider using the Google Affiliate Network as an engine.

I don’t have any access to Google Affiliate Network (I submitted request), so all of this is speculative. But after looking through the Google Afffiliate Network API interface, it looks like I can pull both advertisers, publishers and events through the API— so I’m envisioning two scenarios:

• API Owners - As an API owner I could use the Google Affiliate network to define “events” that could occur via my APIs, and setup my API developers as “publishers”.
• API Consumers - As an API consumer I could setup various APIs I use as “advertisers”, creating specific events for these APIs, and setup my own applications or sites as “publishers”.

In either case, API owners or API consumers could replace any URLs in content or URLs directly served up via APIs with a Google Affiliate Network generated URL with specific conversion events defined, then shortened using Google URL Shortener API.

This would create a layer of not just metrics, but conversion events that could be monetized. API consumers could choose from affiliate opportunities available on the Google Affiliate Network, and API owners could do the same, or define their own conversion events that were meaningful to their business goals.

These are just some original thoughts on API monetization using Google Afffiliate Network API and the Google URL Shortener API. Seems like there is a lot of opportunity monetize the data and resources flowing through API pipes, whether you’re an API owner or avid API consumer.

Is Your API Big Data Ready?

Many “public APIs” are launched with well, very “public” intent—to extend the reach of the brand and platform. Many of these APIs are setup to pull data, enabling developers to use it in their applications for free or paid, with the understanding they’ll properly attribute the source.

Many of these APIs like Amazon E-Commerce, eBay, Google Places and Foursquare are engineered to publicly extend the central platform, all feeding back back to the “mother ship”, either through linking or other type of attribution.

As the Internet evolves, and the era of “big data” takes hold, and as the need for processing data and deriving meaning out of the flood of data available to us online grows—so does the demand for API access that isn’t marketing centric.

As a big data developer I may be comparing product pricing from Amazon to auctions on eBay, and I may need to use Google Places data to identify best places to sell my products, and Foursquare to identify local demand. The needs of big data API developers are going to be radically different than maybe your originally intended developer audience.

Hopefully you are already carefully targeting your developers and grouping them by their usage patterns. Have you identified any users that are actively using your APIs, but not necessarily following regular patterns?  Have you reached out to them?

It might be the case that your API won’t be of interest to big data developers or quite possibly that this isn’t a market you’re interested in. However it is a question every API owner should ask—is my API big data ready?

Barack Obama Directs All Federal Agencies to Have an API

As a follow-up to the Executive Order 13571 issued on April 27, 2011, requiring executive departments and agencies to identify ways to use innovative technologies to streamline their delivery of services to lower costs, decrease service delivery times, and improve the customer experience—Barack Obama has directed federal agencies to deploy Web APIs.

The Whitehouse CIO has released a strategy, entitled “Digital Government: Building a 21st Century Platform to Better Serve the American People”, providing federal agencies with a 12-month plan that focuses on:

• Enabling more efficient and coordinated digital services delivery
• Encouraging agencies to deliver information in new ways that fully utilize the power and potential of mobile and web-based technologies
• Requiring agencies to establish central online resources for outside developers and to adopt new standards for making applicable Government information open and machine-readable by default
• Requiring agencies to use web performance analytics and customer satisfaction measurement tools

President Obama has set the timeframe for roll-out and accountability at:

• Within 90 days of the date of this memorandum, create a page on its website, located at www.[agency].gov/digitalstrategy, to publicly report progress in meeting the requirements of the Strategy in a machine-readable format.
• implement the requirements of the Strategy within 12 months of the date of this memorandum and comply with the timeframes for specific actions specified therein

Ok, can I call 2012, the year of the API now? Of course this announcement makes me extremely excited! This is something I didn’t think I’d see in the next 5 years, but of course I’m super skeptical too. Is this something that these agencies are capable of? Is there enough political will to make happen? I sure hope so.

I’ve seen some good coverage of this news on popular tech blogs, but we’ll have to wait 90 days and see ho many agencies have publicly reported on “progress in meeting the requirements of the Strategy in a machine-readable format”, and ultimately how much momentum this actually gets—or if it gets forgotten.

As soon as I can find an API with all government agencies and their websites, I will make a monitoring dashboard showing how many agencies have published anything, and what it contains, and report on my findings in 90 days.

Self Service vs Sales Oriented Web APIs

I’m doing some big data work. Ok it isn’t really, but feels like I should use that label. What I’m actually doing is analyzing the Twitter activity of top APIs.

I have the twitter handles of 100 of the popular web APIs. I have been pulling and analyzing the Tweets from each of these accounts via the Twitter API for some time now.

It is time that I scale this to about 500 API twitter accounts, and also start monitoring mentions of each of these APIs on Twitte, while also performing searches for some keywords associated with each API or a group of APIs.

At this stage of growth, it was clear I was outgrowing the regular Twitter API and since what I’m doing is more big data, than twitter client app, I am looking at the two approved Twitter resellers Gnip and Datasift.

First I went to Gnip, looked at their product and it looked like what I needed. I saw at the bottom of the page, “Get Started”. I recognize that language, clicked on it and filled out their form and I get a “Thank You, Someone Will Be In Touch”.

Ok…so I move on to Datasift. I look at their product and it too, looks like what I need. I see on the page, “Get Started”. I recognize that language, clicked on it, logged on with Twitter, added my email and password, and boom—I’m dropped into a dashboard. I am able to build streams from Twitter using different keywords, Twitter users, etc. I get freemium access, with the ability to put in my credit card and be billed for more.

Next, I got a quick email from a nice fellow at Gnip asking what I was looking to do, and if I had time in the next couple days to talk on the phone.  I will definitely talk with them, but by the time I get on the phone with them I will be 2-3 days into developing my solution around Datasift. Unless Gnip has some secret pricing or some magic features Datasift doesn’t have, I probably won’t switch.

That’s the difference between self service and sales oriented web APIs. Which one are you?