RSS

API Communications News

These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.

When Describing Your Machine Learning APIs Work Extra Hard To Keep Things Simple

I’m spending a significant amount of time learning about machine learning APIs lately. Some of what I’m reading is easy to follow, while most of it is not. A good deal of what I’m reading is technically complex, and more on the documentation side of the conversation. Other stuff I come across is difficult to read, not because it is technical, but because it is more algorithmic marketing magic, and doesn’t really get at what is really going on (or not) under the hood.

If you are in the business of writing marketing copy, documentation, or even the API design itself, please work extra hard to keep things simple and in plain language. I read so much hype, jargon, fluff, and meaningless content about artificial intelligence and machine learning each day, I take pleasure anytime I find simple, concise, and information descriptions of what ML APIs do. In an exploding world of machine learning hype your products will stand out if they are straight up, and avoid the BS, which will pretty quickly turn off the savvy folks to whatever you are peddling.

Really, this advice applies to any API, not just machine learning. It’s just the quantity of hype we are seeing around AI and ML in 2017 is reaching some pretty extreme levels. Following the hype is easy. Writing fluffy content doesn’t take any skills. Writing simple, concise, plain language names, descriptions, and other meta data for artificial intelligence and machine learning APIs takes time, and a significant amount of contemplation regarding the message you want to be sending. The ML APIs I come across that get right to the point, are always the ones that stick around in my mind, and find a place within my research and storytelling.

We are going to continue to see an explosion in the number of algorithmic APIs, delivering across the artificial intelligence, machine learning, deep learning, cognitive, and other magical realms. The APIs that deliver real business value will survive. The ones that have simple intuitive titles, and concise yet informative description that avoid hype and buzz will be the ones that get shared, reused, and ultimately float to the top of the pile and sticking around. I’m spending upwards of 5-10 hours a week looking through AI and ML API descriptions, and when I come across something that is clearly bullshit I don’t hesitate to flag, and push it back to the back warehouses of my research, keeping my time focused on the APIs which I can easily articulate what they do, and will also make sense to my readers.

Photo Credit: Bryan Mathers (Machine Learning)


A Lack Of Communication Around Federal Government APIs

I personally understand the challenges with communicating publicly when you work for the federal government. It is one of the top reasons I do not work in federal government anymore. It would kill me if I couldn’t blog each day without friction–it is how I create and ideate. Even with this understanding I find myself regularly frustrated with the lack of communication by owners of APIs across federal government agencies. There are numerous agencies who do successfully communicate around their APIs and open data projects, but the majority of APIs I come across have little, or no communication around their API operations.

Have a blog, Twitter, or Github account might seem like a nice to have, but in reality they are often the only sign that anyone is home, and an API is reliable, and make the the difference between choosing to integrate with an API, or not. A blog or Twitter account, and whats new feature box on the home page of an API developer portal can send the winning (or losing) signal that an API is actually active and alive. Developers come across a lot of APIs that are dormant or abandoned, and the presence of common communication channels (blog, Twitter, Facebook, LinkedIn, Github) are the signal we often need before we are willing to invest the time into learning another new API, or signing up for yet another developer account.

I know that it is possible to handle API communications in a healthy way at government agencies–18F, Census, and others are doing it right. There is some serious storytelling friction occurring in government. I see the same illness in corporate and other institutional API platforms–geeks and IT folks aren’t always the best at getting the word out about what they are doing. However, I think there is additional friction at the government level. We’ve seen a significant increase in blogging, and social network usage usage across government agencies, we need to investigate how we can incentivize federal government API operators to get a little more chatty with their work.

Communication around API operations is an essential building block. Federal government isn’t immune to this. If you aren’t telling the story about why developers should be using it, and actively communicating with your integrators, you will never find the success you seek when doing APIs at your agency. You don’t have to launch a wildly active and popular blog or social media presence. You just need something. A simple blog with RSS, hosted on your Github account. A Twitter account. Something. Please. Anything. Thank you!


The Most Important Aspect Of The API Discussion Is Learning To Think Outside Our Boxes

There are many good things to come out of doing APIs properly. Unfortunately there are also many bad things that can come out of doing APIs badly, or with misaligned expectations. It is easy to focus on the direct benefits of doing APIs like making data resources available to partners, or maybe developing a mobile application. I prefer looking for the more indirect benefits, which are more human, more than they are ever technical.

As I work with different groups on a variety of API definitions and strategies, one very significant part of the process I see, is people being forced to think outside their box. APIs are all about engaging around data, content, and algorithms on the web, with 3rd parties that operate outside your box. You are forced to lookup, and outward a bit. Not everyone I engage with is fully equipped to do this, for a variety of reasons, but overall the API process does make folks just a little more critical than they do with even their websites.

The web has come with a number of affordances. Those same affordances aren’t always present in API discussions forcing folks to have more conversations around why we are doing APIs (an answer shouldn’t always be yes), and discussing the finer details not just storing your data, and managing your schema, but doing in a way that will play nicely with other external systems. You may be doing things one way internally, and it might even be working for you, but it is something that can only get better with each outside partner, or consumer you are exposed to along your journey. Even with all of the internal politics I encounter in my API conversations, the API process always leaves me enjoying almost any outcome.


Writing API Stories That Influence Your View Of Technology

I know that some of my friends who follow API Evangelist shake their heads when I talk about API business models, partner programs, and many of the business sides of API operations. Much of my work will have an almost delusional attraction towards the concept of an API. Heavily doused in a belief in technology as a solution. This isn’t accidental. This is API Evangelist. A persona I have developed to help me make a living, and help influence where we go (or don’t go) with technology.

I am delusional enough to think I can influence change in how the world uses technology. I’m borderline megalomaniac, but there really is not sufficient ego to get me quite all the way there. While still very, very, very minor, I feel I have influenced where technology has flowed over my seven years as the API Evangelist. Even if it just slowing the speed (seconds) at which the machines turn on us, and kills us all. If nothing else, I know there are few folks out there who I have touched, and shaped how they see, use, and allow technology in their lives (cause they told me so).

