API Evangelist

Lack of Pinterest API is a Lack of API Business Strategy

Fri, 25 May 2012 12:23:16 PDT

Here we are going into June, and I still don’t see a publicly available Pinterest API. Jay Yarow wrote in Business Insider back in February, "Pinterest's API Is Coming Soon, And VCs Are Super Excited" and Adam Duvander wrote in ProgrammableWeb, "Pinterest API: Coming Soon or Already Here?".

There is also a reply to a Quora thread by Yashh Nelapati, Lead Engineer at Pinterest from May 2011, saying the API is 2-3 weeks away. It’s now a year later and there is no official API (there is a Rogue API).

Business Insider says, Pinterest fears having a "Twitter problem”. Meaning that when Twitter released its API, it was still an immature company, allowing developers to build applications with features that it was missing--then Twitter matured, and it wanted to control its platform, it began adding building its own features and poaching from the Twitter API ecosystem.

So why not learn from Twitter and other APIs, and use the appropriate API building blocks to address this:

Branding Guidelines - Establish branding guidelines that clearly lays out what apps that use Pinterest API should look like
UI / UX Toolkit - Provide a UI / UX toolkit like Twitter Bootstrap that sets the tone for applications built on the API
Roadmap - Provide a real-time and transparent roadmap that developers can use to help keep their development efforts in line with Pinterest
Developer Framework - Establish a developer framework outlining opportunities for developers to become stronger members of API community, also introducing possible investment and incubation of most success or important features
Terms of Use - Establish a fair and equitable terms of use that protects Pinterests but acknowledges the commercial aspirations of developers
Events / Meetups - Establish a roadshow or network of meetups that brings developers together and makes them part of the Pinterest API community

These are just a few of the ways Pinterest could establish a solid business strategy for their API that would not only protect developer interests, it would establish the Pinterest API as an external research & development department, with a built in incubation component.

Pinterest has already missed out on a year of developers innovating on their platform. Why continue holding back innovation? Establish a flexible API business strategy that allows for you to learn from the mistakes made by Twitter, and become the platform VC’s are looking for you to become.

The API Driven Life of Your Facebook Mobile App

Fri, 25 May 2012 10:51:01 PDT

One of the best ways to explain what APIs are to someone sitting next to me on the plane is to find something the user does every day, that is driven by an API, and explain how an API drives the functionality they take for granted.

I tend to look for industry specific examples if they are an accountant or stock broker, but the most common example I use, is Facebook. Facebook is technology everyone I meet has exposure with.

My story always starts with Facebook.com, and how the social networking website was built for people. People go to www.facebook.com and they see HTML web pages, that allow them to interact with the community.

Next I move to the Facebook application on their mobile phone. While the application is built for people to use, the application needs a way to talk with Facebook--in comes APIs. APIs are a way for other programs to interact with Facebook, providing a interface for developers to build applications that use Facebook.

When you first login to Facebook on your mobile phone, the applications makes a request to the Facebook Authentication API, and gives your mobile application rights to interact with your Facebook account on your behalf.

After your logged into the Facebook application on your mobile app, every action you take will make an API call. When you click on your news feed, update your status, look at photos or check-in to a place, they each represent a different call to the Facebook Open Graph API. The Open Graph API exposes almost every aspect of Facebook as a programmatic interface that applications can use, hence the name Application Programming Interface (API).

Most online technologies that you use everyday have APIs. Amazon, EBay, Facebook, Twitter and Google all have APIs, allowing developers to build applications on top of their businesses, turning their websites into web services.

With the grwoth of the smart phone and tablet markets, the number of, and usage of APIs are exploding, silently driving the mobile applications like Facebook that are part of your everyday lives.

Visions from the API Economy

Thu, 24 May 2012 10:56:21 PDT

I’m always looking for solid examples of how more and more of our every day world is being driven by APIs. Examples I can use to help explain APIs to every-day business folks.

I came across one example that will speak to many business executives today via an Apigee Innovator Spotlight on their client TradeKing. When asked about the vision of their API program Dan Raju CIO of TradeKing says:

We are one of the top-ranked online brokerages in the country, growing very rapidly. We manage people's assets, give them a set of capabilities to trade, and offer an extremely transparent pricing structure. However, we recognized that our customers’ demands for next-generation interfaces are rapidly changing, and our API helps us stay in front of that. We anticipate that in the next phase, the API will be a meaningful revenue driver for us. It is already opening us up to new markets. We will continue to develop our own platforms on the API and incentivize and engage our development partners. At the end of the day, it’s all about delivering value to our customers, and the API will continue to help us drive increased value at an accelerated pace.

