API Best Practices Blog
Free Webinar: Mapping Out Your API Strategy »
Ever need to explain why APIs are so powerful to someone at your company? Need an easier way to think about the different API strategy options?
Join us for a Webinar - “Mapping Out Your API Strategy” - this Wednesday, April 20 at 11 am PST / 2 pm EST.
It's free (of course) and you can sign up at this registration page.
Brian Mulloy and Sam Ramji will talk about the API market, and propose some ways of thinking (and cool frameworks) for how you can think about API strategy vs. your objectives.
Build & Run a Web API for FREE »
With the proliferation of free, cloud services it's possible to build and run interesting mobile and web projects from end-to-end for free--including an awesome web API.
Here are 10 steps to building and running a web API for free.
1. Prepare
Get up to speed on APIs - from their economic and business model rationale to design best practices and principles to developer community practices.
2. Design
Prioritize your resources (objects) in a Google spreadsheet and start to craft your URLs and HTTP methods.
3. Build
Build your API quickly using Ruby on Rails scaffolding. And here are some additional Rails API tips from @StefanSiebel.
Store your source code in GitHub.
4. Deploy
After you create your Rails-based API, deploy it to Heroku.
5. Proxy
Use Apigee's Free service for API analytics, debugging and rate limiting.
6. Document
Document your API using GitHub pages.
7. Engage
Engage developers by embedding an API Console into your docs using Apigee To-Go.
8. Launch
Grab a domain name for your project from a DNS provider like GoDaddy.
Setup CNAME records for:
- GitHub docs: dev.mydomain.com
- Apigee proxy: api.mydomain.com
9. Promote
Use Twitter, Blogger and Facebook to promote your API.
10. Support
Support your community with GetSatisfaction and manage tickets with GitHub's Issues feature.
A couple of us (@earth2marsh & @landlessness) recently built an API with this set of products and had a lot of fun doing it. We'll talk more about that project in a future post.
Considerations for ‘open data’ API programs »
In my last post I wrote about how the book digitizing effort is trying to monetize underutilized books online.
For anyone contemplating exposing data or capabilities via APIs to create new revenue streams, there are some important implementation lessons that can be learned.
Have control
In Norway’s Bookshelf project, their free online books can only be read online and only in Norway, and cannot be downloaded or printed out. Similarly, with APIs you need to have a way to control who can access your data and from where. API Identity, API authorization and other API security considerations are a must.
Make it (at least something) free
Google must operate under copyright laws, but it has found a way to freely expose extracts or snippets under ‘fair use’. Similarly, you cannot expect uptake of your content or capabilities if some of it cannot be consumed easily and en gratis. Give at least some of what you offer away for free to spur adoption. Technically, this means being able to control what can be consumed at a granular level.
Get started!
Google, Bookshelf, and Europeana have ideas about how they’ll monetize books they put online, but they are still experimenting with the right business models. Executives shouldn’t wait for an iron-clad business model to present itself… you won’t figure out the right model unless you are ‘in the game’.
How do content and transactional APIs differ? »
Recently, during one of our our RAW (Rapid API Workshops) with a retail customer, a great question came up - what are the major differences between a content and transactional API?
Probably not a complete list, but in general:
Content APIs are more likely to be open, without sensitive information. Think of a search, media, or mapping API. While the provider might want to track identity through API keys, these APIs often need no authentication, authorization, or encryption. Search results may be highly cachable, which might be helpful to support high concurrency for bursts of demand for popular content. Content APIs are also more likely to need throttling to protect the back-end and quotas to measure consumption - think about that grad student downloading your entire database one API call at a time. Users might have some tolerance of downtime for free content that can easily be requested again. Success for content APIs might be measured in terms of usage or engagement. (usage per consumer), so having API usage analytics might be important. If you can, make content APIs simple and easy to adopt with standards like REST.
Transactional APIs have sensitive data and therefore security needs go beyond identity and developer key level tracking to include API authentication and authorization. The data might need encryption and XML or API specific threat protection. Instead of quotas, the back-end business logic might already contain all the controls you need to measure consumption and monetization. There is probably no tolerance for downtime or lost transactions. And of course success for transactional APIs can be measured in existing financial terms.
| Content API | Transactional API |
|---|---|
| (Often) Open to all without authentication or encryption | Authenticated, authorized, and encrypted access |
| (Often) non-sensitive data |
Audit and compliance requirements |
| Static or mostly static data -- highly cacheable | Dynamic data -- limited cacheability |
| May have higher volume | Natural volume limits (user may have to pay...) |
| More likely to require quota (prevent download of all content, excessive updating, etc.) | Natural volume limits |
| Some tolerance for downtime (user can just refresh) | Little tolerance for downtime (did you charge my card or not?) |
| Metrics == API usage | Metrics == Financial ($$ of orde |
What's your experience in the difference between content and transactional APis?
Paid vs. Free APIs »
Last time I wrote about the difference between'open' vs. 'free' APIs.
Another interesting dimension is free vs. paid.
Free vs. Paid has to do with the business model of your service. If you have a service that’s valuable/revenue-generating to the user (unlike advertising/reach, which is valuable to *you*) then you might choose to ask to be paid - through a credit card, licensing or BD deal. (we've written before on the many API monetization models and resulting API roadmap and technology implications.)
While I hate the term "freemium" (more on that later) .. You might also choose to offer your free service up to some limit (100 API messages/hour) and then charge for larger volumes (100-999 calls cost X, 1000-4999 calls cost Y, etc.). The lowest rung on the pricing waterfall is often 'free'.
Twitter's API has both free and paid access. For typical end-users, the API is free and provides a limit of 150 messages per hour. For larger usages – such as those from media and news companies who want to harvest Twitter data – there is paid access to enable message volumes in the thousands and higher per hour.
No doubt if the volume of API calls in the Tweetdeck case to Facebook goes up, there could be a charge; or if Twitter starts selling licenses to consumers for larger API bandwidth as they do today for enterprises (media companies), Tweetdeck could be a place where those licenses are sold. Personally I would happily pay $2-5/month to get 500-1000 messages per hour on Twitter due to the incredible utility of Tweetdeck. Otherwise I’d be confined to the Twitter web interface which is just not that useful to me.
We are really in a very dynamic part of the API market right now where many business models are being tested out. We should have a longer conversation about the different business models that seem to be working. A good example - Fred Wilson had some great and different thinking that can open up new profit models through APIs.
Next - is there a business model in *paying* people to use your API?
Free vs. Open API: Is there a difference? »
"Open and Free" are often used interchangeably when talking about APIs. But if you look at in terms of the "API Economy" - open and free API are orthogonal.
'Freedom' in the cloud is more typically discussed as your rights to move data from one service to another. Application portability has also been raised as important but current application models are both early in their maturity curve and vary greatly.
Open and free are both crucial attributes in order for a market economy to grow. There are many aspects of cloud computing but for the developers and users of cloud services, the atomic unit of the cloud is the API.
The link between openness and economic growth is a deep subject that may provide clues for how to build a better cloud – this paper makes me think a company’s APIs might represent the “export goods in which it has a comparative advantage”.
In the software industry open platforms have typically outperformed closed platforms in the long run due to the economies that develop on top of them, cementing those platforms’ place in a range of markets.
Open APIs are:
1) Openly documented
2) Available via self-service (i.e. developers can sign up and get a key on a website)
3) Using open technologies (SOAP, REST, RSS)
A good example is bit.ly - a simple URL shortening service that also lets you see how many people have clicked on your shortened version of that URL. It’s really useful if you want to both project important articles on the web and understand the reach of your projection. Is it an Open API?
Test 1: Bit.ly's API is openly documented (here)
Test 2: It's available via self-service. You can get an account and a key right away.
Test 3: It uses open technologies: It's a REST API (granted, it is a mix of verbs and nouns)
Open APIs lead to 3rd party innovation
Tweetdeck users put their bit.ly API key into Tweetdeck, which automatically uses their bit.ly account (indicated by the API key) to shorten URLs that are typed into tweets. It made Tweetdeck better and probably increases the traffic to bit.ly.
This could also work on the iPhone application of Tweetdeck but it’s not yet implemented in the version I have. Many iPhone applications work use one or more cloud APIs that provide access to services in a clean, machine-friendly way.
From the efficiency of innovation perspective, keep in mind that Twitter most likely never contacted Tweetdeck to use their API, nor did bit.ly (as far as I know). The Tweetdeck guys simply built a killer application that uses those services via APIs rather than scraping their web sites. In the last month, Tweetdeck also added Facebook and MySpace support via their APIs.
Open APIs lead to innovation, efficiency and reach through designing your core business service to be “remixed” is found through APIs – Tweetdeck users got new value through the app they like and Facebook and MySpace got a new stream of user-driven content, all without sales or business development teams engaging at the outset.
Next time: Free vs. Paid APIs...
(Sam Ramji is the VP of Strategy for Apigee. Previously, Sam drove many of Microsoft's Open Source Initiatives)