Through my storytelling on API Evangelist, I am always looking for the next convert–even if it takes years and hundreds of stories. A significant portion of this outreach involves telling stories that reach my intended audience–usually startups, business, institutional, and government agency workers and influencers. To reach them I need to tell stories that speak to them, and feed their current goals around finding success in their startup, or their role within businesses, institutions, and government agencies. With this in mind, I am always trying to bend my stories in their direction, talking about topics that they’ll care about, and tune into.

Once I have their attention, I will work on them in other ways. I’ll help them think about their business model, but also help them understand transparency and communication when it comes to executing this model. I will help them understand the best practices for managing an API using open source solutions like Tyk or Dreamfactory, and the leading approaches to using Runscope for monitoring and testing, while also encouraging them to me more observable with these practices. Making sure companies tell stories about what they are doing, and how they are doing it all–the good and bad.

I’m always working to build bridges to folks who might not see this whole API thing like I do. I’d say that many of these bridges will never get fully walked across by my target audience, but when someone does, and my stories influence the way they see or use technology even a little bit–mission accomplished. I’m constantly testing new ways or reaching out, speaking in the language of my target audience (without selling out), using trendy terms like microservices, devops, and serverless, but this isn’t just about following the latest fad. It is meant to capture your attention, build some trust, and then when it matters I can share some information about what really matters in all of this–in hopes of influencing how you see technology, and how it can be used a little more sensibly, securely, or maybe not even at all. ;-)


Having The Right Communications Pipeline For Your API Platform

My friend Matthew Reinbold, formerly of Vox Pop, and now the Lead for the Capital One API Center of Excellence, as well as the maintainer of web API events has shifted his blogging platform to use Github, using Jekyll. Ok, yawn, why is this news? Someone is shifting the underlying platform for their blog. Well, first Matt is one of the leading API practitioners in the space, who is also a storyteller. Second, his approach highlights a set of tools that other API providers should be considering for their API communications pipeline.

Matt is using a pretty potent formula for his communications platform in my opinion, with a handful of essential ingredients:

  • Github - Using a Github repository as the open source folder for your website.
  • Github Pages - Using Github Pages to publish the front-end for your website.
  • Jekyll - The content management system that sits in the folder for your website.
  • CloudFlare - The DNS and SSL front-end for your website, complete with analytics.
  • Hover - The registrar for the domain which you offload DNS management to CloudFlare.

Matt is taking advantage of the benefits of static website development, which some of the benefits are, as Matt describes:

  • SPEED - There’s no processing server side; posts have already been reduced to the essential atomic units of the web: HTML, Javascript, and CSS. There’s something poetic to me about that.
  • Security - While not so much an issue with my own coded CMS, I lived in constant fear of missing a zero-day Wordpress exploit patch and finding myself, along with clients, compromised. Reducing the number of moving parts significantly decreases the places where something might go wrong.
  • Hosting - Rather than having to find, research, and deploy to increasingly rare ColdFusion hosts (or port to another language), I can post my content to anywhere that supports HTTP/JS/CSS. hosting. This becomes very compelling given that Github Pages, one option, is free.

This is the cheapest and quickest way for your API to get a blog stood up, and get publishing stories about the value your API is bringing to the table. This approach isn’t just limited to your developer portal or engineering team blog, this could be for partners, or any API related project that you are running. I publish a static Jekyll blog for each area of my research, and I try to always have one for each of my data, or API tooling project–telling the story of each project that is independent from the API Evangelist blog, providing a static log of everything that has happened.

Github isn’t just a pipeline for code, it can be a pipeline for your communications and storytelling. It also can be a pipeline for your documentation, how-to-guides, and other resources. I’m happy to see Matt putting it to be use. Another thing I like about his post, other than him mentioning me ;-), is that he also mentioned the benefits of this approach over using Medium, which is something I’ve been advising API providers against for some time. In my opinion you are better off publishing your blog like Matt has, and then syndicating to Medium if you want. There is a lot more detail available on Matt’s story behind his new blog strategy, I recommend heading over and learning from what he’s done.


Three Rules Of My API Communication Strategy

Communicating effectively around API operations is the number one illness I see across the API space. Engineers are good at writing code and devopping their way to a usable API, but often fall short when it comes to telling the story of what the API does, and consistently beating this drum until people become familiar with what is going on.

An effective API communication strategy is more art than it is science, and I’d like to share three of my rules when it comes to telling stories on the API Evangelist platform.

  • Honesty - Be honest with yourself, you’re readers, and those you are writing about. If you can’t find a way to be honest in your writing go find a new job–it won’t be sustainable.
  • Consistent - Communicate every day. Ok, maybe every other day. Regardless of frequency, make sure you are communicating on a consistent basis, setting the tone for what your audience can expect.
  • Compelling - Make it compelling. No, not every single post will be compelling, but make it your primary goal to tell a compelling story that you would read yourself, if it was on someone else’s blog.

That is it. Don’t sweat all the technical details. Just write on the blog, spend the time on Twitter, participate in threads on Github, and regularly dive into the bowels of the Slack. Don’t spend all your time worrying about your communication strategy, just make sure you give it a sensible amount of time, and follow these three rules–the rest will come.

As of this moment, there are 2,680 blog posts on API Evangelist, with the first entry in September 2010. These three rules have kept me on track when I was taking money from bigcos like Intel and Mulesoft, and kept me from losing my shit when I was traveling and drinking too heavily. These three rules are what keep me doing this effectively after seven years.


The Yes I Would Like To Talk Button When Signing Up For An API Platform

There are never enough hours in the day. I have an ever growing queue of APIs and API related services that I need to play with for the first time, or just make sure and take another look at. I was FINALLY making time to take another look at the RepreZen API Studio again when I saw that they were now supporting OpenAPI 3.0.

I am still driving it around the block, but I thought the second email I got from them when I was signing up was worth writing about. I had received a pretty standard getting started email from them, but then I got a second email from Miles Daffin, their product manager, reminding me that I can reach out, and providing me with a “Yes I Would Like To Talk Button”. I know, another pretty obvious thing, but you’d be surprised how a little thing like this can actually break us from our regular isolated workspace, and make the people behind an API, or API related service more accessible. The email was pretty concise and simple, but what caught my eye when I scanned was the button.