Raju hits on all the best of the API buzzwords including transparency, rapid change, meaningful revenue, open to new markets, and delivering value to end-customers.

I feel TradeKings vision of their API program, speak to larger visions of the API driven economy we are now immersed in, and provide a great example we can reference when helping other companies not just understand what an API is, but the imperative for their companies to embrace APIs and actively join the API economy.

Developer Insights Into Facebook Open Graph API Usage

Thu, 24 May 2012 10:31:46 PDT

Facebook provides an interface for Open Graph API developers to better understand how users are interacting with content via their applications, called Insights.

With Insights you can monitor the number of your unique users that are seeing and accessing a Facebook authorization dialog, number of unique users publishers stories through Open graph as well as viewing and clicking on those stories.

While the number of users clicking, viewing on stories is very cool, I’m interested in their stats regarding the authorization dialog. Insights provides data on how many times people access your dialog authorization, with the number of acceptances, while also breaking down the number of views, acceptances into a corresponding conversion rate.

If your authorization dialog prompts users for different permission sets, you’ll also see a breakdown of the impressions, accepts and CTR for each one, showing you the rates at which people accept and reject different permission sets--helping you to identify the most optimal permission set for your authorization dialog, which will directly help increase user installs for your app.

This kind of insights for developers is critical, helping them understand the level of engagement with users and build a more effective Auth Dialog flow, which could make or break an applications Facebook Open Graph integration and adoption.

Providing developers with analytics to evaluate their users API usage is so valuable, I wonder if I can find any other examples of this granular type of OAuth reporting with other APIs or from API service providers like Apigee?

Google Updates the API Explorer

Wed, 23 May 2012 16:24:45 PDT

Google just released an update to their API Explorer.

Some of the new features include:

Indexed history of API calls
API request body editor
Search box for search APIs and methods
Indicator showing which methods require authentication

The Google API Explorer now supports two dozen Google APIs, up from only six when they first launched.

Google’s continued investment in their API explorer, which makes APIs not just easier to use, but more accessible to non-developers, really shows that an API explorer has become an essential API building block.

Nike Sustainable Products Index API

Wed, 23 May 2012 09:22:07 PDT

Nike is working on a new API as part of their Nike Better World initative. The API provides access to a materials sustainability index, which evaluates the environmental impact of materials used by manufacturers.

The scoring system evaluates the environmental impacts of materials used in products using a combination of materials-specific data, covering areas such as Chemistry, Energy and Greenhouse Gas Intensity, Water and Land Use Intensity, and Waste.

The Nike Materials Sustainability Index API is only in alpha stage right now, and is undergoing for a peer review process with Duke University. You can follow their Nike Maker’s Blog to get more information on the initiative and get notified when the API will be available to the public.

How Are We Going to Track Private APIs?

Tue, 22 May 2012 11:37:19 PDT

Image Credit - Wiki Noticia

Adam Duvander (@adamd) reported at ProgrammableWeb today that they rolled over 6,000 public APIs in the directory. The pace at which companies are launching public APIs is accelerating, with the last 1,000 added in just 3 months.

Any of us in the space knows that this is just the tip of the iceberg, and Adam acknowledges that internal API usage is a major factor in API growth. While public APIs get all the major press, there are many private API initiatives that won’t see the light of day.

So my question is, how are we going to track on the growth of private APIs along with public APIs? Since mobile app development is such an important piece, can we count mobile apps produced by a company? Can we count on API service providers to start reporting on this data?

I don’t have the answer. It is something I think we need to figure out, not just so ProgrammableWeb can have its finger on the pulse, but there is an ever increasing amount of business and personal resources flowing through these API pipes, we need to have an understanding of where these API pipes are laid, which industries, etc.

Much like the rollout of fiber in the late 90’s, we are going to see massive API rollouts, without much oversight and map of where these virtual pipes are. I’d like to hear more about how we can work together to build a map of the back-end of the new API driven economy.

Find Your Hackathon Venue with EventUp

Sat, 19 May 2012 19:47:56 PDT

I am going through all my notes from organizing the CityGrid Los Angeles Hackathon and trying to publish as many stories as I can, about how I planned and organized the hackathon.

One service that was a catalyst for the event occuring, was assistance from EventUp. EventUp is a service that assists event venue owners in finding people to rent their space, and in turn can help you find the ideal location for your hackathon.

Tony Adam (@tonyadam) the owner of EventUp emailed me one day after I had submitted a request via eventup.com for more information on venues for my Hackathon in the Los Angeles area. He offered to help make sure I found the right location.

