{"API Communications"}

Stories Are The Best Way To Keep The Door Open

The world is built on stories. People enjoy telling and hearing stories. Stories are the lifeblood of what I do as the API Evangelist and are the number one way I stay in touch with people across many different industries and around the globe. As a single person shop there is only so many calls I can conduct in any single day, and there are only so many folks I can ping on a regular basis to stay in touch--I rely on the power of stories to do the hard work for me, acting as the distributed glue in my world.

When I connect with someone new via Twitter, email, or in person, I always close up the conversation with, "if you ever have any good stories for me to tell, either anonymously, or directly, make sure and reach out". I do need the stories, but my primary objective in doing this is to keep the communication channels open and encourage folks to do the heavy lifting when it comes to remembering to reaching out to me and renew the connection between us. The urge to share (and be heard) or hear a good story is always much stronger than the desire to buy or sell a product (aka sales lead), making this approach produce the return on investment (ROI) I am looking for.

I see my approach in contrast to the urge to tip of major tech blogs about a product release or investment because it often isn't about the tech--it almost always is about the humans. Companies want to talk to Techcrunch when a product, feature, investment, or press releases, and people contact me when something good or bad has happened involving the humans. Sure, I still get the regular release engagement, but it is the stories that truly matter to me, and to my readers. Storytelling is the way I reach a large audience on a regular basis, and the way that a global group of people stay engagement with me, even when the migrate companies, organizations, institutions, and government agencies--stories are everything, and always the best way to keep the door open.

See The Full Blog Post


The Three Layers Of API Hype

I read a lot of content about APIs. I read a lot of redundant and fluffy marketing and technical jargon, trying to understand exactly what an API does, or doesn't do. Before I criticize, I have to admit that crafting really good API marketing and documentation is hard. Only about 5% of what I read is good, a significant portion is just incomplete and lazily done by someone who doesn't care--the rest is actually incorrect, misleading, and straight up hype.

There are three layers to the API hype onion in my experience:

  • Marketing - The fluff on the main page written by the marketing team who usually doesn't care about the API and has taken the time to get to know what it does.
  • Documentation - The technical fluff in the API portal usually written by someone technical, and not quite possessing the skills to talk to humans, let alone coherently explain something to another human being.
  • API - The actual naming, ordering, parameters, and overall request and response structure for an API that actually accomplishes something--it may not always accomplish exactly what I'm looking for, but at least it is.

While I still read marketing and documentation, because they provide me with clues about the intent behind API operations, when I actually want the honest take of what an API does, I always go straight to the API and get to work making API calls. This is a problem that is only increasing as we enter into the artificial intelligence and machine learning hype phase.

After you finish writing the marketing, documentation, and have your API up and running--step back, and re-read everything, and think about the synchronicity between these three areas of your operations. It takes a lot of practice and hard work to do right, but I think if you just take a moment, step back, and think about these layers to how you articulate what your APIs does--you will immediately find yourself in a better position to communicate what it is you are trying to accomplish to a much wider audience.

See The Full Blog Post


There Is More To This Than Just Having An API

There is a reason why I encourage API providers to look at not just the technology of APIs but also invest heavily into the business and politics of API operations. There is a reason I evangelize a more open, web-based approach to doing APIs, even if you are peddling hardware and device APIs. It is because there are a number of human-centered elements present when doing APIs, that will define your services, and ultimately contribute to whether or not they are a success or a failure.

One example of this from my API news curation archives is from the Sonos API ecosystem, and a pretty big blunder in communication the audio device platform made late last year, that is significantly impacting their partnerships in 2017.  Directly from the CEPro article:

A collective cheer roared from home-technology installers at CEDIA Expo 2016, when Sonos announced an API for home-automation integration starting with Control4 (Nasdaq: CTRL), CrestroniPortLutron and Savant.

These partners – and most other respectable smart-home systems providers – have integrated with Sonos for many years, albeit with unsanctioned drivers created through reverse-engineering of a fairly straightforward UPnP-based protocol.

But the new API kind of snuck up on dealers and vendors alike, with their customers waking up to a brand new Sonos experience in late December, courtesy of an auto-update by Sonos.

The new experience was inferior to the original, with users unable to access Spotify or Amazon Music from the home automation system, except to select favorites created through Sonos’s own app.

When you are operating an API that many different businesses depend on, communication is essential. this is why I advocate that API providers always have a clear communication and support strategy, as well as the road map, issue management, and change log processes. Every single change has to be considered for its impact on the community, and you have to have a plan for how you will be communicating and supporting your API consumers needs around a change. 

This is also why API providers should be understanding the benefits of hypermedia when it comes to change management. Hypermedia design patterns provide you with a more honest approach to dealing change, one that helps make your partner's clients more fault tolerant. It is well worth the time learning about the handful of leading hypermedia media types. Any one of them would have helped Sonos manage change.

There are multiple tools in the API toolbox to help you manage change. In the en,d the most effective tools involve human to human interaction, and actually talking to your partners early on about change, and making sure you have a robust communication strategy throughout your API lifecycle. Us engineers like to think it is the API technology making the magic happen, but in the end, there is more to this than just having application programming interfaces, it is about also having the right human interfaces.

See The Full Blog Post


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.

See The Full Blog Post


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.

See The Full Blog Post


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.

See The Full Blog Post


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.

See The Full Blog Post


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.

See The Full Blog Post


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. :-)

See The Full Blog Post


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.

See The Full Blog Post


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.

See The Full Blog Post


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.

See The Full Blog Post


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.

See The Full Blog Post


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).  

See The Full Blog Post


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.

See The Full Blog Post


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!

See The Full Blog Post


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.

See The Full Blog Post


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.

See The Full Blog Post


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...

See The Full Blog Post


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.

See The Full Blog Post