Anyways, just a small potential building block for your API communication strategy. I’ll be adding the list I am cultivating. I’m not a big hard sell kind of guy, and I appreciate soft outreach like this–leaving it up to me when I want to connect. I’ll keep playing with RepreZen API Studio and report back when I have anything worth sharing. I just wanted to make sure this type of signup email was included in my API communication research.


Weekly Roundups vs Short Stories

I process a lot of stories each week, which I do not think is at all unique. While I tend to read short, medium, and longer form pieces, I notice that people tend to tune into my shorter, more concise pieces. I’m an aggregator, analyst, so people probably are looking to me to understand what is going on and in turn I’m looking for individual API providers and service providers to help me keep in tune with what is going on with their operations–I depend on blog posts, change logs, and other common building blocks to do my work.

One recommendation I have for API providers and service providers when it comes to their communication strategies is to provide short concise blog posts regarding specific goings on. Make your blog posts like your API resources–doing one thing and doing it well. You can still do a round-up at the end of the week providing an executive summary, but don’t cut out the short individual blog posts. In my experience, people tend to read titles, tweets, and don’t have much attention span beyond 300 to 500 words. Personally, if I am busy, the first thing I cut out each week is the lengthy weekly roundups from providers–I will scan, but really do not read much of the detail if something catches my eyes.

This advice isn’t for other aggregators and analysts. Your job is to round up and provide and overview of what is going on. My advice is for individual API providers looking to update everyone with what is going on with their API operations, services, tooling, customers, and other common things you should be evangelizing and communicating as part of your regular operations. This is just some feedback from someone who is passionate about consuming as much information as I possibly can each week. Many short stories are better than just a single round-up, and you tend to get better search and social media bang for your buck when you have well-crafted titles, and a short body, that focuses on a single topic. Think of your API communication strategy similar to your microservices approach and I think you’ll get the reach you are looking for.


Icons To Describe Each Of Your API Resources Like AWS

Amazon Web Service teams sure have been rocking their architectural icons across their storytelling lately. They standardized a set of icons for each of their cloud services and published in a variety of formats as the AWS Simple Icons for Architecture Diagrams. I am a big fan of the Noun Project API for use across my storytelling and find that having a standardized library of meaningful images and icons to be extremely valuable in helping quickly convey meaning (or entertain).

I was reading optimizing Amazon S3 for high concurrency in distributed workloads from AWS, and the diagram they provided, daisy chaining each of the AWS services at play, really brought the concept home for me. I read a lot, but I also scan a lot, and meaningful diagrams like this can go a long way to help me get up to speed as quickly as possible.

I have been an advocate for establishing icon sets for common API technologies, and even service providers, and I think I will add individual API resources to the stack. It would be valuable to have icon sets for common API resources like images, video, storage, etc. Icons that spoke to what they did, but also clearly identifies them as an API resource and allowing them to possibly be daisy chained together like Amazon does.

API industry icons will have to wait until some benefactor steps up to invest in this crazy idea. I'm graphically challenged, I know what looks good, but I can't craft anything graphical to save my life--look at my logo. Even if we don't have an industry-wide set of icons, it might be something individual API providers would want to consider creating for their API resources, like Amazon does. It is something that could help make your storytelling more impactful, and provide a common set of icons for everyone to use when referencing specific API resources.


Amazon Alexa As An Example When It Comes To API Communications

I'm always looking for specific API providers to showcase as examples we can follow when crafting different portions of our API strategies. The Amazon Alexa team is doing a pretty kick ass job at blogging, and owning the conversation when it comes to developing conversational interfaces, so I thought I'd highlight them as an example to follow when planning the communications portion of your strategy.

Take a look at the #Alexa tag for the AWS blog. They have a regular stream of storytelling coming out of the platform. Its a mix of talking about the tech of the platform, and showcasing what it can do. What really captured my attention for this story is there regular showcasing of the interesting solutions developers are building on top of the platform. Many platform blogs I read are a one trick pony, just talking about their service, and I think the AWS Alexa team has found a compelling blend.