After a couple days he helped me secure CoLoft which was the best location for the hackathon imaginable. It was accessible, had great layout with tables, good wifi and the staff was extremely helpful.

EventUp isn’t in all markets yet, but if you’re planning a hackathon I recommend talking with Tony at Eventup, and seeing if they have the right location for your event.

App Center Best Practices

Wed, 16 May 2012 22:11:42 PDT

Last week Facebook announced a new App Center where developers can submit applications they've built. Like any API owner, Facebook is looking for high quality applications to list in its directory and has published a list of App Center Best Practices:

Websites must provide a personalized experience - All websites and mobile web apps need to immediately present authenticated users with a logged-in experience. Specifically, we’re looking for personalization, such as name and profile picture, so users know that their Facebook information is being used to create an account.
Review your app settings - App detail pages are dynamic based on the integrations you’ve specified on the basic settings page of the Developer App. Be sure to review this and remove any old or non-functional integrations.
Provide high-quality images - Your images should match the quality of your app. As specified in the guidelines, images shouldn’t have buttons, excessive text, borders, dropshadows, URLs, promotions, pricing, or third-party logos.
Input accurate names & thoughtful descriptions - Don’t add any additional keywords to the name of your app. Proofread your app description for spelling and grammar and remove unnecessary symbols, like stars, hearts and multiple exclamation points.

Some food for thought. Every app center will be different and have different requirements. I think I will add App Center Best Practices as a building block, after I look at a wide selection of other API app showcases, and identify some common best practices.

Products and Commerce with APIs

Wed, 16 May 2012 21:17:37 PDT

I am really starting to see my early visions of the Internet coming together. In my mind I see an interconnected world of products and commerce, where every business has an API.

APIs finally seem to be maturing, reaching a point where they can deliver at the scale and reliability we need, to really make this happen. Three good examples of this are:

The StructuredRetailProducts.com API - Providing to access to over 3 million individual product listings from 1700+ companies, representing total sales of over £3,382 billion and counting. Access 15+ years of product and market data across 72 different countries at the click of a button and get the latest data on sales volumes, activity levels, and market share.
The Elastic Path Digital Commerce API - A Digital Commerce Engine™ for driving any e-commerce experience, on any device or platform, allowing companies to build compelling product experiences, leverage new business models, and extend their reach to emerging end points.
Stripe API - A complete payment platform, that handles everything, including storing cards, subscriptions, and direct payouts to your bank account, without a merchant account or gateway.

When you look through those three APIs, you see the simplicity of REST + JSON, plus the essential building blocks to support developers, and the power and scalability you need to drive commerce in the API driven economy.

Developing More Meaningful API Metrics

Tue, 15 May 2012 20:52:49 PDT

API metrics are an essential, but what should we measure? There are two metrics that seems to dominate discussions about success of the API industry:

Number of New API Registration
Number of Daily and Monthly API Calls

Every API I’ve consulted with, use the same two metrics, if they have any at all. The tech blogosphere (driven by API service providers) have created a so call billionaires club, showcasing APIs that have over a billion API calls within a day or month.

Investors are even using the number of API calls as a metric to consider the valuation of a company, and seen as a good indicator of the demand for a company’s services.

I agree that new registrations and number of API calls are a start, but we should be able to identify many other metrics to truly measure the activity and success of an API and the sentiment of it's API developer community.

PeopleBrowsr API Restructures to Deliver More Meaning for Developers

Tue, 15 May 2012 13:18:18 PDT

Explaining to developers, what an API does, can be hard. How you describe your API, the underlying endpoints, can make or break user adoption. You shouldn’t be afraid to evolve, and keep trying to find the sweet spot in both the language and branding that you use in your API area.

I saw an example of this today, with the restructuring of PeopleBrowsr's APis. When I first starting playing with PeopleBrowsr's APIs, they were broken into 3 separate APIs:

PeopleBrowsr API
Kredentials API
Kred API

On the surface its really hard to know what each of these APIs does, but after I dove in I saw lots of value within individual methods, but I really had to spend time, getting to know each method, one by one. I saw the value, but the structure and presentation of the PeopleBrowsr API area, and the way the interfaces were assembled, didn’t immediately speak to this value.

Today they’ve restructured their three APis into a single API, dubbed the PeopleBrowsr Kred API, and grouped all the API methods into four logical groups:

Find Influencers - Pinpoints influential people on any subject or within communities connected by shared interests or affinities.
Deep Analytics - Author-based analytics which includes Kredentials (a single-screen summary of anyone’s social presence), historical Kred scores, reach, and friends & followers.
Action Analytics - Aggregated social data metrics for any keyword, hashtag or @name, including mention counts, word clouds and hashtag clouds.
Global Kred Score - Appends global Kred scores to @names or twitter IDs in web-based applications.

