Monday, July 30, 2012

API Driven Twitter Advertising

I’m playing around with my Twitter Advertising account, trying to understand Twitter’s path to monetization. The Twitter Advertising interface is pretty clean and simple, allowing me to promote my account or tweets in four easy steps.

Step 1 - I can choose the locations where I want to reach users anywhere in the world, in specific countries only or in specific US cities:

Step 2 - I can promote my Twitter account prominently in the who to follow section to users that are most likely to be interested in my account--I only pay for new followers that I gain:

Step 3 - I can promote my Tweets, prominently displaying them to other users with similar interests:

Step 4 - Then plug in my credit cards to pay for the ad spend I setup for my promoted account or tweets:

Twitter Advertising is pretty straightforward. I wouldn’t call it anything revolutionary. But it is implemented simply, making it work for the masses. I could see businesses adopting it right alongside Google AdWords.

By itself Twitter Advertising makes sense, but when you step back and look at it in context of the rest what’s going on with the Twitter ecosystem, I wonder if they are seeing the big picture.

As a Twitter Advertiser will I be able to:

  • Use the Twitter API to truly understand the space I’m advertising in? Track on patterns, opportunities and be able to get at the data I need to make my advertising successful? If I have to pay Gnip or DataSift for my business intelligence, it won’t work
  • Have access to an API that gives me full access to the Twitter advertising resource? Allowing me to programmatically tailor my Twitter Advertising campaign

It just seems like to me that Twitter is seriously reducing the potential network effect by not including the Twitter API ecosystem in the Twitter Advertising program. Developers could help deliver innovation beyond just promoted accounts and tweets, extend the reach of advertising if they had more access to data via the Twitter APIs, optimize advertising campaign effectiveness with more API access as well as automate Twitter advertising with an API directly for the advertising platform.

from API Evangelist

Saturday, July 28, 2012

What is the Future of Web APIs?

Photo by Nicholas_T

APIs are about to enter a new phase, one where developers can easily program using multiple APIs at once, and non-developers can easily introduce API automation into both their business and personal worlds.  A time where APIs are seen as a valuable resource anyone can quickly put use, not just as a technical interface only the geekiest of us understand.

Web APIs have matured out of its earlier service oriented architecture (SOA) roots, often shedding a rigid SOAP approach to a more flexible RESTful implementation, increased efficiency by opting for more lightweight JSON over bloated XML, and becoming more accessible with API explorers and interactive documentation like Swagger, Mashery I/O Docs, and Apigee’s Console.

Now with over 6,000 public APIs available, there is a need to get more efficient about how we work with APIs, and evolve to where we can truly program the web.  But to get there, we have to add a new platform layer that can help standardize the authentication, interfaces and resource types available--simplifying how not just developers, but average users can take advantage of APIs.

One approach is targeting developers with new languages, or extensions of existing languages that can be used to program against one or many APIs, as with Webshell and Temboo:

Webshell - A scripting language designed for fast API consumption and implementation
Temboo - Platform allowing you to easily choreograph API workflows using Java, PHP, Python, or Ruby code snippets

The second approach is targeting a wider audience with automation platforms that create API driven tasks, such as IFTTT, and WhenAUser:

IFTTT - IFTTT is a service that lets you create powerful connections with a simple If This Then That statement - helps you to automate routine operations and connect multiple cloud APIs.
WhenAUser - A simple rules engine that makes APIs tools work together

Both approaches provide a much needed platform to help make APIs more accessible, where one is still targeting the developer community and the other will allow anyone to take advantage of APIs through special automation tools and connectors. Beyond these programmatic and automation approaches there is a third approach to API usage, currently being defined to support mobile application development.  Companies like Cabana and Tiggzi are changing the way we build API driven mobile apps:

Cabana - A visual way to build custom, API driven mobile applications
Tiggzi - A GUI mobile application development platform

These GUI mobile application builders allow developers and non-developers to rapidly deploy mobile applications built on top of APIs, providing new ways of abstracting away the complexity of API integration we commonly experience today.  This approach to API bundling is also being put to use by Mobile Backend as a Service (MBaaS) providers like Kinvey, who are building in API gateways for common APIs that would be needed by mobile developers--a move we’ll see mimicked by other MBaaS providers.

Which of these three approaches reflect the future of the ProgrammableWeb?  Will it be an API programming language, an API automation platform, mobile back-end as a service or a blend of them all?