Ok, AWS probably has just a few more resources than your API team, but trust me, one person can do a lot when they are really engaged. I produce at least five posts a day (ok, they are ranty and weird), and always work to keep thing as diverse as possible, and not about my products or services (fact I don't have any probably helps as well). I do not recommend you using API Evangelist as a model for your platform blogging. I do recommend you use Amazon Alex as a model for how you can create a compelling API platform communication experience.


Details About The 52 Online Services I Depend On

I went through all the online services I use, and made sure all of them are listed, and I understood more about why and how I use a service. So far I have 52 servies I depend on, providing a pretty good map of my online domain.

3Scale

  • Why do I use this service? API Management
  • What content do I generate via this service? user, access and traffic logs
  • Do I pay for this service? - Yes
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes via email
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? No
  • Do I currently integrate with this services API? - No

about.me

  • Why do I use this service? - Profile Page
  • What content do I generate via this service? None
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes - http://about.me/developer/sdk/docs/
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Alchemy API

  • Why do I use this service? - Text Extraction
  • What content do I generate via this service? None
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - Yes 
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Amazon Web Services (AWS)

  • Why do I use this service? - Central hosting and stroge
  • What content do I generate via this service? None
  • Do I pay for this service? Yes
  • Does this service provide data portability? - Yes
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

Angellist

  • Why do I use this service? - Business Profile
  • What content do I generate via this service? None
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes  https://angel.co/api
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

Anypoint Platform

  • Why do I use this service? API Management
  • What content do I generate via this service? APIs
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Apiary.io

  • Why do I use this service? API Design
  • What content do I generate via this service? APIs
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

AT&T

  • Why do I use this service? - Mobile Phone
  • What content do I generate via this service? None
  • Do I pay for this service? Yes
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Crunchbase

  • Why do I use this service? - Business Profile
  • What content do I generate via this service? Profile
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

Disqus

  • Why do I use this service? - Commenting
  • What content do I generate via this service? Comments
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Dropbox

  • Why do I use this service? - Storage
  • What content do I generate via this service? Files
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - Yes
  • Do I currently integrate with this services API? - No

Drupal

  • Why do I use this service? - Nothing
  • What content do I generate via this service? None
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Dwolla

  • Why do I use this service? - Payments
  • What content do I generate via this service? Payments
  • Do I pay for this service? Yes
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

DZone

  • Why do I use this service? - Blog Syndication
  • What content do I generate via this service? Blog Syndication
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

EventBrite

  • Why do I use this service? - Event Management
  • What content do I generate via this service? Events
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

Evernote

  • Why do I use this service? - Notetaking
  • What content do I generate via this service? Notes
  • Do I pay for this service? Yes
  • Does this service provide data portability? - Yes
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - Yes
  • Do I currently integrate with this services API? - No

Facebook

  • Why do I use this service? - Social
  • What content do I generate via this service? Messages, Photos, Videos, Friends
  • Do I pay for this service? No
  • Does this service provide data portability? - Yes
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Flickr (Yahoo)

  • Why do I use this service? - Manage photos
  • What content do I generate via this service? Photos
  • Do I pay for this service? No
  • Does this service provide data portability? - Yes
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Foursquare

  • Why do I use this service? - Track my locations
  • What content do I generate via this service? Checkins, Photos
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

FullContact

  • Why do I use this service? - Contact Profling
  • What content do I generate via this service? Profile
  • Do I pay for this service? Yes
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

Geeklist

  • Why do I use this service? - Developer Profile
  • What content do I generate via this service? Profile
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Github

  • Why do I use this service? - Manage all projects
  • What content do I generate via this service? Websites, Code
  • Do I pay for this service? Yes
  • Does this service provide data portability? - Yes
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

Gliffy

  • Why do I use this service? - Diagramming
  • What content do I generate via this service? Diagrams
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

GoDaddy

  • Why do I use this service? - Domain Management
  • What content do I generate via this service? Domains
  • Do I pay for this service? Yes
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - Yes
  • Do I currently integrate with this services API? - No

Google

  • Why do I use this service? - Primary account
  • What content do I generate via this service? Email, Contacts, Calendar, Documents
  • Do I pay for this service? No
  • Does this service provide data portability? - Yes
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - Yes
  • Do I currently integrate with this services API? - Yes

Hacker News

  • Why do I use this service? - News syndication
  • What content do I generate via this service? Bookmarks
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Hover

  • Why do I use this service? - Domain Management
  • What content do I generate via this service? Domains
  • Do I pay for this service? Yes
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

IFTTT

  • Why do I use this service? - Automation
  • What content do I generate via this service? Jobs
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Instaper

  • Why do I use this service? - Reading service
  • What content do I generate via this service? Bookmarks
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Klout

  • Why do I use this service? - Social Ranking
  • What content do I generate via this service? No
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No
  • Laneworks - http://control.laneworks.net/admin/

Lanyrd

  • Why do I use this service? - Event discovery
  • What content do I generate via this service? Events
  • Do I pay for this service? No
  • Does this service provide data portability? - Yes
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

LinkedIn

  • Why do I use this service? - Social
  • What content do I generate via this service? Messaging, Links
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Mashape

  • Why do I use this service? - API Management
  • What content do I generate via this service? API Profiles
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Meetup

  • Why do I use this service? - Event Discovery
  • What content do I generate via this service? Events
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

Mega

  • Why do I use this service? - File Storage
  • What content do I generate via this service? Files
  • Do I pay for this service? No
  • Does this service provide data portability? - Yes
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Noun Project

  • Why do I use this service? - Image Discovery
  • What content do I generate via this service? Images
  • Do I pay for this service? Yes
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Paypal

  • Why do I use this service? - Payments
  • What content do I generate via this service? Payments
  • Do I pay for this service? Yes
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

Pinboard

  • Why do I use this service? - Bookmarking
  • What content do I generate via this service? Bookmarks
  • Do I pay for this service? Yes
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

Plancast

  • Why do I use this service? - Event discovery
  • What content do I generate via this service? Events
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Quora

  • Why do I use this service? - QA
  • What content do I generate via this service? Questions, Answers
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Reddit

  • Why do I use this service? - Bookmarking
  • What content do I generate via this service? Bookmarks
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Serve

  • Why do I use this service? - Payments
  • What content do I generate via this service? Payments
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Soundcloud

  • Why do I use this service? - Audio Discovery
  • What content do I generate via this service? Audio Files
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Square

  • Why do I use this service? - Payments
  • What content do I generate via this service? Payments
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

Stack Overflow

  • Why do I use this service? - QA
  • What content do I generate via this service? Question, Answers
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

StumbleUpon

  • Why do I use this service? - Bookmarks
  • What content do I generate via this service? Bookmarks
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Thingiverse

  • Why do I use this service? - 3D Printing
  • What content do I generate via this service? 3D Designs
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Tumblr

  • Why do I use this service? - Blogging
  • What content do I generate via this service? Blog
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - Yes
  • Do I currently integrate with this services API? - No

Twitter

  • Why do I use this service? - Tweeting
  • What content do I generate via this service? Tweets, Friends
  • Do I pay for this service? No
  • Does this service provide data portability? - Yes
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

VectorStock

  • Why do I use this service? - Stock Images
  • What content do I generate via this service? Images
  • Do I pay for this service? Yes
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - No
  • Does this service have an API? - No
  • Does this service offer oAuth? - No
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Yahoo

  • Why do I use this service? - Profile
  • What content do I generate via this service? Profile
  • Do I pay for this service? No
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - No

Zapier

  • Why do I use this service? - Automation
  • What content do I generate via this service? Jobs
  • Do I pay for this service? Yes
  • Does this service provide data portability? - No
  • Can I terminate my use of this service? - Yes
  • Does this service have an API? - Yes
  • Does this service offer oAuth? - Yes
  • Does this service offer 2 Factor Authentication? - No
  • Do I currently integrate with this services API? - Yes

I think I will need to build some sort of tracking system for the services I use. Something that runs on Github, and can be forked by anyone, and made public or private. 

I'll update this as I add new ones. I know there are more servies I use, but it is hard to remember all of them.


Which Online Services Do I Depend On?

The first step in reclaiming my domain is understanding which online services I depend on. After the recent OpenSSL Heartbleed security episode, I am going through all of my accounts and changing my passwords. I’m using this opportunity to being using 1Password which has been on my list for a while now, after watching Audrey use it this year.

I already maintain a list of services that I depend on, as part of my own personal IT efforts, but this is a great occasion to pull them together, institute 1Password across the board, and pull together my Reclaim Your Domain strategy.

Currently I have a list of 52 services that I depend on:

  • 3Scale
  • about.me
  • Amazon Web Services (AWS)
  • Angellist
  • AT&T
  • Blogging
  • Boxcar
  • Crunchbase
  • Digg
  • Disqus
  • Dropbox
  • Drupal
  • Dwolla
  • DZone
  • EventBrite
  • Evernote
  • Facebook
  • Fast Company
  • Flickr
  • Foursquare
  • Geeklist
  • Github
  • Gliffy
  • GoDaddy
  • Google
  • Hacker News
  • Hover
  • IFTTT
  • Instaper
  • Klout
  • Lanyrd
  • LinkedIn
  • Meetup
  • Mega
  • Noun Project
  • Paypal
  • Pinboard
  • Plancast
  • Quora
  • Rainmaker
  • Reddit
  • Serve
  • SoundCloud
  • Square
  • Stack Overflow
  • StumbleUpon
  • TalkWalker
  • Thingiverse
  • Tumblr
  • Twitter
  • VectorStock
  • Yahoo
  • Zapier

I know there are more, and as I find them I put them on my master list, but this represents the core of what I depend on. I will use this list to guide me on my password change process, and as a roadmap to reclaiming my domain from each of these providers.

Next up I will need short list of questions to ask of each of these providers—I'll call this a reclaim profile.


API Evangelism Strategy: Blogging

I’m working with the Cashtie API to pull together an API evangelism strategy for the payments API. As I pull together, it seems like a great opportunity to share with you. Who knows, maybe you can use some of the elements in your own API strategy.

Next up is blogging, an area I feel is the single most important part of your API evangelism strategy:

  • Projects - Establishing of editorial assembly line of technical projects that can feed blog stories, how-tos, samples and code libraries.
  • Stories - Writing, editing and posting of stories derived from projects, with SEO and API area support by design.
  • Syndication - Syndication to Tumblr, Blogger and other relevant blogging sites that actually add value to readers, not being spammy.

This part of evangelism can be as involved as you like, being the work of a lone evangelist, or the work of a team of coders, writers, editors and community managers. The goal is to generate exhaust around your API, that will attract new developers to an API, as well as educate existing developers about the value an API delivers.

If you aren’t producing interesting projects around your API, and telling these stories far and wide, nobody will ever know your API exists, let alone put it to use.


PR People For APIs

I'm getting more PR folks reaching out to me trying to get me to review their client's API program. I'm happy to add these to my list and make time each week to review them alongside the other new APIs I find each week.

I'm not willing to jump on the phone and hear a pitch about the API. You should send me a short succinct email, or even better a Tweet with a URL and I'm happy to add to my list and make time when i can.

I'm not the usual blogger who just wants to regurgitate what you told me in a briefing or in a press release. Your API and its supporting area should do the talking. I should be able to click on a single link, understand what you do, and be able to find what I need within 5 minutes or less. If I can't? Well I will let you know.

Think of me as a developer. I will be reviewing your product from that perspective.

So if you are doing PR for an API company, make sure and read my blog, engage me on Twitter and save the briefings and emails for other bloggers. I'm more concerned with the value your client is bringing to the table, and their approach to delivering a self-service API platform.

No briefing required. :-)