This new presentation immediately helps me understand which methods I should use based upon my goals. PeopleBrowsr took the time to understand how developers were using their API, and worked to present the API in a way that best speaks to this.

PeopleBrowsr also took the time to understand the value delivered via their API in each of these new areas and restructure pricing to reflect this value:

Find Influencers - $1.00 per call
Deep Analytics - .10 cents per call
Action Analytics - .01 cent per call
Global Kred Score - Free

Only time will tell if the new structure of the PeopleBrowsr Kred API will truly speak to developers that are looking to harvest insights from social media, but I like what they did to understand the needs of their developers, and work to better deliver the API presentation, documentation and pricing to reflect this need.

Make sure you are tuned into what your API developers are looking for and aren’t afraid to evolve and better serve your developer community.

Disclosure: I have consulted for PeopleBrowsr in the past.

USDA Releases API for Mandatory Livestock Reporting Data

Mon, 14 May 2012 17:25:56 PDT

USDA’s Agricultural Marketing Service (AMS) has released a new, publicly available web API for its Livestock Mandatory Reporting (LMR) system, offering access to all historical LMR data, allowing users to pull large amounts of customized data sets via a RESTful interface with JSON embedded URLs and XML formatted output.

"The Livestock Mandatory Reporting program facilitates open, transparent price discovery and provides all market participants, both large and small, with comparable levels of market information for cattle, swine, sheep, beef and lamb meat," said Craig Morris, Deputy Administrator of the AMS Livestock and Seed Program. "This new web service will provide our customers with additional resources to obtain large volumes of data."

In 2001, USDA’s Agricultural Marketing Service implemented the Livestock Mandatory Reporting program as required by the Livestock Mandatory Reporting Act of 1999, establishing a program to track information on the marketing of cattle, swine, lambs, and the products of such livestock, providing information that can be readily understood by producers to improve the price and supply reporting services of the Department of Agriculture, while also encouraging competition in the marketplace for livestock and livestock products.

A great example of APIs providing being used to manage and regulate industries while also letting markets freely operate, and encouraging competition. Imagine that, the best of both worlds.

APIs Have Been Copyrightable for 22 Years

Mon, 14 May 2012 13:40:06 PDT

I attended a great webinar put on by the folks at Apigee last week, where they discussed APIs & Copyright. A very timely discussion with the recent API copyright decision in the EU, and from the ongoing Oracle vs. Google case.

As I process all discussions around API copyright, I’m going to publish relevant pieces here at API Voice, for everyone else to process along with me. One interesting piece of the Apigee discussion is that APIs have been copyrightable for the last 22 years--specifically referencing the JOHNSON CONTROLS, INC. v. PHOENIX CONTROL SYSTEMS, INC. from October 3rd, 1989. On page three, it states:

"A computer program is made up of several different components, including the source and object code, the structure, sequence and/or organization of the program, the user interface, and the function, or purpose, of the program. Whether a particular component of a program is protected by a copyright depends on whether it qualifies as an "expression" of an idea, rather than the idea itself."

Beyond Johnson Controls, Inc v. Phoenix Control Systems, it appears there is further precedent to apply copyright to APIs. The filing also references:

See Harper & Row Publishers, Inc. v. Nation Enters.,471 U.S. 539, 547, 105 S.Ct. 2218, 2223, 85 L.Ed.2d 588 (1985); Data East USA, Inc. v. Epyx, Inc.,862 F.2d 204, 207-08 (9th Cir.1988); 17 U.S.C. § 102(b).

I think the questions API owners and developers should be asking themselves is not, whether or not they might have to think about API copyright protection in the future, but that it is something they should be discussing now, when it comes to their other legal API building blocks like terms of use, privacy and branding.

API Innovation at the Edinburgh Festivals

Mon, 14 May 2012 12:36:40 PDT

I’m always on the hunt for API stories that capture the power of APIs, showcasing how they are transforming industries and businesses around the globe. Today, my global API monitoring platform picked up one such story in Edinburg, Scotland.

In the summer of 2011, the summer-based Edinburgh Festivals made their event listings data publicly available for digital developers and technologists, via web APIs. There are seven events participating in the API:

Despite all the printed brochures and media coverage, with 44,000 performances in 3,000 separate venues, discovery, planning and finding what you want to see at the Edinburgh festivals is a near impossible task. Event organizers needed a way to provide the most up to date event information for the media and press, while also delivering the most enhanced experience possible for festival goers.