Only time will tell, but no matter which approach get us there, I can see we are getting closer to a truly ProgrammableWeb.

from API Evangelist

Wednesday, July 25, 2012

Update Once, Publish Everywhere with an Embeddable API Strategy

Embeddable tools like widgets, gadgets and buttons built on top of an API are nothing new. A healthy embeddable strategy was behind the success of popular platforms like Youtube, Google Maps, Twitter and Facebook.

Even with this success, embeddable tools often get overlooked by many companies when planning their APIs. I was recently introduced to BandPage, formerly known as RootMusic, who made a name for themselves by building a successful band promotion application within the Facebook ecosystem, and have crafted a very interesting embeddable strategy. To recover from a recent Facebook platform change, BandPage employed a robust embeddable strategy to quickly decouple their business from Facebook, enabling bands to not only deploy on Facebook, but manage music, photos, tour dates across the web.

Driving the embeddable band pages is a robust JavaScript API, which isn’t publicly available, but at some point it’s something they’d like to expose. Calling BandPage’s embeddable tools widgets really doesn’t do them justice, they have a seriously crack team of developers who’ve built a pretty sophisticated platform.  Their approach deserves notice, not just for the embeddable strategy, but the way they were able to use it to quickly recover from the changes they encountered in the Facebook ecosystem.

I think a healthy embeddable strategy is something every API owner should craft.  The right set of embeddable tools can extend your reach beyond the average developer community, while also allowing your data and resources to exist on any site or platform. And in the case of BandPage it can also free you from having your wagon hitched to any single platform like Facebook, and open up much wider opportunities for success.

from API Evangelist

Friday, July 20, 2012

Definition of API Craft

The current API development space is very self-ruled, in that web API developers have freed themselves of earlier SOA attempts to rigidly define and ultimately constricted API growth, into a more grassroots, community-owned approach to RESTful API design.

You can see this happen in real-time on the public Google Group called API Craft. API Craft was started by Apigee, as an open forum for sharing and developing knowledge and skills around APIs, where you can find the latest throughts, from the smartest people in the space.  

I thoroughly enjoy the online version of API Craft, and just experienced my first offline version of API Craft at OSCON in Portland this week. Several API folks got together for beers and API Craft discussion at the White Eagle Saloon creating an awesome real-time, face-to-face extension of the online API Craft group--an experience I intend to initiate whenever I am in new cities around the country, and I encourage you to do the same.

I think Apigee has really started something important and feeling inspired, I wanted to share my thoughts on a definition of API Craft. Deriving from the dictionary definition of craft:

"Skill in doing or making something, as in the arts; proficiency" and "The membership of such an occupation or trade; guild."

I suggest the following definitions of API Craft:

"An online forum for sharing and achieving proficiency in the skill and art of web API design, development and management" and "A physical gathering for discussion of the skill and art of web API design, development and management while enjoying a craft beer and good food."

Apigee has started something that has taken on a life of its own, becoming a powerful, community driven approach to evolving the skill and art of web API design, development and management--both on and offline.

I encourage you do participate, and I’d love to hear your definition of API Craft, as well as more information your local API Craft gatherings.  I look forward to seeing you online and in-person at the API craft gatherings.

from API Evangelist

Wednesday, July 18, 2012

Let Developers Register for Your API with Their Github Profile

I was playing with Singly, a unified social API last night. One of the first things I saw, after landing on the home page, were two choices for signing up as a developer--one with Facebook or the other with my Github account.

I’m seeing Github as an option for API developer registration, more frequently these days. And it makes sense. Each of my social networks have a place in my life--Facebook is my more personal social network, Twitter my more public persona, Google is my business platform and Github reflects my developer profile.

When registering for APIs and development centric platforms I’d much prefer to keep these associated with my Github profile. And for an API owner it makes sense to have developers linked using Github, because of the social effects and interactions possible with code library repositories and documentation.

With two clicks I was signed up for Singly, using my Github, and I dropped into the dashboard where I was given an option to add my first application and begin integrating.

Developer registration using Github should be standard operating procedure for all APIs. Github is the social network I want APIs to interact with me on, and it is definitely where API owners want to connect with their developers, so they can further interact around code, documentation and all the other geeky goodness Github provides.

from API Evangelist

A Unified Interface for Social APIs with Singly

Web APIs come in all shapes and sizes. The differences between API authentication, interfaces and data types can be a big challenge when developers work with multiple social networking APIs like Twitter, Facebook and social media APIs like Instagram and Flickr.