On Losing My Storytelling Voice

photo credit

I'm totally thankful for the experiences I've had over the last 90 days in Washington D.C. as a Presidential Innovation Fellow, and even more thankful I'm able to keep doing much of the work I was doing during my fellowship. In reality, I'm actually doing more work now, than I was in DC.

While there were several challenges during my time as a PIF, the one that I regret the most, and is taking the longest to recover from, is losing my storytelling voice. This is my ability to capture everyday thoughts in real-time via my Evernote, sit down and form these thoughts into stories, and then share these stories publicly as the API Evangelist.

During my time in DC, I was steadily losing my voice. It wasn't some sort of government conspiracy. It is something that seems to happen to me in many institutional or corporate settings, amidst the busy schedule, back to back meetings and through a more hectic project schedule--eventually my voice begins to fade.

In July I wrote 61 blog posts, August 41 and September 21. A very scary trend for me. My blog is more than just just stories for my audience and page views generated. My blog(s) are about me working through ideas and preparing them for public consumption.

Without storytelling via my blog(s) I don't fully process ideas, think them through, flush them out and think about the API space with a critical eye. Without this lifecycle I don't evolve in my career, and maintain my perspective on the space.

In October I've written 28 posts and so far in November I've already written 27 posts, so I'm on the mend. In the future, I'm using my voice as a canary in the coal mine. If a project I'm working on is beginning to diminish my voice, I need to stop and take a look at things, and make sure I'm not heading in a negative direction.


API Evangelism

API Evangelism

An API is useless if nobody knows about it. Evangelism has emerged as the approach to selling, marketing and support an API platform. While the intent of evangelism can be sales and marketing, the philosophy that has proved successful is to find a balance that is more about focusing on API support and engagement with consumers over sales.

A healthy API evangelism strategy brings together a mix of business, marketing, sales and technology disciplines into a new approach to doing business.

Goals
Healthy API evangelism is centered around clear goals. Goals usually start with targets like new user registration, but need to be set higher around active API consumers, expanding how your existing users consume your API resources, all the way to clear definition of how your API will extend and expand your brand. 

Consumer Engagement
While it may seem obvious, actively engaging API consumers often gets lost in the shuffle. Have a strategic approach to reaching out to new users in a meaningful way, establishing healthy practices for reaching out to existing developers at various stages of integration, is essential to growing an API initiative. Without planned engagement of API consumers, a canyon will grow between API provider and API consumer, one that may never be able to be reversed.