So, upholding their commitment to openness and innovation, the Edinburgh Festival organizers decided to release their data via API. With an API they hoped to challenge developers to build things that extended the reach of the festival, beyond what the event could do themselves.

Immediately festival organizers started seeing innovation around the API, and further encouraged developers with the Edinburgh Festivals Idea Challenge, offering prizes to the top 25 of 291 ideas submitted. The Edinburgh Festival API has spawned many projects including:

Festipods – a fun and engrossing way of visualizing the Edinburgh festival events that you have attended
Festivalclock.com - a beautiful visualisation of the summer festivals listings information
FakeFringe - a fun game where players have to guess which Fringe show description is real and which is the fake
Festafriend - a website that uses the festivals as a way for people to date and make new friends

Andrew Coulton (@acoulton), of the Ediburgh International Book Festival was very excited about APIs from the beginning, realizing there was a lot that they wanted to accomplish, but didn't have the resources internally to make happen, and had hopes that the API could help deliver. Coulton states that when you focus on providing the best quality data possible, building a developer community--that is when the most exciting things happen can happen around your API.

Looking back, Coulton says they had to focus on three key areas, to make the API happen:

Business - Making the business case for deploying an API
Technical - Overcoming technical challenges with deploying an API
Emotional - Overcoming historically proprietary attitudes of event organizers regarding their data

The Edinburgh Festival's innovation around their API is a great case-study for any business, arts, tourism or sporting event organizer, who wants to take their event to the next level. While there are definitely some major challenges to deploying a festival API, the potential for strengthening the event's brand, showcasing performers, keeping media up-to-date and creating the best possible experience for festival goers is massive.

Making Your API Accessible to the Masses

Thu, 10 May 2012 12:58:55 PDT

There are a lot of high value APIs emerging these days, APIs with access to essential business data, resources and intelligence.

When designing your API you want to make the interface as intuitive as possible, and ensure as wide as access to it as you possibly can. To quote Jonathan Schwartz, Sun CEO regarding Java APIs:

"We wanted to build the biggest tent and invite as many people as possible,” Schwartz said. “You have open APIs and compete on implementations."

To do this, I encourage building tools and widgets that non-developers can use when working with your API. A great example of this is at Google, with their Google Analytics Dashboard Library. Google wanted to make it easier for users to deploy a dashboard that was tailored specifically for their business, so using a team of University of California Irvine students, they set out to simplify it down to 3 steps:

Register with Google APIs Console.
Copy and paste the JavaScript code.
Configure this code to query your data and choose a chart type to visualize it.

Now, you still have to be JavaScript savvy to work with the Google Analytics Dashboard Library, understand how to edit your site, and be fluent in Google Analytics--but it’s a step closer to providing wider access to the power of the Google Analytics API, beyond just the development community.

LinkedIn also has some great examples of taking concept this to the next level with their “plugin” builders which essentially generates the widgets for users, using the API. Since Google is going to keep working with the Google Analytics Dashboard Library over the next 3 quarters, so I’m sure you’ll see their library evolve as well.

I’ll keep exploring other great examples of API embeddable strategies that can potentially bring in a much wider audience, opening up your API for access beyond developers, potentially bringing in other more business oriented groups.

The Flora and Fauna of the Twitter Ecosystem

Mon, 07 May 2012 00:06:54 PDT

Twitter has an innovative approach to presenting the objects that make up the Twitter Platform. They have built a field guide to Twitter Platform objects, designed like an Audubon Society field guide, describing the four primaty Twitter objects:

Tweets - Also known as a Status Update, Tweets are the basic atomic unit of all things Twitter. Users create Tweets. Tweets can be embedded, replied to, favorited, unfavorited, retweeted, unretweeted and deleted.
Users - Users can be anyone or anything. They tweet, follow, create lists, have a home_timeline, can be mentioned, and can belooked up in bulk.
Entities - Entities provide metadata and additional contextual information about content posted on Twitter. Entities are never divorced from the content they describe. After May 14th, 2012 Tweet Entities will be returned wherever Tweets are found in the API. Entities are instrumental in resolving URLs.
Places - Places are specific, named locations with corresponding geo coordinates. They can be attached to Tweets by specifying a place_id when tweeting. Tweets associated with places are not necessarily issued from that location but could also potentially be about that location. Places can be created and searched for. Tweets can also be found by place_id.

It is a creative way to educate users about the Twitter API, making it more visually appealing. Beyond that, I'm not sure it helps developers get up and running using the API, but who knows...it might make it more accessible to some users.

Have you seen any other creative wasy of displaying API documentaton?