Each API tends to run with their own interpretation of what a RESTful API means, leaving developers left with navigating not only the differences between various APIs, but the changes a single API will make from version to version.

Many industry pundits claim this will become unmanageable. I think its the nature of the web API space, and we should leave API owners to do what they do best, rather than forcing them to agree on standards.  Then how will we bridge these difference? This is an important opportunity for providers to step in and aggregate critical APIs within specific sectors, and provide a unified interface that developers can depend on. One example of this in action is Singly.

Singly aggregates some of the most important social APIs, simplifying authentication, creating consistent patterns for API endpoints and a unified set of data types to work with across all supported APIs. Singly pays attention to the differences between APIs and versions, so developers can do what they do best--build social applications, using social data from the platforms their users are already on.

Immediately the pundits will ask, how can they keep up with all the changes? I respond with how can we not move this industry forward without someone paying attention to it for developers. I see Singly as a necessary component for the API industry to stabilize and move forward. Developers needing to integrate with a single API can visit the API directly, while developers who need to integrate across multiple APIs can depend on Singly.

I see opportunities for the Singly model to be applied in other niche areas like location based services, video, restaurants and government to just name a few fast growing API business sectors. It’s clear that RESTafarians aren’t going to come to an agreement on a single stand, and API owners are busy providing the data and resources they specialize in, so a unified approach like Singly appears to be a healthy path forward for standardizing APIs, creating a more stable interfac for developers.

from API Evangelist

Monday, July 16, 2012

Dwolla's New Developer Area is Not Just for Developers

Next generation payment platform Dwolla just revamped the home page of their developer center to speak to the widest audience possible. When you land at you are given two options:

  • I can code - You know the difference between Java and JavaScript and just want to dive into our API documentation
  • I don't code - You're a non-technical executive, the master of partnerships and products, and want to know why Dwolla is right for you

This is an approach I've been long advocating for, and rarely see in API areas. The best case study I always point out is the LinkedIn developers area, who provide buttons, widgets and embeddable tools that non-developers can put to use.

Why do this? Well according to Dwolla, "One of the biggest misunderstandings about API portals is that their purpose is only for developers. That’s just not true. Integrations start with a spark of curiosity, “Would this work for my company?” Technical or not, who asks that question is irrelevant at that point; how it’s answered is what determines the outcome."

Dwolla's approach reflects the core philosophy of why I started API Evangelist. I'm not advocating just to developers about the power of APIs, I'm evangelizing to the business leaders and decision makers about the power of APIs.

While actually integrating with your API might be a technical endeavor, much of the business decision around using your API will most likely be made by a non-developer. Make sure your API speaks more than just geek, and reaches as wide an audience as possible.

from API Evangelist

Thursday, July 12, 2012

Don't Forget About the API Pioneers When You Think APIs Won't Work

As we continue to stress over all the news of API ecosystem battles, and how APIs owners are evil, and once a business grows up, it has to choose between being a hobby developer platform or real grown up business--let’s remember the web API pioneers.

Salesforce, eBay and Amazon are all three going strong, making money, treating developers as part of the equation and continue to operate legitimate business via APIs for over a decade now. These three API pioneers set the stage for the API industry during the first “dot com bubble” in 2000 and Amazon in 2002, and 10 years later still proving you can become an Internet powerhouse with the help of your API developer ecosystem.

API skeptics always step up and say they are different, that they have core web products, existing business models, etc. Sure, there are differences, but Salesforce, eBay and Amazon have all managed to achieve success with continued investment in their API ecosystem. None of these platforms have had to restrict or shed their developers to make ends meet, once the utopian API early days are over.

When I read comments, tweets and other noise from people about what fools developers are for depending on an API, I stop and think about these API pioneers. Developing a large, healthy API ecosystem is not easy--but when you see your API as an essential part of your core platform, and give it the necessary resources, you can strike the harmonious balance necessary to make APIs work.

from API Evangelist

Wednesday, July 11, 2012

Two Years of API Evangelism

I started my research on the API industry two years ago this month. In July 2010 I was looking for the next step, and thought the API space might be it, but I wanted to do my homework before I made the switch. So I spent a month studying where the API space was, and where it was going.

I saw that web APIs had found its roots in sales and e-commerce with API pioneers like Salesforce, Amazon and eBay. Then quickly gained momentum with social APIs like Delicious and Flickr, then Twitter and Facebook. But social was still more hobby than business, and it wasn’t until Amazon started deploying storage and compute infrastructure using web APIs, is when it got real.