Blogging
An active blog, with an RSS feed has the potential to be the face of an API and developer evangelism campaign. A blog will be the channel you tell the stories that help consumers understand the value that an API delivers, how other developers are integrating with it, ultimately leaving an SEO exhaust that will bring in new consumers. If comments are in place, a blog can also provide another channel for opening up conversation with API consumers and the public. 

Landscape
Without an understanding of the industry an API is operating in, an API will not effectively serve any business sector. By establishing and maintaining a relevant keyword list, you can monitor competitors, companies that compliment your platform, and establish an active understanding of the business sector you are trying to serve. Regular monitoring and analysis of the business landscape is necessary to tailor a meaningful API evangelism campaign. 

Support
When it comes to evangelism, support is one of the most critical elements. There is no better word of mouth for an API, than an existing consumer talking about how good the API is, and the support. Engage and support all API consumers. This will drive other vital parts of API evangelism, including creating positive stories for the blog, healthy conversations on social networks and potentially creating evangelists within a community.

GitHub 
I recommend a lot of online services and tools for API providers and consumers to put to use. But there is not any single platform that delivers as much value to the API space as Github. I would put AWS as close second, but Github provides a wealth of resources you can tap when both providing APIs or building applications around them.  Github is a critical piece of any API strategy, allowing social relationships with developers that is centered around code samples, libraries or even documentation and resources for an API.

Social Networking
Twitter, Facebook, LinkedIn, Google+ and Github are essential to all API evangelism strategies. If an API does not have a presence on these platforms, it will miss out on a large segment of potential API consumers. Depending on the business sector an API is targeting, the preferred social network will vary. Providing an active, engaging social support presence when operating an API is vital to any API ecosystem. 

Social Bookmarking
Discovery and curation of bookmarks to relevant news and information via social bookmarking platforms is essential to an active API evangelism strategy. Using Reddit, Hacker News and StumbleUpon will provide discovery and access to a wealth of resources for understanding the API space, but also provide an excellent channel for broadcasting blog posts, news and other resources about API operations, keeping consumers informed, while also opening up other opportunities for discovery. 

Road-map
API providers, and API consumers are constantly building trust and establishing a long term relationship with each other. One key facet of this trust, and the foundation for the relationship is sharing a common road-map. API providers need to actively involve API consumers with where the API resources are going, so that consumers can prepare, adjust and even give feedback that may, or may not, influence the road-map. Nothing will piss off API consumers faster than keeping them in the dark about what is coming down the pipes, and surprising them with changes or breaks in their applications. 

Events
A healthy online presence is critical to any successful API strategy, but giving attention to a strong in-person presence at events is also a proven tactic of successful API providers. Evangelism involves a coordinated presence at relevant conferences, hackathons and local meetups. Events are necessary for building personal relationships with partners and API consumers that can be re-enforced online.

Reporting
Measuring every aspect of an API operations is necessary to understand what is happening in any API operations. Reporting on every aspect of API operations is how you visualize and make sense of some often, very fast moving API activity. It is important to quantify API operations, and develop reports that are crafted to inform key stakeholders about an API initiative.  

Internal
External facing activities will dominate any active API operations. However, an essential aspect of sustainable API programs is internal evangelism. Making sure co-workers across all departments are aware and intimate with API operations, while also informing management, leadership and budget decision makers is critical to keeping API doors open, healthy and active. 

Repeat
API and developer evangelism is an iterative cycle. Successful API operations will measure, assess and plan for the road-map in an ongoing fashion, often repeating on a weekly and monthly basis to keep cycles small, reducing the potential for friction in operations and minimizing failures when they happen.

A healthy API evangelism strategy will be something that is owned partially by all departments in a company. IT was a silo, APIs are about interoperability internally and externally.


Netflix Storytelling And Why You Should Tell Stories of Your Platform

The mission of API Evangelist is centered around telling stories from the API space, shedding light on the innovative things developers and API providers are doing across all business sectors.

Over the holidays I rolled my history of APIs series into its own section. It can be very difficult to understand who the players were in the API game, last year, let alone 10 years ago. If there aren’t stories about what happened in 2001, it can be very difficult to piece together the history.

In 2012 I also scaled up my API monitoring system to track the blogs and tweets of over 1000 APIs, providing a way for me to track activity across the space and establish my own API ranking system resulting in what I cal the API Stack. This too is very dependent on API owners telling or sharing stories around their operations.

I’m tracking on over 1500 APIs and only 1000 have blogs and Twitter accounts. With very few other signals to follow, such as stories in the blogosophere, social bookmarks on Hacker News and Reddit or QA on Quora or Stack Overflow--there isn’t much to discover about these potentially valuable APIs.

At first, I felt there was a flaw in the way I track on APIs. If an API offers value, but there are no stories for me to track on, it won’t show up on my radar--leaving me feeling my approach could be flawed.

On the flip side, going into 2013 I am eager to find “new” stories of APIs, feeling like I’m constantly telling stories of Amazon and Netflix--contrasting this with the lack of stories around 500 of my APIs, I felt there is an important link. There is a reason I tell so many stories about Netflix isn't chance, it is because Netflix shares so much about its operations, providing fuel for my analysis and storytelling.

To shed light on this, I sat down with Daniel Jacobson (@daniel_jacobson), Director of Engineering for APIs at Netflix and asked him, “Why does Netflix share so many stories about their operations?”

It is very similar to why I tell stories on API Evangelist.  Daniel asys it can be very positive to think about things, anticipating that you will share publicly, forcing you to see things in a different light. That process can be very healthy, even without considering the after-effects of publicly sharing.

Ultimately Netflix shares its stories publicly to set itself as a thought leader, providing a marketing vehicle for the company when stories get picked up by TechCrunch or Mashable, but also sending signals to the world that Netflix is innovating and is a great place to work--additionally providing a valuable talent acquisition engine in a time when competition for talent is high. Look at posts from Daniel, on sites like ProgrammableWeb. What do you see in the last sentence...”we are hiring!”