Curated API Industry News Feeds

Sat, 05 May 2012 18:49:11 PDT

In my Google Reader I curate hundreds of articles pulled from 600+ blogs and 25+ real-time Google Alerts, on a daily basis. Everything I star in my Google Reader or Tweet about daily ends up in my Pinboard account. In addition to this curation, I bookmark every relevant site and post I come across in my daily surfing using the Pinboard bookmarklet.

Using the Pinboard API I setup a news curation system at API Evangelist which pulls my latest pinboards every 15 minutes and adds them to a curation queue which I monitor every couple hours. My API Evangelist curation system allows me to add comments and tags, further adding meaning to what I’ve already read throughout the day. Then using a combinations of tags, I route relevant news to API Evangelist and Hack Weekends.

These curated links represent the daily reading and research that goes into my writing and industry reports. I thought it would be good to share with you some of what I read on a daily basis, my random comments and insights, rather than just the final results.

APIs Help Deliver on Early Visions of the Internet

Thu, 03 May 2012 12:15:52 PDT

As my professional career moved online during the years between 1995 and 2000, I had numerous visions about what the World Wide Web could do for businesses. I think I shared these visions with millions of other individuals, fueling what we now know as the first Internet bubble.

I saw e-commerce driving entirely new businesses that could operate entirely online, and strengthen existing brick and mortar businesses allowing anyone to buy and sell goods and services from anywhere, instantly.

What we ended up with was still important, but the web 1.0 world was not quite as grand as I think some of us had envisioned. E-Bay, Amazon and Paypal definitely went further than many e-commerce platforms and service providers, and I firmly believe their embrace of web APIs was the reason for this.

While e-commerce has undeniably grown and evolved, other new concepts like social and cloud computing took center stage in creating an entirely new vision of the Internet, concepts we didn’t even conceive in the early days of the World Wide Web.

Years later, driven by APIs, I think we are just now beginning to deliver on the early visions of commerce on the Internet. E-commerce APIs like ElasticPath are delivering on this vision by offering up a mature and robust e-commerce engine completely accessible by a truly RESTful API.

Using ElasticPath you can define and execute against any vision of commerce whether it involves physical or virtual goods, with any type of pricing, offers or subscriptions that enable purchasing of these products on truly any platform or any device, in a myriad of ways only limited by your imagination.

ElasticPath delivers by starting with a hardened and complete e-commerce engine that drives clients like Google and Sony, and proven by driving extreme online and offline commerce scenarios like the Vancouver 2010 Winter Olympics. Next ElasticPath bundles a robust Level 3 REST API with the their e-commerce engine, providing not just programmatic access to every aspect of the e-commerce engine, but a hypermedia driven experience ensuring developers can deliver on the business logic and user experience defined by any company that deploys their e-commerce platform using ElasticPath.

If you’re not familiar with Level 3 REST also known as Hypermedia as the Engine of Application State (HATEOAS), it is an enhancement to REST, that enables a client to have no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. So in the context of e-commerce, when a developer requests a product the API, you get back the usual JSON describing the product, but you also get supporting media types for these “products”, and supporting link relations. So if purchasing the product means streaming in media player you will get media types as well as link to load into player, where if it is a product that you can add to shopping cart, you will get the link to add to cart, and so on.

I’m still learning about the technical details and benefits of HATEOAS REST, but i can see the benefits when bundled with ElasticPath’s very mature e-commerce engine. It allows you to not only build robust product catalogs that drive your website, but an e-commerce engine that can drive digital commerce across multiple platforms and devices, without developers having to fully understand the business rules and logic set forth by your company, leaving them to do what they do best, while ensuring your products, information and brand are reflected wherever your conducting e-commerce.

I guess e-commerce isn’t the only vision of the Internet, but it definitely is a large part of it, and I think APIs have been fueling the growth of e-commerce since the first part of the last decade, and now with platforms like ElasticPath we will truly see this vision mature and allow us to sell physical and digital goods anywhere in the world, in real-time.

Tools of the CityGrid Los Angeles Hackathon

Wed, 25 Apr 2012 22:46:34 PDT

We have a pretty awesome line-up of tools, platforms and APIs for people to use when building their local web and mobile apps this weekend at the CityGrid Los Angeles Hackathon:

3Scale (@3Scale) - A Plug & Play Cloud based API Management Infrastructure for Developers, Startups, SMBs and Enterprises to securely open, control, manage and monetize their API to 3rd parties.
CityGrid (@CityGridAPITeam) - Places, offers, reviews APIs and mobile, web and custom advertising with places that pay.
CloudyRec (@Cloudyrec) - CloudyRec is a mobile app scaffolding engine with integrated Backend-as-a-Service (BaaS).
Factual (@Factual) - Places, Products, Health, Education, Government and Entertainment accessible via database and API, with a Resolve API providing places intelligence and Crosswalk API identifying places across multiple systems like Foursquare, Yelp and Facebook.
GeoCoda (@GeocodaHQ) - Simple Geocoding API providing information about any U.S. address via an HTTP API, and a spatial database to store and manage location-based information.
IPGP (@IPlookup) - IPGP is a site that lets users lookup the location of their site's visitors based on their IP addresses.
Iron.io (@Getiron) - Iron.io provides massively scalable cloud application services: IronWorker, a massively parallel worker platform and IronMQ is an elastic message queue as a service.
Jeppesen (@JeppesenJP) - Jeppesen Journey Planner is a cost effective way to integrate public transit information into your own website or mobile application.
Socrata (@Socrata)- Open Data Services for federal, state, and local governments to dramatically improve the reach, usability and social utility of their public information assets.
Spire.io (@Spireio) - A real-time messaging service as the first in a set of hosted, secure, and scalable APIs built for mobile and web application development.
Tiggzi (@tiggziapps) - Cloud-based Builder for HTML5, jQuery Mobile, and PhoneGap Apps, allowing connection to REST APIs, and Export for Android, iOS, or Mobile Web.
Verious (@Veriously) - A marketplace for mobile application components, enabling iOS and Android developers to license pre-built, pre-tested libraries to accelerate time-to-market, access 3rd-party platforms and increase in-app monetization.

The CityGrid Los Angeles Hackathon is sold out, but you can follow the event on Twitter using the hashtag #citygridhackathonLA.

Developers, Take 10 Seconds to Respond When Your API Evangelist Reaches Out

Mon, 23 Apr 2012 15:59:42 PDT

The best thing about owning API Evangelist is I get to write about whatever I want. I have full editorial control, and because of my unique view on the API space I tend to write about APIs from three separate perspectives:

API Owner
API Service Provider
Developer

These are the three main actors in the API game. There are others, but these are the three viewpoints I write about the most. I tend to rail on API owners a lot, and today I think I will rail on API developers.

Currently I’m doing a lot of reaching out to my developers. I personally email everyone who registers for CityGrid APIs. Sure I use template emails, but I customize them and send the email one by one so I can profile my API developers and understand what they are doing.

So far, my findings are that many developers don’t have any sort of verifiable online persona, and even more don’t bother responding when I email or tweet at them. Its not my business to police the CityGrid APIs, but I definitely apply a grade to every developer I look at, and make recommendations based upon this grade, where online persona and responsiveness are two big factors.

We hear a lot of developers (me included) complain about API owners not being responsive, but remember there is another side to the coin. If you're using someone’s API for FREE, and they take time out of their day to email you or tweet at you, it might be cool if you took 10 seconds to respond and say hello, and let them know you're an actual person.

API as the Deliverable at the Hackathon

Mon, 23 Apr 2012 14:40:27 PDT

At most hackathons, the end goal is building a web or mobile application, using various platforms and APIs. Even though I’ve seen this evolve to data visualization, or mashing up SaaS platforms at some events, the app really tends to be the primary deliverable at hackathons.

So this week I’m spending time thinking of unique and interesting ways to present my sponsors for the CityGrid Hackathon this weekend in Santa Monica at CoLoft. One of our sponsors is 3Scale, one of my favorite API service providers, and while we see many of the API service providers including Apigee and Mashery involved in many of the hackathons you really don't see anything built using their platform. (I know they’ll ping me and say they do, but really your building using their clients.)

So for the CityGrid Los Angeles hackathon, I want to encourage developers to come up with ideas for APIs, develop the API and using 3Scale, deploy the building block that are essential that enable other developers to build on top of the API.

Not only do we need more, high value APIs, we need developers to be fluent in not just developing and deploying mobile and web apps, developers need to be fluent in designing, developing, deploying and managing APIs.

So if you have a great API idea and are in the Los Angeles area this weekend, come down to the CoLoft in Santa Monica and form a team and build your API, and deploy it using 3Scale, and you just might have a chance at winning $5,000.00 for your API.

APIs Are Forever, Wait No...They Can Go Away at Any Time!!!

Fri, 20 Apr 2012 17:56:39 PDT

One of my self-appointed roles in the API industry is to shed light on, and discuss the business of APIs when many other API owners and evangelists tend to keep their strategy and business closer to their chest.