In summer of 2010 I couldn’t see anything but mobile. Understanding the importance of APIs when it comes to mobile app development, I knew that APIs would play a significant role in the future. But what role could I play? How could I contribute?

There were plenty of extremely smart RESTful pundits or RESTafarians as Mike says. I was capable of playing here, but saw an area I could focus on, and that was the business of APIs. Successful APIs aren’t just technical, there are a lot to consider on the business and marketing side of things.

So in August 2010 I bought, then by October I was blogging about my research in the space. Two years later I’m still blogging about the business of APIs and monitoring the space. But I’m adding two new domains to my network:

  • API Voice - A blog about the politics of APIs. Issues that face API owners and developers while trying to develop and manage API ecosystems
  • The API Stack - A listing of top APIs, ranked using an algorthm I’m evolving, that helps me discover new and identify strong and emerging APIs--as well as APIs that aren’t fully delivering

As I’m finding more time to focus on the space you will find my coverage of the business of APIs on API Evangelist, the politics of APIs on API Voice, and a view into how I rank and monitor APIs at The API Stack.

I hope you find some value in my research in the space. I know I learn a lot, every day.

from API Evangelist

Tuesday, July 10, 2012

Where Do I Learn More About APIs?

When it comes to the business side of APIs, API Evangelist is where you want to be. I’m also working to build out API Voice as a source of information on the politics of APIs.

But where do you go for the deeper, technical side of APIs? I recommend API Craft.

API Craft is a Google Group setup by API service provider Apigee to discuss everything about APIs. API Craft has over 1300 active members, generating conversation about where to meet-up and talk APIs in different cities to the finer points of HATEOAS.

There are some seriously smart folks on the forum, from companies who already lead the space, discussing their API implementations and sharing insights. Apigee and the community has done an amazing job keeping the forum all about APIs and not about selling our warez.

If you are not already a member, and looking to deploy an API, or just want to learn the finer points of API development, and management I recommend checking out API Craft.

from API Evangelist

Monday, July 9, 2012

Twitter Acquisitions

Acquisition of technology startups by companies is a regular part of business today, providing a way for these companies to get the technology, talent, as well as user and market share they need to be successful. These acquisitions play an important part of API ecosystems, with API owners hoping developers build the next killer feature that users will love, something they can invest in, and developers dream API owners will notice their work and purchase their “startup”.

Looking back at the acquisitions made by a company can funcation as a sort of “tea leaves”, allowing us to interpret the companies motivations, possibly telling us where they are headed and who they might acquire next. As part of my Twitter research I wanted to look at the acquisitions made by Twitter over its short six year history:

07/2008 - Summize - Social Search

11/2008 - Values of n - Social Software Developers
12/2009 - Mixer Labs - Location Information Engine
04/2010 - Atebits - Tweetie Client for iOS and Mac

04/2010 - Cloudhopper - Mobile Messaging

06/2010 - Smallthought Systems - Database and Analytics

12/2010 - Fluther - Question & Answer Service
05/2011 - TweetDeck - Web and Desktop Twitter Client

05/2011 - AdGrok - Advertising

07/2011 - BackType - Social Analytics

08/2011 - Bagcheck - Social Sharing and Discovery
09/2011 - Julpan - Real-time Social Search Engine

11/2011 - Whisper Systems - Mobile Privacy and Security
01/2012 - Summify - Social News

01/2012 - Dasient - Internet Security

03/2012 - Posterous - Blogging Platform

04/2012 - - Social Media Intelligence

05/2012 - RestEngine - Personalized Email Marketing Service

06/2012 - nclud - Boutique Design Agency

Twitter’s acquisitions are diverse and appear to be very strategic. Twitter has wisely invested in search, security, messaging and data storage, while also taking control over mobile and desktop clients.  Twitter has made some smart acquisitions out of the ecosystem, but you have to wonder why acquisitions of companies like Tweetie and TweeDeck caused such a backlash, while acquisitions like Backtype, Julpan and Dasient you don’t hear much of anything from the ecosystem.

I would like to understand other players in the Twitter ecosystem like the firehose partners and investors more, before I draw too many conclusions from the acquisitions Twitter has made.  Twitter has already made 6 acuisitions this year, the same amount as Twitter acquired in 2011, and we are only halfway through the year.  It makes you wonder who Twitter's next acquisition will be.

from API Evangelist