Next I asked Daniel how, or if they measure and reported on the return on investment (ROI) from their public storytelling--number of hires, pageviews, syndication, etc. He providing me with another link to talent acquisition--that ultimately they don’t track on this, its based upon the response they get publicly and the feeling in their gut after each story is released into the wild.

Daniel related this approach to strorytelling with their internal culture of freedom and responsibility. When you work at Netflix, there is NOT a lot of management and control, the culture is centered around good judgement, communication, impact, curiosity, innovation, courage, passion, honesty and selflessness. In my opinion all qualities that can lead to good storytelling.

The Netflix storytelling process isn’t a PR stunt. Its truly about a genuine desire to share the story of their operations, the successes and failures--demonstrating their expertise and thought leadership not just in the movie and TV industry, but across the technology sector.

API Evangelist is my learning and storytelling platform. It is rooted in my learning in real-time, and my desire to share these thoughts, in hopes others can learn along with me. I’m not seeking pageviews, I just want to share my view of the space, showcase the good and bad across all sectors, helping lead, in hopes that I can contribute to making the space as healthy as possible.

As an API provider, your blog, social networks, QA and forum activity is not just a PR mouthpiece. It is how you will tell the stories around your platform, how you will share the value you deliver--educating users, developers and the public at large that you exist, and that what you are doing matters.

Without stories, your platform won’t matter now or in the future--no matter how amazing your technology is.


Top Technology Blogs Lose 50 Percent of Readers Due to Innacurate Reporting

For about six years now, technology blogs like TechCrunch ad Mashable have been the go-to-place, to find the most up to date information that comes out of Silicon Valley and the technology world.

After many high profile acqusitions of these tech blogs, and the daily pressures of "churnalism", these tech blogs have become the go to place to get information that doesn't exist.

After reading the story of one of the few journalists in the space, Caleb Garling (@CalebGarling), Analytics firm AppData pollutes web with sketchy Instagram info:

A couple weeks after a concentrated uproar over Instagram’s privacy policies — which were largely pointless anyway — analytics outfit AppData has told the New York Post that its data shows users are fleeing the service because of the terms of service announcement. The company’s data showed that Instagram peaked at 16.4 million active daily users the week it rolled out its policy change had now plummeted to 12.4 million as of Thursday.

I went to dig up my own numbers. According to ChurnData Systems LLC (link unavailble), the leading providing of fictitous numbers for Silicon Valley, Techcrunch, ReadWrite, Mashable and others have lost 50% of their readership due to lack of actual journalism, ethics, while also consistently reporting on meaningless or completely made up stories.

While I stopped following any of the mainstream blogs in 2011, it looks like the mainstream is waking up to the fact that you shouldn't get your tech news from these sources.


Thirty APIs To Look At When Planning Your API

When planning an API, I always tell people to go look at as many of the top APIs as they can before crafting their own API strategy. I'm always surprised how many API owners I talk to don't actually use other APIs. They can usually reference the main ones like Twitter and Facebook, or the usual rockstar Twilio--but very few can cite 10 or more APIs they like.

Recently I spent some time looking through all of ProgrammableWeb's APIs, and I made a list of the 30 APIs I like, and would reference when designing an API strategy. Since I'm more about the Business of APIs and not just the finer, technical points, these I feel are unique because of their business approach to delivering their API.

Here are 30 of the best APIs I think you should look at when planning your own API strategy:

Amazon Web Services - Cloud Computing
Bitly - URL Shortening
Box.net - Cloud Storage
Compete - Web Analytics
Constant Contact - Small Business Marketing
Datasift - Data Marketpalce
Disqus - Comments and Discussions
Dwolla - Payments
Ebay - Products and Online Auctions
Etsy - Handmade Marketplace
EventBrite - Event Management
EverNote - Memory and Notetaking
Factual - Data Marketplace
Flickr - Images
Foursquare - Locations and Check-Ins
Full Contact - Contact Intelligence
Google Maps - Mapping
Google+ - Social Network
Instagram - Photos
LinkedIn - Business Social Network
RapLeaf - Email Contact Intelligence
Salesforce - CRM and Sales
SendGrid - Email
Stripe - Payments
The EchoNest - Music
Twilio - VoIP and SMS
Twitter - Micro Blogging
Wolfram Alpha - Computational Knowledge Engine
Xero - Accounting
Zappos - Shoes and Clothing

Not all of these APIs do it perfectly, but each of them have something we can learn from when planning, deploying and managing our own APIs.  All of these APIs have an active presence, so I recommend reaching out to them and ask questions about what made them successful or follow their blog and Twitter accounts.

If there is an API you feeling strong about that is not on this list, please let me know.  Or if you feel one of these APIs doesn't do something right, either technical or otherwise, also let me know as well (except if its Twitter).  


Keep Your API Area Active So Developers Feel Like Someone Is Home

The largest portion of my time as API Evangelist is spent keeping the area around an API active. Your developer’s first impression when they enter your API area is critical, and if they see signs that your API is inactive, they might start looking elsewhere.

The most common ways I keep an API active is by:

  • Blogging
  • Tweeting w/ Twitter Feature in API Area
  • Forum Posts
  • How-Tos
  • Starter Projects
  • Developer Showcase

By actively posting content in these areas w/ timestamps showing when they were posted, I keep the API area looking like someone is home.

This active content doesn’t just help developers visiting the site feel like the API is active, it also helps your SEO. Search engines and social networks will regularly index your content, providing fresh traffic, and potentially new developers to your API.

Just a couple hours a day, generating fresh content and engaging with your developers goes a long ways in attracting new developers and making them feel confident that your API is a priority, and they should integrate it into their applications.


Is The Blog for Your API Up to Date?

As a building block, a blog is a very valuable tool for building awareness of your API, keeping your developers informed and give a personality to the team beyond an API.

My recommendation to API owners is to always have a blog, however one the most damaging things you can do is stop posting to your blog. A blog is a key variable in my API Stack algorithm, of whether or not an API is worth integrating with, and if you haven’t updated your blog anytime in the last year, I immediately step away.