Many API owners don’t discuss their roadmaps, either because they feel they will be giving away their secret sauce, or quite possibly because they don’t have a clue where they are going with it. I think it’s more the latter, as we are all making this shit up as we go along.

One subject you don’t hear API owners discuss often, is when their API will be deprecated or shuttered, leaving developers and tech bloggers to speculate on the subject. Because of this you tend to hear just the extreme views on the subject. Popular perspectives on API life-span tends to be:

APIs Are Forever - Once you put an API, you have to support it forever
APIs Can Go Away Anytime - There is no stability whatsoever when it comes to APIs

I’ve written on this subject several times including What Happens to Instagram API Developers After Facebook Acquisition and Building Your Business Around Google or Any Other APIs.

Even with my stance on the subject I fall prey to the hype sometimes. I saw the post from Google today called Changes to deprecation policies and API spring cleaning, and I immediately thought oh no, here we go again. After reading deeper I realized they are updating their API deprecation policy for many popular APIs. As they state:

The new policy simply states that we will strive to provide one year notice before making breaking changes.

Google is setting a clear window, for which they will make sure and give developers a heads up before deprecating an API. This allows you to know that you can count on an API being around, until you hear otherwise, and then, you still have a year to figure out what you are going to do.

I know this is something other API owners do, but it rarely is something you hear any news about, giving the API extremists free range to use page view grabbing headlines about APIs owners being no better than satan, and eat their developers for dinner.

I’m going to work on a more formal post about API deprecation policies, and how API owners can put them to use, setting better expectations around API life cycles.

Will a Self-Service API Area Ever be Enough?

Tue, 17 Apr 2012 18:20:17 PDT

One of the essential ingredients of a successful API, is a self-service area to support your API developers. In my opinion this is a no-brainer. You have to have registration, documentation, code samples, forum and other essential API building blocks available to developers in a self-service way--so they can engage with your API 24/7 without asking for access.

I’ve worked hard to make sure the CityGrid API area has a logical navigation, taking developers to the essential information they will need to learn about and integrate with the APIs:

With those 13 links you can get to everything you need to know about the CityGrid Places, Offers, Reviews and Mobile, Web and Custom Advertising APIs.

I keep a regular flow of information going through the blog to make sure there is excellent SEO content, so developers can search for anything at Google, and the blog will support linking to whats relevant in the CityGrid Developer Center.

Even with all of this, I still get some pretty basic questions like:

I need PHP code samples? - Immediately available on the code samples page.
What does the API cost? - Says that it is FREE on Getting Started and FAQ.
Can I save your data in my database? - Says it on the Usage Requirements
Do I have to show your logo? - Says it on the Usage Requirements

That is just the tip of the iceberg. I’ve posed this question before...are there enough doers in the world to make this whole API vision work? It’s hard to tell if its just my view, while in the pit of despair, or if it is just the way it is.

It seems like there will always be some users who need hand holding, and they refuse to read the self-service material available in the API area. When I’m hacking on an API, I always make sure I search exhaustively before I ask a question, but I’m discovering a new breed of developers who won’t search, won’t ask questions--then when you reach out to them they’ll ask for what they need, no matter how basic.

It seems, that self-service API resources are essential, but there will always be a segment of our audience who aren’t quite doers, they need more hand-holding and information presented to them before they get what they need.

Profiling API Developers

Tue, 17 Apr 2012 15:54:52 PDT

For the last couple weeks I’m neck deep in getting to know the developers who already use the CityGrid APIs. I want a better understanding of who a developer is, what kind of business they have and what they are looking to get out of the API.

To find this out I start out profiling them socially using Rapportive (which I plan on automating using the Full Contact API as soon as I have more time) for the following information:

Twitter Profile
LinkedIn Account
Facebook Profile
Google + Profile
Github Profile

Usually I know the URL of their website, but if I don’t, I can extract from their email address or sometimes Rapportive will provide for me. I visit each developer’s site and look for:

Blog w/ RSS Feed
Business Contact Email
Business Contact Form

Next I build a quick one sentence description, telling me who they are and what they do. I also assemble a comma separated list of keyword and key phrases that best represent what they do.

Before I’m done looking around their site I take a picture of their home page, so I have a visual reference to go with the developer profile. The home page image can go further than just a logo sometimes.

I take all of this information, put it into a database, and connected it to a JQuery Carousel that allows me to watch a slideshow that walks me through the world of my developers, and watch like a TV channel.

This process not only gives me a 100K understanding my developer ecosystem, but helps me remember as much as I can about each developer. From this I hope to better engage them on a daily basis as well as provide feedback to the CityGrid API roadmap based upon quality API developer segmentation.