If you want people to find your API, have a blog. If you want your existing developers to be educated about what can be done with your API, have blog. If you want developers who find your API, to feel confident enough to integrate it into their app, keep you blog updated!


Turning API Forum Posts into Blog Stories

I’m always looking for new, relevant ideas to write blog posts on for the CityGrid Developer blog. I have several topics I write about regularly including new projects I’m working on, new releases around the API, and what I find during my local, mobile and social landscape analysis.

However it can be hard to find topics to write about that are relevant to CityGrid developers, or publishers as we call them. To help write blog posts that are useful to my API community I started harvesting ideas and topics from actual forum posts from developers.

Earlier today a publisher submitted a forum post stating their concerns about the age of some of the reviews they get along with businesses, when making requests against the CityGrid Places API. It was an easy question to answer, since CityGrid also provides a business reviews API, that will give you more control how you can pull reviews for a zip code, neighborhood or specific business.

Using the topic that was posted on the forum I was easily able to create a quick blog post framing the question and providing a detailed answer explaining how the CityGrid Reviews API provides a solution.

Now CityGrid publishers can potentially be exposed to this solution via the blog, RSS feed and since I actively syndicate my blog posts, they will see it if they follow CityGrid on Twitter, LinkedIn, Facebook and also using a search engine.

When evangelizing for an API, I feel it is important to try and provide as helpful content as you can via an active blog presence, while also reverberating it across the multitude of channels your developers might be listening on--turning relevant forum posts into stories is a great way to do this.


Tumblr Releases API v2

Tumblr just released version 2.0 of the popular blogging platform API, in an effort to make developers lives a little easier when integrating with the Tumblr platform.

The previous version of the API made distinctions between read and write operations and pushed different activity to two separate domains, the www.tumblr.com and the blog subdomain.

The new API version consolidates all API access to api.tumblr.com and exposes two major resources in the URI: /blog and /user. Consolidation under one domain will allow Tumblr to effectively measure and balance traffic using DNS.

The new URLs will follow a pattern, making them intuitive, allowing developers to easily discover and experiment with the API without having to rely exclusively on documentation.

Instead of adhering to strict RESTful practices, Tumblr is looking to create simple URLs that enable manipulation by the average human.

For example, to pull the avatar of my tumblr blog I use the following URL: http://api.tumblr.com/v2/blog/kinlane.tumblr.com/avatar

The API returns the default avatar image, and if I want a larger size, I just append the size to the URL: http://api.tumblr.com/v2/blog/kinlane.tumblr.com/avatar/512

In the first version of the Tumblr API, all data was available in XML, with JSON support added largely as an afterthought. Now Tumblr has just decide to eliminate XML, and focused on dialing in their JSON implementation. A common approach for API owners.

The new API implements OAuth 1.0a for authentication and they are looking at upgrading to OAuth 2.0 in the neear future.

I like how Tumblr has consolidated under a single domain, and I favor their approach to intuitive URL's over a strict RESTful implemntation.

The Tumblr API v2 is definitely an improvement, I will see how it sizes up against the new Posterous API launched last month.

Mashape Provides Tools to Distribute, Discover and Hack APIs

I'm exploring the Mashape API Platform, trying to break things down and understand everything in more detail. Blogging about a topic does this for me.

So let's start with deploying an API with Mashape.

With the Mashape PHP Library you can deploy an API on your infrastructure. You download the library from Github, deploy on your server, and then add the methods for your API by extending the Mashape PHP component class.

If you already have an API that returns JSON responses, you can just register it as a Mashape API for distribution, without deploying the Mashape PHP Library.

If you've deployed your API without the Mashape PHP Library you will need to accomplish one more step. You will need to implement the Mashape Connector by adding one line of code to your API, which is required to connect your API to the Mashape Platform and handle user authorization, billing, and rate-llimiting.

Whichever way you deploy your API, you can now distribute it using Mashape. The first step for distributing an API is to create an XML file that describes what the API does. This XML file gets deployed on your server and needs to be updated as your API evolves.

Once your API is deployed and published to Mashape, the platform distributes your API to the Mashape Marketplace and provides a detail page with title, description, documentation, test console and PHP, Python, Ruby, Java and Objective C client libraries.

Mashape then provides a way for developers to sign-up and start hacking on any API in the Mashape Marketplace with a single developer account and key. There are also social features allowing users to follow and contact other users.

All APIs that are published using Mashape will connect and communicate with Mashape through an API Proxy. This is the proxy that handles the authorization of users, implementation of billing, rate limiting and other functions described above.

Right now the proxy is primarily available via the Mashape platform, but you can also find an open-source version of the Mashape API proxy on Github. The API Proxy is intended to be downloaded and installed on your servers, which will increase the performance and security of your API.

In addition to being able to register your API and use the Mashape API Proxy in the cloud, you can download and install on-premise. Since it is open-source, you could also fork the code and potentially add in your own modifications to the API proxy, which is written in JavaScript and runs on the latest version of node.js

I'm playing around with deploying one small and one large data-set as two separate APIs using the Mashape PHP Library, so I can get more familiar with how the platform works. I just wanted to work through some thoughts about what they provide here on the blog. More to come on Mashape...

Posterous, From SaaS to PaaS Using an API

In a single announcement yesterday, the blogging service Posterous went from Software as a Service (SaaS) to Platform as a Service (PaaS), with the introduction of a full set of APIs.

The new set of RESTful APIs give developers access to methods and actions that were formerly available only to the core Posterous engineering team including the ability to create new sites, manage users, posts, comments, custom themes and other data for those sites.

Beyond just exposing the core posterous technology via as a simple set of RESTful APIs, Posterous has delivered their API documentation as an interactive set of tools allowing developers to see every available method, interface with these methods and experiment bydynamicallychanging the paramaters and inspecting responses, all within the browser.

Posterous has merged the concept of API documentation and API explorer into a single set of interactive developer documentation. This steps up the game, in that not only should your documentation be simple and complete, but also functional.

The new Posterous APIs have evolved Posterous from a service where users can come and setup blogs, to a platform that companies can use as a backbone for their own blog and site managment systems.

If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.