The API Evangelist Blog - 2016

This blog is dedicated to understanding the world of APIs and exploring the technology, business, and politics of APIs.


Pandora vs Target When Considering How Public To Be With Your API Operations

16 November 2016
I am reworking the API Evangelist developer area, and shifting most of my content to be available as YAML and JSON data on the Github repositories that drive my network of sites. I'm doing this partly because I am not in the business of managing and growing an API community, and because there are some really badly behaved people out there that I'm just not really interested in having keys to my internal network. I am happy to open up read only access to my work publicly and write capabilities to my trusted partners, but having self-service access to my server(s) just isn't fun in the current online climate.  I get it when folks want to keep their valuable data, content, and algorithm under lock and key, and require developers to build a relationship before they get access or increased levels of consumption...

Focusing On A Single Example Of What An API Is When On-Boarding Folks

16 November 2016
Talking to people, and telling stories on a regular basis always pushes me to evolve my understanding of how people see (or don't see) APIs, and pushes me to keep shifting the way I tell stories. I've always felt that that education about APIs should be relevant to the users, but usually this centers around making it familiar, and speak to whoever I am helping onboard. After talking to some folks recently at @APIStrat, I'm adding to my thinking on this, and focusing on making my stories more precise for folks I talk with. One of the reasons I really like APIs is that they are so versatile. You can take and a piece of data, content, or an algorithm (code), and wrap with an API, and provide read and write access via the Internet...

The Taiwanese Government Posts An APIs.json Index

14 November 2016
My friend and partner in crime Nicolas Grenié (@picsoung), and operator of our open source API search engine APIs.io, just let me know that the Taiwanese government just added an APIs.json file for their government open data site. Adding to the other authoritative (added by owner) government API indexes like from Trade.gov in the United States. We haven't' had a lot of time to move forward the APIs.json index lately, but honestly it doesn't need much pushing forward at this point in time. Our primary objective is to continue getting adoption like this, and not radically shift the specification until we have more feedback from the community, across a large number of API operators...

Daisy Chaining Multiple API Paths Using Stoplight Scenarios

14 November 2016
There aren't too many startups doing interesting things in the API space right now. One of the exceptions is Stoplight.io. I am working really hard to find some of the good things in the API space to focus on, in hopes of not being too dark with my writing, after the election. Stoplight's new Scenarios is something new, something progressive, and I think could have a larger impact down the road--making it worth covering here on API Evangelist. Stoplight Scenarios is billed as "Test, automate, and debug web APIs + AWS Lambda". You can make API and AWS Lambda calls, and test, automate, and debug the responses -- pretty standard stuff we are seeing across several API service providers. Where it gets interesting for me is that you can daisy chain these requests together into a variety of scenarios...

The API Evangelist Mission Continues

14 November 2016
I tried to get back to normal last week on API Evangelist -- I failed. The previous week was @APIStrat in Boston, which was a success. It was the Presidential election that caused me to swerve and put things into the ditch. I was devastated and saddened by the results. Not because my party lost, but because we chose someone who ran on such a racially, and religiously charged platform, that was so threatening to women.  It is easy to mistake what I do as the API Evangelist, as being a voice for the startup community -- cheerleading APIs in the service of the seemingly endless wave of tech companies coming out of Silicon Valley. While I do pay attention to the technology, and business of how these companies are using APIs, making sure the content, data, and algorithms they employ are transparent and observable by partners, 3rd party developers, end-users, and industry regulators is my primary objective...

How Do You Work Towards A More Diverse Inclusive Tech Conference?

10 November 2016
The 7th edition of API Strategy & Practice Conference happened last week. While I wasn't fully engaged throughout the planning process for this edition, due to my summer being disrupted, I wanted to take the time to share some of what happened to make it more of an inclusive technology event. There is a lot of people who are "interested" in making their events more diverse and inclusive, but APIStrat is "committed" to this (thanks, Charles Ashley III @CAsh_The3rd), and here are some of what we did. Strong Female Lead - Put a woman in charge. Period. She will set a good tone. Invite Women To Speak - Work to ONLY invite women when getting started. Invite People of Color To Speak - Work to ONLY invite people of color when getting started...

Maintaining The API Community At Scale #APIStrat

10 November 2016
The 7th edition of API Strategy & Practice wrapped up last week. It has been difficult to gather my thoughts with the election going on, but I wanted to shift my attention back to the API community for a bit. Steve Willmott and I started APIStrat back in 2012 to help establish an open, vendor-neutral community to discuss the technology, business, and politics of APIs -- we more than succeeded! It always warms my heart when people come up to me and share that they didn't see anything different about APIStrat, from other events before they attended and that they do now. Steve and I worked our asses off to make it a rich, inclusive, and meaningful conversation around APIs. It makes me very happy to hear people seeing the event as we intended, and going home with a headful of API knowledge...

Drone Recovery In The Attention Economy

04 November 2016
Difficult To Keep My AttentionWhen I was young I was always curious when it came to technology. I set up the entire computer lab for my 7th-grade math teacher back in 1983. I programmed computers all through high school, even having a job programming the software used by schools in the State of Oregon in COBOL. I was really good at school until I wasn't interested. If I got bored, which I did growing up in rural Oregon, I tended not to pay attention in school. Eventually, it got kicked out of high school in my senior year, and I ended up getting into drugs, and a lot of trouble. From 1990 through 1995 I spent my time traveling the country partying and dealing drugs until I finally hit a wall and needed a way out...

We Will Need Machine Readable Transparency Report Info Via APIs

28 October 2016
I was reading the latest Yahoo transparency report, as well as the Tumblr. When a company releases their latest version of this data, it tends to prompt me to take a look at some of the other providers who have them, like Google and Twitter. I am interested in what I can learn from these reports, about what the government is up to, as well as the incentives behind each platform publishing their reports. I fascinated by studying the process and approach of each company, tracking on what some of the common building blocks so that I can include in my API transparency research. The addition of CSV downloads of information requests by Twitter is worth noting, and adding to my list of building blocks...

A Drone Law API For Use In Planning And At Flight Time

28 October 2016
  Photo: Drones and Society I went down to the police department in Hermosa Beach and filed my application for a drone permit. It's been two weeks and I haven't heard back. When I get done with @APIStrat I will go down there and talk to them again, and probably have to resubmit my application. Hermosa Beach is purported to have some of the strictest laws. I'm submitting mine so I can just play with my drone, and program it on the beach without getting into trouble.  Before I fly my drone I use the B4UFLY mobile app from the Federal Aviation Administration to know whether I should fly my drone or not. It tells me whether I'm near an airport, military base, other location or event...

Internet Connectivity And Data Transfer Control For IoT Devices On The Network

28 October 2016

Tooling To Help Aggregate DNS Across Multiple Service Providers

27 October 2016
Adrian Cockroft (@adrianco) turned me on to a DNS aggregation solution the other day while I was working on updating the API definitions for the API providers that are included in my API DS research. It was a very appropriate day for thinking deeply about aggregate DNS, with the DDOS attack against Dyn going on. DNS provider redundancy: the idea behind @denominatorOSS - one API/tool for many providers to allow switching. /cc @adrianfcole — adrian cockcroft (@adrianco) October 21, 2016 Denominator is a portable Java library for manipulating DNS clouds. It has pluggable backends, including AWS Route53, Neustar Ultra, DynECT, Rackspace Cloud DNS, and OpenStack Designate. Here is a good post on it from back in 2013, describing it as a multi-vendor interface for DNS...

Allowing For Relationships Between API Developers At The App Level

27 October 2016
Managing developers access to an API is API management 101. Managing the relationships between developers, and allowing for multiple users associated with an API application isn't something I have seen before. Slack just added the ability to add what they call app collaborators--"adding any existing member of your Slack team as a Collaborator, including members and Guest Accounts." The functionality felt a lot like the social aspects that made Github more attractive than just Git. When it comes to developing messaging apps and bots I can see a social layer doing pretty well. "Once a Collaborator is added, they’ll receive a notification from Slackbot letting them know they now have access to your app...

Why upgrade to a paid plan?

27 October 2016
I thought the microservices platform Nanoscale.io have an interesting argument for why you would upgrade to a paid plan. On their pricing page, after they break down each of the pricing plans they provide you with four reasons of why you would want to upgrade from their free tier. More powerful APIs - Your nanoscale.io hosted microservices can run longer and perform more complex operations, or access slower source systems, without timing out. Get premium support - Having a problem with nanoscale.io? Think you may have found a bug? Submit your inquiry and get a guaranteed response from our technical team. Influence product roadmap - We are open to new feature consideration, and give preference to paid accounts to influence which ones get built sooner...

Transparent Data Transfer Control APIs At The IoT Device Level

26 October 2016
I am diving deep into the DJi drone developer platform, and one of the elements of the DJi Drone Guidance API that caught my attention was the data transfer control methods. In this situation, the transfer control methods are designed for just the data being sent as part of the drone guidance systems, but I think it provides a blueprint that can be used across almost any IoT device connectivity. DJI provides four methods for managing the drone data transfer control: Start Transfer - Inform guidance to start data transfer. Stop Transfer - Inform guidance to stop data transfer. Release Transfer - Release the data transfer thread. Wait For Board Ready - Set callback function handler for hen data from guidance comes, it will be called by data transfer thread...

APIs Helping Drones Generate Alpha Used In High Frequency Trading

26 October 2016
One of the things I love about my world as the API Evangelist is the time I get diving into rabbit holes and learning about different areas where technology is being applied. I do not always agree with the business motivations behind what is going on, which can result in some often pretty shady situations, but I enjoy stepping back and understanding the data, API and approaches behind what is going on. I was doing some research on drone APIs recently, and as I was falling down the rabbit hole, I found myself reading about drones being a source of alpha? WTF is alpha? I had no idea and wanted to learn more about what an alpha generation platform was, and how drones and APIs are playing a role--here is the definition I found: An alpha generation platform is a technology solution used in algorithmic trading to develop quantitative financial models, or trading strategies, that generate consistent alpha, or absolute returns...

Learning The Dimensions Of The DJI Drone SDKs And APIs

26 October 2016
I am going through the DJi DJI drone developer area which has three distinct SDKs, which allow us to leverage a variety of APIs that make the drone magic happen. I'm still wrapping my head around the intersection of drones and APIs, and this is my attempt to distil down what I'm finding in their developer area, and absorb some of what is going across the industry. This is not  meant to be a complete list. It is meant for my learning, and hopefully yours along the way. There are a variety of devices being connected to the Internet, but other than the automobile I don't think there is another object that is as complex as the drone. I'm fascinated by what is possible with this device, and the variety of APIs it has, the interaction with the RC controller, mobile device, and with other resources the clouds...

Asynchonous Conversational Interfaces For Us Anti Social Folks

26 October 2016
I get why people are interested in voice-enabled solutions like Alexa and Siri. I'm personally not a fan of speaking to get what I want, but I get the attraction for others. Similarly, I get why people are interested in bot enabled solutions like Facebook and Slack are bringing to the table, but I'm personally not a fan of the human-led noise in both of these channels, let alone automating this mayhem with bots. In short, I'm not 100% on board that voice and bots will be as revolutionary as promised. I do think they will have a significant impact and are worthy of paying attention to, but when it comes to API driven conversational interfaces, I'm putting my money on push driven approaches to making API magic happen...

Potential For APIs To Target Us Online By Adding More Context

26 October 2016
Many folks see me simply as a cheerleader for APIs when in reality I am more of an evangelist for the bad that can happen with APIs. I believe that sharing of data, content, and algorithms using web APIs has the potential for good, but in reality, they are often be used for doing some pretty shady shit.  An example of this is found in my inbox this morning, and I'm sure is something everyone will encounter at some point in their daily lives. It is an email for an undelivered Fedex package, which I know better than to click on, but sadly I think it is one that many folks will fall for. Why do they fall for this? Because the email potentially has relevance, as I just ordered a handful of packages from Amazon, which were being shipped via Fedex (I do not order much online)...

API Technology Does Not Have To Mindlessly March Forward

25 October 2016
I am seeing more people asking that we put on the brakes when it comes to technology, looking to slow the adoption of new technology, in favor of mastery of the existing, and getting our house in order with the technology we already in play. One of the core tenets of my message as the API Evangelist centers on the importance of doing what we are already doing and doing it better. You can see this message present in my 2014 recommendation on an API strategy for the US federal government--do more of what is already in motion, don't disrupt by just doing the new. I have seen a lot of API technology float by in the last six years of doing API Evangelist. I can still get excited by some of it, but far less than I did in 2010 when I first started...

Adding New Dimension By Including Patents In My DNS API Research

25 October 2016
I have been tracking on API related patents for some time. I regularly pull XML dumps from the US Patent Office, a process in which I am getting more refined, so that I am able to easily tag, and organize them alongside the rest of my research. I spent some time this last week diving into my DNS API research, and after updating the rest of the data behind, I added some DNS related patents. The patent information is already available in my API monitoring system, I just needed to be able to tag the patents, and write a script to publish the tagged patents to each of my Github projects. Now that I have this in place, it is pretty easy for me to spend an hour or two looking through the patents that come each week, and putting them into each area of the API space I study--which is why I have organized my API research the way that I have...

With Mobile We Are The Product -- With IoT Lets Get A Piece Of The Action

25 October 2016
Internet-connected devices generate data. The most recent wave of mobile devices has opened up an unprecedented world of data generation and harvesting from the network, device, and application layers. The location data, photos, videos, and other valuable exhaust from these devices is why there has been so much investment in technology, and why we are seeing continued investment in the Internet of Things (IoT). When it came to mobile phones this opportunity was new, and it isn't always clear that we are the product when it comes to making money off connecting these devices to the Internet. People aren't always aware of how much data they are generating, and how much this data is generating revenue for the latest generation of entrepreneurs--because it's new...

Thinking About An API Observability Stack

25 October 2016
I am learning about observability from reading Stripes post on Veneur, a high performance and global aggregation for Datadog. While the math of it all is over my head, the definition makes a lot of sense and provides me with a nice Venn diagram overlap across several areas of my API research, including testing, monitoring, logging, analysis, and visualization. The Wikipedia definition for observability is: Formally, a system is said to be observable if, for any possible sequence of state and control vectors, the current state can be determined in finite time using only the outputs (this definition is slanted towards the state space representation). Less formally, this means that from the system's outputs it is possible to determine the behavior of the entire system...

Looking At The Latest API Related Certification Stories

25 October 2016
As I curate the interesting news from across the API space each week I tag things to put them into different buckets. At the end of each week, I look through each bucket, deciding which area(s) I will be writing about each week. I am always trying to identify patterns and evolve the different areas of my research. One of the areas I'm considering adding as a formal area of API research is when it comes to certification.  I have been seeing the area come up quite a bit, making me think it is something I should be thinking more about, and researching as its own project. This week there were four items thought caught my attention: BigML Certifications are Here! - Professional certification on machine learning APIs, from a leading API provider...

Preserving The Twitter API Field Guide

24 October 2016
I'm a fan of the human elements of this technological shift that is going on in our world. We tend to focus on the technology, and the dudes who do the technologies (the cyber is HUGE), but what will really matter in 50 or 100 years will be the more human aspects of how we did all of this. Trust me, it is hard to make this boring ass API shit human in any way, so I am always excited when there are people who soften the hard edges of the gears as they grind forward. One of the moments that has stood out for me in the last decade was the Twitter API Field Guide created by Taylor Singletary (@episod) during his time as an evangelist at Twitter. This field guide was removed by Twitter (not sure when as I just noticed today), but the original blog post remained...

The API Behind Every Feature In The User Interface

24 October 2016
I have blogged about this topic in the last 60 days, but I predict it is an area you will hear from me about regularly until I see it baked into more software solutions. CloudFlare, one of my favorite DNS API providers has what I think is the best approach to linking to an API in the bottom corner of every UI element in their dashboard. If you look in the bottom right corner, next to the help icon you will see an API link. When I click on the API link I'm given the API path that corresponds to the UI element. In this scenario it allows me to purge the cache for my domain. I am also given a link to the full CloudFlare API documentation. I have always been an advocate for companies making sure to have an "API" or "Developer" link in the footer of their main website...

Prototype API Design Guide Builder Developed On Top Of API Stylebook

24 October 2016
I was pretty happy when my friend Arnaud Lauret (@arno_di_loreto) developed API Stylebook. I want to see his work expand and grow into someday containing hundreds or thousands of API design guides. To help contribute to his work I took the YAML core of the design topics he's aggregated and began developing an API design guide builder that runs 100% on Github, allowing anyone to fork, and use to build their own API Stylebook on top of Arnaud's work. Currently, I have two screens for API design guide builder: Editor - Allows for the editing of the YAML API Design Stylebook stored in the Github repository. View - Allows you to view the API Design Stylebook stored in the Github repository...

Amazon Groups Should Share More API Design Patterns

24 October 2016
The sharing of common API design patterns is something we are really bad at in the API space. I'm not a believer that there is one API design pattern to rule them all, but I am a believer in learning from what works, consuming other people's APIs, and sharing design tips over the cubicle wall. I don't believe that everyone should be 100% REST-compliant in the crafting of their APIs, but you should be picking your head up from time to time, and learning from what the rest of the world is up to, especially across the other groups within your own company. I tend to shy away on critiquing companies on API design, and prescribing any specific approach, but I can't help but point out inconsistencies in any approach, when it is clear that they aren't tuning into some of the common patterns out there, especially between their own internal groups...

An API Discovery API For Your API With Tyk

21 October 2016
If you are selling services to the API space you should have an API, it is just how this game works (if you are savvy). I was going through Tyk's API for their open source API management solution and came across their API definitions API, which gives you a list of APIs for each Tyk deployment--baking in API discovery into the open source API management solution by default. The API API (I still enjoy saying that) gives you the authentication, paths, versioning, and other details about each API being managed. I'm writing about this because I think that an API API should be the default for all API service providers. If you are selling me API services you should have an API for all your services, especially one that allows me to discover and manage all the APIs I'm applying your service to...

Does Your Business Model Reflect Where Your API Deployment Is Going

21 October 2016
I've been thinking about the concept of a wholesale API for some time. Going beyond how we technically deploy our APIs, and focusing more on how we can provide a wholesale version of the same API resources, with accompanying terms of services that go beyond just a retail level of API access in the cloud. Not all APIs fit into this category of API, but with the containerization of everything, and the evolving world of Internet of Things (IoT), there are many new ways in which API resources are being deployed. You can see this evolution in how we are deploying APIs present in one of the latest API deployment platforms I added to my API deployment research, Nanoscale.io. This image is just a portion of their platform, but the separation of deployment concerns articulates the technical side of what I'm talking about, we just need to add in considerations for the business and political side of how this works...

Icons To Describe Each Of Your API Resources Like AWS

21 October 2016
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...

The Potential Of The OpenAPI Spec Parameters Object

20 October 2016
I enjoy learning from the OpenAPI Specs of the API providers I track on. Just having an OpenAPI Spec present tells a lot about an API provider in my book, but the level of detail some providers put into their API definitions adds another level to this for me. While reviewing the OpenAPI Spec for the Oxford Dictionaries API, I noticed their robust usage of the OpenAPI Spec parameters definitions collection, which provides an interesting overview of the surface area of the API, augmenting the benefits brought to the table by the definitions collection of an APIs underlying data schema. When you are defining each path for an API you can either define the parameters using each paths parameters, or you can add them to the overall parameters definition object, allowing them to be reused across all paths...

The Open Guide to Amazon Web Services

20 October 2016
I keep an eye on things that are trending daily and weekly on Github because it is a great way to discover new companies and individuals doing interesting things with APIs. While looking at this earlier this week I came across the open guide to Amazon Web Services, a pretty robust, and well organized getting started guide to everything AWS. Here is their description of this resource out of the leading cloud computing platform: A lot of information on AWS is already written. Most people learn AWS by reading a blog or a “getting started guide” and referring to the standard AWS references. Nonetheless, trustworthy and practical information and recommendations aren’t easy to come by...

What Is More Important? Helping New Users Be Aware Of APIs Or Pushing Concept Forward?

20 October 2016
This is a topic that has come up in several discussions lately and is a topic I struggle with on a regular basis. What is more important, helping new users, both developer and non-developer be more aware of APIs, or is helping push forward the concept of APIs amongst those who are already tuned in? While I don't think there is a perfect answer, I think it is an important concept to explore and discuss. I started API Evangelist on the premise of helping educate new users about the importance of APIs and is something I regularly strive to do, but if you read my blog I definitely do not always keep things simple and accessible to a wide audience. I keep coming back to this founding premise of API Evangelist and work hard to write about 101, and 201 level concepts, despite definitely being a card carrying member of the core API community...

Reducing Friction For API Developers With Enums In API Definitions

20 October 2016
I am going through the Oxford Dictionaries API, learning about this valuable resource. Their onboarding process for registration, and learning about what the API does using interactive documentation, is very smooth. One of the things that really cuts the rough edges off learning about each API are the enums that are available for each path. The parameters required for making calls to many of the paths, like language and country, have their enum values populated as part of their API definition. I look at numerous OpenAPI Specs in the course of my work and they rarely have values present for enum, providing critical default values for developers to use--eliminating some often serious frustration...

What Are Your Intentions With My API?

20 October 2016
While it can be easy to bash on API providers for being tight with their API resources, it can be very difficult to be an API provider operating in today's online environment. Some developers are just badly behaved and hold some pretty unrealistic expectations when it comes to opening up access to valuable content, data, and algorithms. This is why I work to be supportive of providers when locking down their API resources, as long as they do it a constructive way. One positive approach I came across recently was from the Oxford Dictionaries API, who ask a lot of questions as part of their API signup form, but I felt it was a positive experience, and provided no barriers to me gaining access to their valuable API resources...

How Do We Keep The Fire Alive In API Space?

19 October 2016
It is tough to keep a sustained fire burning in the world of technology, at the individual, organizational, and community level. I have been doing API Evangelist full time for six years, and it is no secret that I have had several moments where I've experienced a crisis of faith, and I do not doubt that there will be many more of these in my future--there is no perfect solution. It takes hard work, creativity, and a myriad of other considerations to keep going, stay energized, and keep other folks doing the same. I have spent a great deal of time this fall thinking about all of the factors that influence me, and contribute to the fire burning, or acting as a flame retardant to me and the API space...

We Want To Do APIs -- You Already Are, It Is Just Not In An Organized Way

19 October 2016
I have a number of folks at companies, organizations, institutions, and government agencies come to me saying that they want to do APIs, and they need some help. In many of these discussions, the first task centers around addressing the motivations behind this declaration and helping folks realize they are already doing APIs, they are just not doing it in any sort of coherent and organized fashion. Any business, organization, institution and government agency is moving machine readable data between internal, and with external systems in 2016, for use in a variety of applications. This is just done in a variety of often proprietary, ad-hoc, data dump, and other approaches that are often dictated without any coherent vision...

OpenAPI Spec Google Spreadsheet to Github Jekyll Hosted YAML

19 October 2016

All The Right Channel Icons In Support Of Your API Platform

18 October 2016
I look at a lot of websites for companies who are providing APIs and selling services to the API space. When I find a new company, I can spend upwards of 10 minutes looking for all the relevant information I need to connect. Elements like where their Twitter and Github accounts are. These are all the key channels I am looking for so that I can better understand what a company does and stay in tune with any activity, but they are also the same channels that developers will be looking for so that they can stay in tune a platform as well. I spend a great deal of time looking for these channels, so I'm always happy when I find companies who provide a near complete set of icons for all the channels that matter...

Learning About APIs Has To Be Relevant And Interesting

18 October 2016
I am working on a project with a 16-year-old young lady to extract and tell a story using the YouTube API. I'm pretty excited about the project because the young lady happens to be my daughter Kaia Lane. If you've ever seen my API Blah Blah Blah t-shirt, you've seen her work. Historically she could care less about APIs, until recently when pulling data about one of her favorite YouTube stars came up--suddenly she is interested in learning more about APIs. During regular chatting with my daughter, I shared a story on the entire history of Kickstarter projects broken down by a city. She is a little geeky and likes Kickstarter, so I figured I'd share the approach to telling stories with data, and said that if she ever wanted help telling a story like this using YouTube, Instagram, or another platform, that she should let me know...

A More Honest And Flexible API Contract Using Hypermedia

18 October 2016
One of the reasons I write so much on API Evangelist is to refine how I tell stories about APIs and hopefully make a bigger impact by being more precise in what I'm saying. I feel like one of the reasons why hypermedia API concepts have to take longer than we anticipated to spread is because many (not all) of the hypermedia elite suck at telling stories. I am sorry, but you have done a shit job selling the importance of hypermedia, and often times were just confrontational and turning many folks off to the subject. I am working on playing around with telling different stories about hypermedia, hoping to soften some of the sharp edges of the hypermedia stories we tell. One of the core elements of hypermedia APIs is they provide us with links as part of each API response, emulating much of what works with the web, in the system to system, and application layers of the web...

The Twitter Branding Page Provides Minimum Bar For API Providers

18 October 2016
API branding is an area that I find to be contradictory in the space, with the loss of brand control being in the top concerns for companies when doing APIs, while simultaneously one of the most deficient areas of API operations, with most API providers have no branding guidance in their developer portal whatsoever. I think it is just one of those telling aspects of how dysfunctional many companies are, and how their concerns are out of alignment with reality, and where they are investing their resources. Every API should have some sort of branding page or area for their API operations--I even have a branding page. ;-) If you are looking for a healthy example to consider as a baseline of your branding page, take a look at Twitters branding page, which provides the essential building blocks you should be considering: Simple URL - Something easy to find, easily indexed by search engines, even a subdomain like Twitter does...

Are API Docs & Definition Formats A Single Thing Or Separate?

18 October 2016
I was reading a virtual panel: document and description formats for web APIs, and thought the conversation was very productive when it comes to helping bring the world of API documentation and definitions into better focus. I encounter daily reminders that folks do not see the many dimensions of API definitions, and the role they play in almost every stop along the life cycle. This virtual panel helps move this discussion forward for me, providing some clarification for when it comes to the separation between API definitions and API documentation. One of the questions asked of the panels was "Do you see API Documentation and Description formats as a single thing? Or multiple things?" Which I found Zdenek Nemec (@zdne) answer to be a great introduction for folks when it comes to understanding the importance of this separation: There are definitely two different things...

Convert OpenAPI Spec to Slate / Shins Markdown API Docs

17 October 2016
Someone turned me on to an OpenAPI Spec to Slate / Shins compatible markdown converter on Github this last week. I have been an advocate for making sure we are still using machine readable API definitions for our API documentation, even if we are deploying the more attractive Slate. I've been encouraging folks to develop an attractive option for API documentation driven by OpenAPI Spec for some time, so I am happy to add this converter to my API documentation research and toolbox. The OpenAPI Spec to markdown converter also introduced me to a version of Slate that is ported to JavaScript / Node.js called Shins. I'm going to add Shins to my API documentation research, and "widdershins" the OpenAPI Spec to markdown converter to my API definition research...

Thinking More About API Driven Conversational Interfaces

17 October 2016
I am spending a lot of time thinking about conversational interfaces, and how APIs are driving the voice and bot layers of the space. While I am probably not as excited about Siri, Alexa and the waves of Slack bots being developed as everyone else, I am interested in the potential when it comes to some of the technology and business approaches behind them. When it comes to these "conversational interfaces", I think voice can be interesting, but not always practical for actually interacting with everyday systems--I just can't be talking to devices to get what I need done each day, but maybe that is just me. I'm also not very excited about the busy, chatty bots in my Slack channels, as I'm having trouble even dealing with all the humans in there, but then again maybe this is just me...

Discovering New APIs Through Security Alerts

17 October 2016
I tune into a number of different channels looking for signs of individuals, companies, organizations, institutions, and government agencies doing APIs. I find APIs using Google Alerts, monitoring Twitter and Github, using press releases and via patent filings. Another way I am learning to discover APIs is via alerts and notifications about security events. An example of this can be found via the Industrial Control Systems Cyber Emergency Response Team out of the U.S. Department of Homeland Security (@icscert), with the recent issued advisory ICSA-16-287-01 OSIsoft PI Web API 2015 R2 Service Acct Permissions Vuln to ICS-CERT website, leading me to the OSIsoft website. They aren't very forthcoming with their API operations, but this is something I am used to, and in my experience, companies who aren't very public with their operations tend to also cultivate an environment where security issue go unnoticed...

Defining OAuth Scope Inline Within The API Documentation

17 October 2016
I am working on a project using the Youtube API, and came across their inline OAut 2.0 scopes, allowing you to explore what the API does as you are browsing the API docs. I am a huge fan of what interactive documentation like Swagger UI, and Apiary brought to the table, but I'm an even bigger fan of the creative ways people are evolving upon the concept, making learning about APIs a hands-on, interactive experience wherever possible. To kick off my education of the YouTube API I started playing with the search endpoint for the Youtube Data API. As I was playing with I noticed the had an API explorer allowing me to call the search method and see the live data. Once I clicked on the "Authorize requests using OAuth 2...

People Do Not Know What Your API Does If You Do Not Showcase It

17 October 2016
With a lot of my storytelling, I feel like captain obvious, but I also recognize the importance of simple, and sometimes repetitive storytelling to help reach my audience of time and resource-strapped API providers. Sometimes API providers are just too busy to remember the small things, and this is where I come in to help you remember some of the most obvious aspects of providing APIs that can be essential to success. This morning's reminder is that nobody will know the cool things your API does if you do not showcase what is being done with it. This is why I added my API showcase research, to highlight the approach of the successful API providers, and give me a regular reminder to write about the topic...

Transparency In Police Access To Social Platforms Using OAuth And APIs

14 October 2016
I was learning about Geofeedia providing law enforcement access to social media data from Twitter, Facebook, and Instagram via their API(s) this week. Geofeedia was making money by selling surveillance services to law enforcement build on top of these social APIs and is something that I guess Facebook and Instagram have cut-off access, but they could still have Twitter access through a reseller (Gnip?).  This isn't something that will just go away. If law enforcement wants access to user's data on Facebook, Twitter, and Instagram, they are going to get it. I am guessing that the rules regarding what law enforcement can or can't do aren't clear (I will have to learn more), and something that is just left up to platforms to enforce via their terms of service...

The Monitoring Layer Of The DevOps Aggregation API Platform

14 October 2016
While spending some time going through my API monitoring research I found myself creating an OpenAPI spec and APIs.json index for the DataDog API, and had the realization that this is the beginning of what I'm looking for when I was talking about a DevOps aggregation API platform. DataDog is just the monitoring layer of this vision I have, but it has many of the other elements I'm looking for. DataDog has all the monitoring elements present in their API platform, and they have all the platform integrations I'm envisioning in a DevOps aggregate API. We just need the same thing for design, deployment, virtualization, serverless, DNS, SDK, documentation, and the other critical stops along a modern API life cycle...

Taking A Fresh Look At The Twitter API

14 October 2016
I am working on profiling the Twitter API again, and I thought their stack of APIs have evolved significantly beyond what we tend to think of as the Twitter API, and was worth taking another look at. It is easy to think of Twitter API being about tweeting, friends, and following people, and #hashtags, but they have an interesting mix that I think tells its own story about Twitter's journey. Here is the current Twitter API stack: Public REST API - The public REST APIs provide programmatic access to read and write the Twitter data -- what we think of when we talk about the Twitter API. Media API - The APi for managing photo, videos or animated GIFs, that are used by other Twitter API endpoints when tweeting, direct messaging, and others...

Slack Shares Their View On Bot Advertising

14 October 2016
I was reading the hard questions on bot ethics from Slack, and their thoughts on bot advertising grabbed my attention. Trying to understand how bots will be monetizing things has been something I'm learning about, so I found Slack's post rather timely, and relevant to this fast growing layer of the API world.  Here was Slack's view on advertising with bots by developers: A bot should not serve ads unless it has a strong, expressed purpose that benefits the user in doing so, and even then only on B2C platforms. I would hate to see bots becoming the new tracking pixel. Bots should not be prompting users to click on things and buy things unless explicitly asked to do so. They continue by adding that, "ads in apps are against the Slack API terms of service, and that makes me rather proud"...

Including The Twitter Object Nest API As A File Upload API Example

14 October 2016
One request I get from folks on a regular basis, is an example of file upload APIs. Each time I get one of these requests I regret that I do not have more file upload and storage APIs profiled, allowing me to share a list of examples. So file upload APIs are high on my list to keep an eye out for as I'm doing my regular monitoring and mapping of the API universe.  An API I wanted to add to this list was the TON (Twitter Object Nest) API, which "allows implementers to upload media and various assets to Twitter". The TON API is an interesting model for me because it supports resumable, and non-resumable uploads--with all files over 64MB required to be resumable. I wanted to profile the API in a story, and add some of the key aspects to my research on file upload APIs, so that I could reference in future conversations...

The Open Skills API From Dept of Labor & University of Chicago

13 October 2016
We like to talk about the API economy in this space. It is kind of the grand dream of API obsessed, that helps us articulate how big of a deal we think APIs are going to be. We know APIs are going to be big, but in reality, the impact most APIs make don't size up. This is one of the reasons I'm such a big support of APIs in the public sector, as the potential for a positive impact tends to be greater in my opinion. One of the APIs that has the potential to contribute at the API economy scale is out of a partnership between the Department of Labor and the University of Chicago--the DataAtWork Open Skills API. Providing "a complete and standard data store for canonical and emerging skills, knowledge, abilities, tools, technologies, and how they relate to jobs"...

Preserving The Sunlight On Github

13 October 2016
I'm following along as the Sunlight Foundation winds down their operations and gathering any lessons along the way, that can help us open data and transparency folks can learn from as we do our work. I wrote earlier that we should be learning from the Sunlight Foundation situation and that we are making sure we bake transparency into our projects and wanted to continue to extract wisdom we can reuse as they turn out the lights. The Sunlight Foundation shared that they are working with the Internet Archive and Github to preserve their projects, and that they are "trying to ensure the open source community can understand and use our projects in the future" by: adding documentation standardizing licenses  scrubbing sensitive info This is the benefits of being transparent and open by default is that you tend to do all of this in real-time...

Drones And Other Devices Having Their Own Software Defined Networks

13 October 2016
I was learning about Verizon starting to sell wireless data plans for drones in the Wall Street Journal, as part of my research on what could be a drone API stack. As an Internet of Things (IoT) concept, I find drones fascinating because they can have so many dimensions of APIs at play. The drone, its camera, battery, and other components can have APIs. They can publish video to Youtube, Facebook via APIs. They can receive real-time updates about weather, fire, infrastructure, and other changing events via APIs. This post is about thinking through about network API layer when it comes to drones. If we are going to be rolling out networks for specific devices like drones, automobiles, and other IoT devices, it seems like every object should have an API, including the underlying network itself...

Keeping API Communications In Shape With Workbench Blogging

13 October 2016
I consider about 75% of the content I create on my network of sites to be workbench blogging--where I tell the story of what I am working on each day. You can see this approach in action with my friend Guillaume Laforge (@glaforge) over at Google, with his post on a day in the life of a Developer Advocate for Google Cloud Platform. Guillaume is workbench blogging, pulling back the curtain on API operations a little bit, while also keeping API communications flowing. This type of blogging isn't about any specific API, feature, or products and services. Workbench blogging really isn't about people learning any particular thing, they are more about pulling back the curtain, humanizing API operations, generating a little SEO, while also keeping the communication pipes open...

Saving and Versioning API Definitions In Editor Using Github Gists

13 October 2016
My friend Jordan Walsh (@jordwalsh) just released a new take on the Swagger editor, that inches closer to my vision of a dream API sketchbook and portfolio. His swagger-gist.io tool allows you to open and save your API definitions to Github Gists, allowing you to use the snippet sharing solution to manage your API definitions, and their evolution. While it isn't my entire vision for an API sketchbook and portfolio, swagger-gist.io's usage of Github Gists is a move in the right direction. This is just the first draft of his tool, and it looks like he plans on building in more of the API definition management features I am looking for--leveraging Github Gists as the book, in my sketchbook definition...

The White House Wants Our Thoughts On Data Portability

12 October 2016
The White House is looking for our thoughts on data portability. While it is the U.S. federal government asking for our thoughts, something that could apply to our tax returns, veterans records, or student loan information. They seem to be most interested in what data portability means to us as consumers, or via many online services today--as the product. Here is what they are looking for: The Office of Science and Technology Policy (OSTP) is interested in understanding the benefits and drawbacks of increased data portability as well as potential policy avenues to achieve greater data portability. The views of the American people, including stakeholders such as consumers, academic and industry researchers, and private companies, are important to inform an understanding of these questions...

APIs Driving Augmented Reality For Drones

12 October 2016
Now that I have API Evangelist fired back up I am spending more time with my drones, working to understand the role APIs can play in the booming industry. I have been studying how companies like Airmap are working to be API brokers for the drone industry, and how government open data and APIs are being injected into the personal and commercial drone experience. I want to continue this exploration, and learn more about how companies are injecting data, content, and other algorithmic resources into this experience, and brainstorm some other approaches to augmenting the world of drones with API resources. As part of my regular monitoring of the space, I am tuned into many of the examples of how drones are being used...

We Understimated The Time It Would Take For Hypermedia To Be Absorbed

12 October 2016
While I still see a steady uptick in the number of hypermedia APIs out there in the wild, as well as conversations around the different media types that are available, I think we severely underestimated the time it would take for the average API developer to absorb and accept the concept. When you are immersed in any of the leading formats, from HAL to Siren, and you have the aha moment about why hypermedia makes sense, it can be easy to think everyone will see the future like we do. When in reality, I just don't think people are always seeking the wisdom in the same way, they are often just looking to get the job done. It takes a lot of work to become hypermedia literate. An investment, not everyone can afford...

Some Key IoT Security Considerations

12 October 2016
I am continuing to learn from folks studying the recent DDOS attack on Krebs on Security. While not a straightforward API story, it overlaps with the API world in several ways, from the technical aspects of how the IoT devices were hacked and enlisted in the bot army, to how the hack has been analyzed online, and the sharing of machine-readable details of the attack. There were some interesting nuggets from the attack analysis I wanted to include in my wider Internet of Things (IoT) research. When it came to the security lapses in the surveillance cameras, printers, and other devices used as part of the DDOS, there were several key areas in play: Username / Password - Default passwords for devices aren't changed, or the settings of unique passwords are not enforced...

Do You Have Agencies Ready To Develop With Your API?

12 October 2016
I was doing some research on how API providers are providing certification of their developers. I want to better understand how leading API providers are developing curriculum for certifying that developers have the skills needed to integrate with their API, and how API providers are also showcasing these certified developers. As I was looking through various API programs I came across Google's Developers Agency Program, where they certify companies as competent to work with Google's APIs when developing Android applications. Google provides an eBook to help provide agencies with the resources they need to get certified, the details on how to get certified, as well as a page showcasing the agencies that have been certified...

I Am Stuck On The Datadog Integration Page

11 October 2016
I wrote about having an integrations page for your API service the other day, and as I'm continuing to study the approach of other providers I find myself stuck on b DataDog's integration page. Datadog provides the monitoring layer across many of the top service providers in the space, making for a pretty stellar list of what solutions are being put to use across the sector.  The Datadog integration page has been open in my browser for the last week, as I make way through each provider. Some of them I'm very familiar with, but others are entirely new to me. Integration pages like this show me what is possible with a service provider like Datadog, but also provides me an opportunity to learn about new services that I can put to use in my own operations, and what the cool kids are using...

Expanding On The 3rd Party Analysis Of Security Threats

11 October 2016
I was learning from the Splunk's analysis of the Mirai Botnet, which was behind the massive attack against Krebs on Security, implemented via common Internet of Things devices like security cameras, and printers. I've been reading several of these types of security event analysis, which is something I think is extremely important in helping the industry deal with the increasing number of security events that are occurring across the online landscape.  The sharing of log files from compromised systems in this way is super important. We need as many eyes as we can get on these attacks, helping analyze what happened, and maybe possibly who was behind it. Of course, there are some scenarios where you might want to be cautious in opening up this data to the general public, but using common approaches to API deployment and management, this can be managed sensibly--while also adding another logging layer to the conversation, keeping track of who joins participates in the analysis...

API Embeddables With Skills and Intent

11 October 2016
I am seeing some renewed interest and discussion around API driven embeddable(s)--an area of my API research that has been going on for years, focusing on buttons, badges, and widgets, but is something that I'm seeing continued investment in from API providers lately. To help fuel the innovation that is already occurring, I figured I'd contribute with my API thoughts extracted from across the bot and voice API landscape. As I monitor the bot community growing out of the Slack platform, the voice API integration emerging from the Alexa development community, and read news about Google's latest push into the space, I'm thinking about how APIs are being used to define the intents, skills, and actions that are driving these bot and voice implementations...

Some API Embeddable Best Practices Out Of Yelp

11 October 2016
Yelp has shared some of the wisdom behind how they design, deploy, and operate their embeddable reviews. I like it when leading API providers share the story behind their tooling like this. This type of storytelling generates SEO for their API, educates their API consumers, and provides educational resources for other API providers (and content for analysts like me). So, what makes for a good embeddable widget, according to Yelp? a minimal amount of HTML code  a consistent & responsive design stay up-to-date with contextual information load fast & gracefully handle traffic spikes record accurate analytics Yelp shares a little bit about the technical approach to achieving their definition of a good embeddable widget, which "are served as Yelp pages within iframes, adhere to the Yelp Styleguide, and show the most up-to-date review": iframe embeds allow for a simpler widgets...

iPaaS In Your Browser With Push By Zapier

11 October 2016
Zapier is up to more good things with the launch of Push by Zapier, allowing you to trigger API driven events from your browser. The new Chrome browser extension lets anyone, even non-developers to trigger the functionality of over 700 apps from the browser toolbar--further expanding the definition of how APIs can be put to work. Allowing users to trigger API functionality from the browser adds an empowering dimension to the API conversation for non-developers. It allows the average user to access the features of any SaaS platform with an API, in their default environment--the browser. It allows the user to define, and queue up the API driven events that matter to them, where they operate the most...

Opportunity For Someone To Help Organize Auto Industry Data

10 October 2016
There is a lot of data coming out of the automobile industry. I was just reading about Udacity open sources an additional 183GB of driving data and the global public registry of electric vehicle charging locations with 42K+ listings, providing us with two examples from the wild. I'm seeing an increasing number of these stories about institutions, government agencies, and the private sector making automobile related data available in this way--pointing to a pretty big opportunity when it comes to aggregating this valuable "data exhaust" (pun intended) in a coherent way. Whether its self-driving, electric, car share, rental or otherwise, the modern automobile is generating a lot of data...

The Internet of Things Shows Us How Regulatory Beasts Are Created

10 October 2016
I am watching the world of Internet of Things (IoT) unfold, not because I'm a big fan of it, but more because I'm concerned that it is happening, and often worried that much of it is happening without any focus on security, and privacy. As I look at this week's stories in my API IoT bucket I can't help but think that IoT is a live demonstration of how the regulatory beasts, that we love to hate on in America, are created. It starts with a bunch of fast moving, greedy, corner cutting capitalists who are innovating and all that shit. These are not always the first wave of movers in a space, but usually the second and third waves of opportunists with one thing in mind--making some money. These are the companies that are so focused on revenue and profits they ignore things like security, and they see the data generated being key to their success, and concepts around privacy often do not even exist--it's the new oil motha fuckkers! As the number of security and privacy events increase, things like the unprecedented attack on Krebs on Security, the calls for a fix will only grow...

Embrace, Extend, and Exterminate In The World Of APIs

10 October 2016
I am regularly reminded in my world as the API Evangelist that things are rarely ever what they seem on the surface. Meaning that what a company actually does, and what a company says it does are rarely in sync. This is one of the reasons I like APIs, is they often give a more honest look at what a company does (or does not do), potentially cutting through the bullshit of marketing. It would be nice if companies were straight up about their intentions, and relied upon building better products, offering more valuable services, but many companies prefer being aggressive, misleading their customers, and in some cases an entire industry. I'm reminded of this fact once again while reading a post on software backward compatibility, undocumented APIs and importance of history, which provided a stark example of it in action from the past: “Embrace, extend, and extinguish“,[1] also known as “Embrace, extend, and exterminate“,[2] is a phrase that the U...

Google Shares Insight On How To Improve Upon The API Experience

10 October 2016
We all like it when the API providers we depend on make using their APIs easier to put to work. I also like it when API providers also share the story behind how they are making their APIs easier to use because it gives me material for a story, but more importantly it provides examples that other API providers can consider as part of their own operations. Google recently shared some of the improvements they have made to help make our API experience better--here are some of the key takeaways: Faster, more flexible key generation - Making this step simpler, by reducing the old multi-step process with a single click. Streamlined getting started flow - Introduced an in-flow credential set up procedure directly embedded within the developer documentation...

Regulatory API Monitoring For Validating Algorithmic Assertions

07 October 2016
As I was learning about behavior driven development (BDD) and test driven development (TDD) this week, I quickly found myself applying this way of thought to my existing API regulation, and algorithmic transparency research. BDD and TDD are both used by API developers to ensure APIs are doing what they are supposed to, in development, QA, and production environments. There is no reason that this line of thought can't be elevated beyond just development groups to other business units, up to a wider industry level, or possibly employed by regulators to validate data or algorithmic solutions. I am not a huge fan of government regulation, but I am a fan of algorithms doing what is being promised, and APIs plus BDD and TDD testing is one way that we can accomplish this...

Amazon Launches Their Own QA Solution Called AWS Answers

07 October 2016
Amazon launched their own questions and answers site called simply called AWS Answers. Amazon is definitely in a class of their own, but I thought the move reflects illnesses in the wider QA space and an approach that smaller API providers might want to consider for their operations. Quora doesn't have an API, so why would we use as a QA solution for the API space? I don't care how much network they have. While Stack Overflow is a wealth of API related questions and answers, the environment has been found to be pretty toxic for some API providers. Making hand rolling your own QA site a more interesting option. AWS answers is a pretty basic implementation but also has a wealth of valuable content...

The Anatomy Of API Call Failure

07 October 2016
I have been spending time thinking about how we can build in fault tolerance, and change resiliency into our API SDKs, and client code. I want to better understand what is necessary to develop the best possible integrations as possible. While doing my regular monitoring this week I came across a Tweet from @Runscope, with a pretty interesting image on this subject crafted by @realm, a mobile platform for sync. There is a wealth of building blocks here to apply at the client and SDK level, helping us achieve more fault tolerance, and make our applications, systems, and device integrations more change resilient. I wanted to break them out, providing a bulleted list I could include in my research: Is the API Online? Did the server receive the request? Was URL request successful? Did the request timeout? Was there a server error? Was JSON receive successfully? Was JSON malformed? Was there an unexpected response? Were we able to map to JSON successfully? Is the JSON valid? Does local model match server model? There are some valuable nuggets present in this diagram...

Harmonizing API Definitions Across Government With The U.S. Data Federation

07 October 2016
Sharing of API definitions is critical to any industry or public sector where APIs are being put to work. If the API sector is going to scale effectively, it needs to be reusing common patterns, something that many API and open data providers have not been that great at historically. While this is critical in any business sector, there is no single area where this needs to happen more urgently than within the public sector. I have spent years trying wade through the volumes of open data that comes out of government, and even spent a period of time doing this in DC for the White House. The lack of open API definition formats like OpenAPISpec, API Blueprint, APIs.json, and JSON Schema across government is a passion of mine, so I'm very pleased to the new US Data Federation project coming out of the General Services Administration (GSA)...

Hacking on Amazon Alexa with AWS Lambda and APIs At @APIStrat

07 October 2016
I'm neck deep in studying how Amazon is operating their Alexa platform, so I'm pretty excited about the chance to listen and learn from the Alexa team at APIStrat in Boston. Even if you aren't building voice-enabled applications, the approach to developing, managing, and evangelizing the Alexa platform provides a wealth of best practices that we should all strive to emulate in our own operations. Rob McCauley (@RobMcCauley) from the Amazon Alexa team is doing a workshop, as well as a keynote at @APIStrat in Boston next month. This is relevant to what is going on in the wider space because voice-enablement is a fast-moving layer when it comes to delivering API resources, helping define what is being dubbed as the conversational interface movement, while also providing the best practices for a modern API strategy that I mentioned above...

Your Southwest Airlines Flight Has An API

06 October 2016
A friend of mine messaged me this photo of the Southwest Airlines flight API on Facebook the other day. After doing a little homework I found that every flight has this available on the planes local network. There is a pretty interesting write up on it from Roger Parks if you care to learn more. Looking through the response it has all the information you need for your flight update screen. It might seem scary for folks like us poking around the network on airplanes looking for things like this, but this is just the nature of the Internet and something any network operator should consider as normal. The API is available at getconnected.southwestwifi.com/current.json when you are on the planes local network, and I'd consult Roger's post if you want more details about how to sniff it out using your browser...

Adding Behavior-Driven Development Assertions To My API Research

06 October 2016
I was going through Chai, a behavior, and test driven assertion library, and spending some time learning about behavior driven development, or BDD, as it applies to APIs today. This is one of the topics I've read about and listened to talks from people I look up to, but just haven't had the time to invest too many cycles in learning more. As I do with other interesting, and applicable areas, I'm going to add as a research area, which will force me to bump it up in priority. In short, BDD is how you test to make sure an API is doing what is expected of it. It is how the smart API providers are testing their APIs, during development, and production to make sure they are delivering on their contract...

Providing Inline API Documentation Within Your SaaS User Interface

06 October 2016
The common approach to discovering that a SaaS provider has an API is through a single, external link in the footer of a website, simply labeled API or developers. Whenever I can I'm on the lookout for evolutionary approaches to making users aware of an API, and I just found a good one over at CloudFlare. When you are logged into CloudFlare managing your DNS, right below the area for adding, editing, and deleting DNS records you are given some extra options, including expandable access to your API--down in the right-hand corner, between Advanced and Help. Once you click on the API option, you are given a listing of DNS record related API endpoints, allowing me to bake the same functionality available to me in the CloudFlare UI, into my own systems and application...

An Auditing API For Checking In On API Client Activity

06 October 2016
Google just released a mobile audit solution for their Google Apps Unlimited users looking to monitor activity across iOS and Android devices. At first look, the concept didn't strike me as anything I should write about, but once I got to thinking about how the concept applies beyond mobile to IoT, and the potentially for external 3rd party auditing of API and endpoint consumption--it stood out as a pattern I'd like to have in the filing cabinet for future reference. Using the Google Admin SDK Reports API you can access mobile audit information by users, device, or by auditing event. API responses include details about the device including model, serial numbers, user emails, and any other element that included as part of device inventory...

A Machine Readable Jekyll Jig For Each Area Of My API Research

06 October 2016
I have over 70 areas of research occurring right now as part of my API lifecycle work--these are areas that I feel directly impact how APIs are provided and consumed today. Each of these areas lives as a Github repository, using Github Pages as the front-end of the research.  I use Github for managing my research because of its capabilities for managing not just code, but also machine readable data formats like JSON, CSV, and YAML. I'm not just trying to understand each area of the API lifecycle, I am working to actually map it out in a machine readable way.  This process takes a lot of effort, and is always work in progress. To help me manage the workload I rely on Github, the Github API, and Github Pages...

Where Is The WordPress For APIs?

05 October 2016
I feel like I have said this before, but probably is something that is worth refreshing--where is the WordPress for APIs? First, I know WordPress has an API, that isn't what I'm talking about. Second, I know WordPress is not our best foot forward when it comes to the web. What I am talking about is a ready to go API deployment solutions in a variety of areas, that are as easy to deploy and manage as WordPress. There is a reason WordPress is as popular as it is. I do not run WordPress for any of my infrastructure, but I do help others setup and operate their own WordPress installs from time to time. I get why people like it. I personally think its a nightmare in there, when you start having to make it do things as a programmer, but I fully grasp why others dig it, and willing to support that whenever I can...

Evolving The API SDK With APIMATIC DX Kits

05 October 2016
I've been a big supporter of APIMATIC since they started, so I'm happy to see them continuing to evolve their approach to delivering SDKs using machine readable API definitions. I got a walkthrough of their new DX Kits the other day, something that feels like an evolutionary step for SDKs, and contributing to API providers making onboarding and integration as frictionless as possible for developers. Let's walk through what APIMATIC already does, then I'll talk more about some of the evolutionary steps they are taking when auto-generating SDKs. It helps to see the big picture of where APIMATIC fits into the larger API lifecycle to assist you in getting beyond any notion of them simply being just an SDK generation service...

The Web Evolved Under Different Environment Than Web APIs Are

05 October 2016
I get the argument from hypermedia and linked data practitioners that we need to model our web API behavior on the web. It makes sense, and I agree that we need to be baking hypermedia into our API design practices. What I have trouble with is the fact that the web is a cornerstone that we should be modeling it after. I do not know what web y'all use every day, but the one I use, and harvest regularly is quite often is a pretty broken thing. It just feels like we overlooking so much to support this one story. I'm not saying that hypermedia principles don't apply because the web is shit, I'm just saying maybe it isn't as convincing of an anchor to build a story that currently web APIs are shit...

Github As The API Life Cycle Engine

05 October 2016
I am playing around with some new features from the SDK generation as a service provider APIMATIC, including the ability to deploy my SDKs to Github. This is just many of the ways Github, and more importantly Git is being used as what I'd consider as an engine in the API economy. Deploying your SDKs is nothing new, but when your autogenerating SDKs from API definitions, deploying to Github and then using that to drive deployment, virtualization, containers, serverless, documentation, testing, and other stops along the API life cycle--it is pretty significant. Increasingly we are publishing API definitions to Github, the server side code that serves up an API, the Docker image for deploying and scaling our APIs, the documentation that tell us what an API does, the tests that validate our continuous integration, as well as the clients and SDKs...

Considering A Web API Ecosystem Through Feature-Based Reuse

05 October 2016
I recently carved out some time to read A Web API ecosystem through feature-based reuse by Ruben Verborgh (@RubenVerborgh) and Michel Dumontier. It is a lengthy, very academic proposal on how we can address the fact that "the current Web API landscape does not scale well: every API requires its own hardcoded clients in an unusually short-lived, tightly coupled relationship of highly subjective quality." I highly recommend reading their proposal, as there are a lot of very useful patterns and suggestions in there that you can put to use in your operations. The paper centers around the notion that the web has succeeded because we were able to better consider interface reuse, and were able to identify the most effective patterns using analytics, and pointing out that there really is no equivalent to web analytics for measuring an APIs effectiveness...

Increased Analytics At The API Client And SDK Level

04 October 2016
I am seeing more examples of analytics at the API client and SDK level, providing more access to what is going on at this layer of the API stack. I'm seeing API providers build them into the analytics they provider for API consumers, and more analytic services from providers for the web, mobile, and device endpoints. Many companies are selling these features in the name of awareness, but in most cases, I'm guessing it is about adding another point of data generation which can then be monetized (IoT is a gold rush!). As I do, I wanted to step back from this movement and look at it from many different dimensions, broken down into two distinct buckets: Positive(s) More information - More data than can be analyzed More awareness - We will have visibility across integrations...

Please Share Your OpenAPI Specs So I Can Use Across The API Life Cycle

04 October 2016
I was profiling the New Relic API, and while I was pleased to find OpenAPI Specs behind their explorer, I was less than pleased to have to reverse engineer their docs to get at their API definitions. It is pretty easy to open up my Google Chrome Developer Tools and grab the URLs for each OpenAPI Spec, but you know what would be easier? If you just provided me a link to them in your documentation! Your API definitions aren't just driving the API documentation on your website. They are being used across the API life cycle. I am using them fire up and playing with your API in Postman, generating SDKs using APIMATIC, or creating a development sandbox so I do not have to develop against your live environment...

Making Data Serve Humans Through API Design

04 October 2016
APIs can help make technology better serve us humans when you execute them thoughtfully. This is one of the main reasons I kicked off API Evangelist in 2010. I know that many of my technologist friends like to dismiss me in this area, but this is more about their refusal to give up the power they possess than it is ever about APIs. I have been working professionally with databases since the 1980s, and have seen the many ways in which data and power go together, and how technology is used as smoke and mirrors as opposed to serving human beings. One of the ways people keep data for themselves is to make it seem big, complicated, and only something a specific group of people (white men with beards (wizards)) can possibly make work...

Amazon Alexa As An Example When It Comes To API Communications

04 October 2016
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...

An Integrations Page For Your API Solution

04 October 2016
A new way that I am discovering the new tech services that the cool kids are using is from the dedicated integrations pages of API service providers I track on. Showcasing the services your platform integrates with is a great way of educating consumers about what the possibilities are when it comes to your tools and services. It is also a great way for analysts like me to connect the dots around which services are most important to the average user. API service providers like DataDog, OpsClarity, and Pingometer are providing dedicated integration pages showcasing the other 3rd party platforms they integrate with. Alpha API dogs like Runscope also have integration APIs, allowing you to get a list of integrations your team depends on (perfect for another story)...

The Different Reasons Behind Why We Craft API Definitions

03 October 2016
I wrote a post about the emails I get from folks telling me the API definitions contained within my API stack research, something that has helped me better see why it is I do API definitions. I go through APIs and craft OpenAPI Specs for them because it helps me understand the value each company offers, while also helping me discover interesting APIs and the healthy practices behind them. The reason I create API definitions and organize them into collections is all about discovery. While some of the APIs I will be putting to use, most of them just help me better understand the world of APIs and the value and the intent behind the companies who are doing the most interesting things in the space...

APIs Can Give An Honest View Of What A Company Does

03 October 2016
One of the reasons I enjoy profiling APIs is that they give an honest view of what a company does, absent of all the marketing fluff, and the promises that I see from each wave of startups. If designed right, APIs can provide a very functional, distilled down representation of data, content, and algorithmic resources of any company. Some APIs can be very fluffy and verbose, but the good ones are simple, concise, and straight to the point. As I'm profiling the APIs for the companies included in my API monitoring research, what API Science, Apica, API Metrics, BMC Software, DataDog, New Relic, and Runscope offer quickly become pretty clear. A simple list of valuable resources you can put to use when monitoring your APIs...

A Dedicated Security Page For Your API Portal

03 October 2016
One area I am keeping an eye on while profiling APIs, and API service providers, are any security-related practices that I can add to my research. While looking through DataDog I came across their pretty thorough security page, providing some interesting building blocks that I will add to my API security research. This is all I do as the API Evangelist--aggregate the best practices of existing providers, and shine a light on what they are up to.  On their security page, DataDog provides details on physical and corporate security, information about data in transit, at rest, as well as retention, including personally identifiable information (PII), and details surrounding customer data access...

A Service Level Agreement API For API Service Providers

03 October 2016
I am spending some time profiling the companies who are part of my API monitoring research, specifically learning about the APIs they offer as part of their solutions. I do this work so that I can better understand what API monitoring service providers are offering, but also for the discoveries I make along the way--this is how I keep API Evangelist populated with stories.  An interesting API I came across during this work was from the Site24X7 monitoring service, specifically their service level agreement (SLA) API. An API for adding, managing, and reporting against SLA's that you establish as part of the monitoring of your APIs. Providing a pretty interesting API pattern that seems like it should be part of the default API management stack for all API providers...

Running Synthetic Data And Content Through Your APIs

03 October 2016
I was profiling the New Relic API and came across their Synthetics service,which is a testing and monitoring solution that lets you "send calls to your APIs to make sure each output and system response are successfully returned from multiple locations around the world"--pretty straight forward monitoring stuff. The name is what caught my attention, and got me thinking the data and content that we run through our APIs. Virtualization feels like it defines the levers and gears our API-driven systems, and synthetics feels like it speaks to the data and content that flows through flows through these systems. It feels like everything in the API stack should be able to be virtualized, and sandboxes, including the data and content, which is the lifeblood--allowing us to test and monitor everything...

Defining A Conversational Layer On Top Of APIs

30 September 2016
As I am exploring, and writing about Meya's Bot Flow Markup Language (BFML),  I came across the announcement from Google about their acquisition of API.AI, titled "Making Conversational Interfaces Easier to Build". I feel like this description reflects what I was writing about "Beyond Mobile: API Ready For iPaaS, Voice, and Bots", and sounds better to me than saying voice, bot, or integration workflow. Whether its skills for voice enablement, intents and flows for bot interactions, or triggers, actions, and integrations with iPaaS, I'm guessing we are going to need a way to define, and convey meaning through this growing conversation we'll be having using API resources. With OpenAPI Spec and API Blueprint we finally have adequate ways to describe where our data, content, and algorithmic resources reside, and a little bit about what they do, but it feels like we need a similar way of defining the conversational layer on top...

A Plan B API Switch

30 September 2016
I've had an idea for a bot-related service I call "plan b", which would act as a secondary action for any sort of bot request / response to an API. When developers are providing common bot responses like looking up a business address, sports statistic or stock quote, it could be exposed to suggestions for a "plan b". When a request is made, it can travel via its regular path, but it would also be included in a queue where other 3rd party developers could provide plan b suggestions, either free or paid. When a user is engaging with the bot and didn't like the primary response, they could click on the "plan b" option, opening up alternative responses. In theory, the user could cycle through each "plan b" suggestion until they find a suitable response...

API SDKs Getting More Specialized

30 September 2016
I have been doing a lot of thinking about the client and SDK areas of my research lately, considering how these areas overlap with the world of bots, as well as with voice, and iPaaS. I'm thinking about the hand-crafted, autogenerated, and even API client as a service like Postman, and Paw. I'm thinking about how APIs are being put to work, across not just web and mobile, but also systems to system integration, and the skills in voice platforms like Alexa, and the intents in bot platforms like Meya. I'm considering how APIs can deliver the skills needed for the next generation of apps beyond just a mobile phone. I kicked off my SDK research over a year ago, where I track on the approaches of leading platforms who are offering up code samples, libraries, and SDKs in a variety of programming languages...

If You Have An API For Your Platform You Are A Stage For Cybersecurity.Theater

30 September 2016
Adding to the many reasons you would want, or not want APIs these days, is the escalating cyber war playing out on the web around the world. APIs aren't playing a role in the cyber security realm in the way you'd think, allowing the bad guys, or even the good guys to get into systems, but they are how these actors are spreading information or disinformation about their cyber activities.  Increasingly Facebook, Twitter, Instagram, Reddit, and other API driven platforms are being used to broadcast, engage, and study the fast growing world of cyber security. Whether it is the Israeli Defense Force, U.S. Cyber Command, or a 15-year-old hacker in your basement, they are using these API driven channels to broadcast their message, as well as monitor the message of their adversaries, with us analysts following up behind trying to make sense of it all--using the same channels...

You Can't Say AI Benefits Outweigh Risk Without Some Algorithmic Transparency

30 September 2016
I am increasingly hearing the phrase, "the benefits outweigh the risks" applied when talking about AI, machine learning, and the increasing number of algorithmic decisions that are being made in all parts of our digital world. This seems to be the new default of AI and machine learning advocates looking to tip the scales in favor of their technology, over the human side of the discussion. This can be found used in discussions about AI used in self-driving cars, all the way to policing algorithms making decisions on the street or in a court of law. I'm not opposed to this argument if it is truly the case, but it seems something you can claim without providing the data behind this decision, and simply relying on your lack of faith in humans being able to consistently making decisions...

An Opportunity For A RESTful API Layer On Top Of New TensorFlow Models

29 September 2016
I was looking the open source models available for execution via the machine learning platform TensorFlow, and couldn't help but think there is a pretty big opportunity for a web API layer on top of it. After a little Googling, I see there is someone asking on Stack Overflow, Google Groups, and a student project to tackle the need. Maybe there are some other projects out there already in the works, but I couldn't find anything with 10 minutes of Googling (mad skills). Google has twelve pretty compelling machine learning models available on Github: autoencoder -- various autoencoders inception -- deep convolutional networks for computer vision namignizer -- recognize and generate names neural_gpu -- highly parallel neural computer privacy -- privacy-preserving student models from multiple teachers resnet -- deep and wide residual networks slim -- image classification models in TF-Slim swivel -- the Swivel algorithm for generating word embeddings syntaxnet -- neural models of natural language syntax textsum -- sequence-to-sequence with attention model for text summarization...

Beyond Mobile: API Ready For iPaaS, Voice, and Bots

29 September 2016
I enjoy being able to switch gears between all the different areas of my API research. It helps me find the interesting areas of overlap and potentially synchronicity in how APIs are being put to work. After thinking about the API abstraction layer present in Meya's bot platform, I was reading about Clearbit's iPaaS integration layer with Zapier. Zaps are just like the components employed by Meya, and Clearbit walks us through delivering intended workflows with the valuable APIs they provide, executed Zapier's iPaaS service. Whether its skills for voice, intents for bots, or triggers for iPaaS, an API is delivering the data, content, or algorithmic response required for these interactions...

Code Resiliency Lessons In How Twitter Deploys Their Embeddables

29 September 2016
I am learning about how Twitter deploys their widgets. Extracting some insight for my research around how we can build change resiliency into our client code. As I'm doing my regular monitoring of the API space I am trying to keep an eye out for any examples from leading providers of how there are investing in client code being more change resilient. This Twitter blog post provides me with three concepts I wanted to add to my research: Reversibility: ‘Rollback first, debug later’ is our motto. Rollback should be fast, easy, and simple. Ideally, it’s a giant red button that can get our heart rates down. Incremental release: All code has bugs and deploys have an uncanny way of surfacing them...

Flow Abstraction And Intent Layer On Top Of APIs To Feed The Bots

29 September 2016
I was reading an interesting post on developing bots from Meya, a bot platform provider, which I think describes the abstraction layer between what we are calling bots, and what we know as APIs. I have been trying to come up with a simple way of quantifying the point where bots and APIs work together, and Meya's approach to flow and intent provides me with a nice scaffolding. The flow step of their bot design rationale provides a nice way to think about how bots will work, breaking out each step of the bot interaction in plain English. They use a YAML format they call Bot Flow Markup lLnguage, or BFML, to describe the flows, comparing BFML to HTML, with this definition: HTML is spatial, and BFML is temporal...

SchemaHub's Usage Of Github To Launch Their API Service Is A Nice Approach

29 September 2016
I'm looking through a new API definition focused service provider called SchemaHub today, and I found their approach to using Github as a base of operations was interesting and provided a nice blueprint for other API server providers to follow. I'm continually amazed at the myriad of ways that Github can be put to use in the world of APIs, which is one of the things I love about it. As a base for SchemaHub, they created a Github Org, and made their first repository the website for the service, hosted on Github Pages. In my opinion, this is how all API services should begin, as a repo, under an organization on Github--leveraging the social coding platform as a base for their operations. SchemaHub is taking advantage of Github for hosting their API definition focused project--free, version controlled, static website hosting for schemahub...

Thinking About How I Can Build Change Resilience Into My API Integrations

28 September 2016
After I wrote a piece on guidance from the USGS around writing fault-resistant code when putting their API to use, my friend Darrel Miller expanding on this by suggesting I include "change resilience" as part of the definition.  @kinlane I would like to see that guidance expanded to include writing change resilient client code. — Darrel Miller (@darrel_miller) September 9, 2016 It is something that has sat in my notebook for a couple weeks, and keeps floating up as a concept I'd like to explore further. I have some initial thoughts on what this means but is something that I need to write about before I grasp better. Hopefully, it will bring more suggestions about what change resilient code means to other people...

The Bot Platform That Operates Like Alexa Will Win

28 September 2016
I'm going through Amazon's approach to their Alexa voice services, and it is making me think how bot platforms out there should be following their lead when it comes crafting their own playbook. I see voice and bots in the same way that I see web and mobile--they are just one possible integration channel for APIs. They each have their own nuances of course, but as I'm going through Amazon's approach, there are quite a few lessons on how to do it correctly here--that apply to bots.  Amazon's approach to investment in developers on the Alexa platform and their approach to skills development should be replicated across the bot space. I know Slack has an investment fund, but I don't see the skills development portion present in their ecosystem...

Every Government Agency Should Have An FAQ API Like The DOL

28 September 2016
I wrote about my feelings that all government agencies should have a forms API like the Department of Labor (DOL), and I wanted to separately showcase their FAQ API, and say same thing--ALL government agencies should have a frequently asked question (FAQ) API. Think about the websites and mobile applications that would benefit from ALL government agencies at the federal, state, and local level having frequently asked questions available in this way--it would be huge.  In a perfect world, like any good API provider, government agencies should also use their FAQ API to run their website(s), mobile, and internal systems--this way the results are always fresh, up to date, and answering the relevant questions (hopefully)...

We Focus On Interacting With The API Developer Community Where They Live

28 September 2016
Another story I harvested fro a story by Gordon Wintrob (@gwintrob) about how Twilio's distributed team solves developer evangelism, was about how they invest in having a distributed team, providing an on the ground presence in the top cities they are looking to reach. I know this isn't something all API providers can afford, but I still think it was still an important approach worth noting. Like with many other aspects of Twilio's approach, they are pretty genuine about why they invest in a distributed API evangelism team: We also focus on interacting with the developer community where we actually live. We don’t think it’s valuable to parachute into a tech community, do an event, and then leave...

Learning About OPC, The Interoperability Standard For Industrial Automation

28 September 2016
I am spending a portion of my time each week learning about how APIs are being applied at the industrial level. An example of this can be found over at Opto 22, with their approach to using REST across their Programmable Automation Controllers (PAC). As I do with other industries I spend my time looking through the approaches of API pioneers in the space, which leads me to other contributing factors to why web APIs are being used to change how things are done in any industry. For now, my industrial API research is a pretty big umbrella, encompassing oil & gas, manufacturing, and often moving into other areas I'm already tracking agriculture and energy. This approach allows me to identify companies who are leading the charge (like Opto 22), as well as specifications, tools, and other elements that are contributing to the evolution of APIs in each area--in this case, its broadly industrial usage of web APIs...

Github Needs Client OAuth Proxy For More Complete Client-Side Apps On Pages

27 September 2016
I'm building what I am calling "micro tools", that run 100% on Github. To push my work forward I developed a base template I can use for deploying apps that run 100% on Github, using Github Pages, the Github API, and Github OAuth as the engine. As a next step I wanted to develop a simple YAML editor that run on Github, allowing me to edit the YAML core of each tool, that is stored in the _data folder for each Jekyll site I host on Github Pages. The key to all of this working securely is Github personal access tokens, which every Github user has in their accounts under settings. I have employed this approach to running apps on Github Pages before using OAuth.io as the broker, something that works very well, and I highly recommend it...

API Access To Your Account By Default But Requires Permission To See Others

27 September 2016
I wrote about SoundCloud beginning to require approval before developers get access to any API resources yesterday, a concept that I want to keep exploring. I'm going to be going through the APIs track on, looking for different variations of this, but before I did this I wanted to explore a couple of approaches I already had rattling around in my head. What if, when you first sign up for API access you only get access to your own data, and content? You couldn't get access to any other users until you were approved. It seems like something that would incentivize developers to publish data and content, build their profiles out, which is good for the platform right? It will also protect other end-users from malicious activity by random developers who are just looking to wreak havoc in support of their own objectives and do not care about the platform--like we saw with Soundcloud...

Every Government Agency Should Have A Forms API Like DOL Does

27 September 2016
I was taking another look at the API efforts out of the Department of Labor (DOL), to help refresh my awareness of what they are serving up, and I came across the DOL Forms API. The API does what it says, providing access on " the most frequently requested Department of Labor forms", which seems like to me should be the default for ALL government agencies. The API returns some valuable details about each agency from including OMB number, URL, file extension, file size, and other meta information like a description, tags, and revision. I know that many in the API community would like all forms to be APIs, but I would be happy if we just started by making the concept of a forms API default across all government agencies first...

API Design Is Not Requirement For All Devs But A Little Empathy Should Be

27 September 2016
My friend Matthew Reinbold wrote a great post on his blog asking "what if developers aren't meant to do API design"? I think he is touching on an important aspect of why DevOps might not work everywhere in the same expected ways. We all have our strengths, and we all have our weaknesses, and I agree with him that maybe we are asking too much of our developers--API design might not be their strength.  As the owner of a small business operated by one person (me), DevOps is hard. I cannot do everything myself, and require a variety of services to help me out, but I still hit areas where I'm deficient like graphic design and editing. I'm getting better at editing, but my graphic design skills never seem to evolve at all...

Thanks For Reaching Out About Your API

27 September 2016
I get a number of folks emailing me about their API and API-focused services. When I have the bandwidth I spend time in my inbox and respond to these emails. To help me do this a little more efficiently (I'm not always very quick about it), I'm formalizing some snippets I can use in my response(s). I want to thank them for reaching out, while also helping them understand my approach to successfully operating API Evangelist. Here is one basic email I crafted today, in response to a pretty slick API provider that I will be writing about shortly: Hi There, I received your email. Thanks for the kind words. Appreciate you introducing me to your [API / API related service]. I'm going to have to pass on the posting of the [guest post, infographic, white paper, case study, etc] to apievangelist...

Taking Another Look At The Department Of Labor API Efforts

26 September 2016
Someone asked me about the current state of the Department of Labors (DOL) API efforts the other day, and since I hadn't actually taken a look in a few months I wanted to spend some time in there seeing what they have going on. There is no better way to get a feel for what a government agency is up to than going through their API efforts--the DOL is pretty ahead of the game in this area. The vibe when you land on developer.dol.gov (which is a great subdomain) is nice. It is clean and has all the links that I am looking for, providing access to their APIs, as well as supporting code, while allowing you to ask questions and report bugs. One thing I think is interesting in their approach is that they efficiently use Github in support of their code, apply Stack Exchange in support of asking questions, and employ Github issues for reporting bugs...

Helping Validate Data And Algorithmic Sovereignty At The API Layer

26 September 2016
I have showcased examples of API providers allowing you to deploy your API into various regions around the world like Algolia does, but it is a topic that I think will keep gaining traction as data, content, or algorithmic sovereignty continues to be a privacy, security, or regulatory concern. As the Internet continues to evolve, people and companies are only going to continue being concerned and dare I say become nationalistic about where they digital worlds exist and operate. When I Google "data sovereignty" I get: Data sovereignty is the concept that information which has been converted and stored in binary digital form is subject to the laws of the country in which it is located...

My API Definitions Are Incomplete But You Do Not Want To Contribute

26 September 2016
I am perpetually working to publish all of my API definitions my API Stack Github repository, with the front available as the API Stack. I regularly push the latest copies of all of my OpenAPI Specs to these Github repos when I have time, but my OpenAPI Specs are far from complete, and are something I'm always working to make as complete as a I can, and certify when possible. My primary objective around defining APIs using OpenAPI Spec is all about API discovery, and understanding the request and response surface area for many of the publicly available APIs out there today. Secondarily I'm interested in actually putting these API definitions to use across the API lifecycle in design, deployment, management, testing, virtualization, and client tools and services...

Doing Away With Self-Service API Access Without Approval Like SoundCloud

26 September 2016
SoundCloud recently made changes to the signup process for their API and are now requiring approval before any 3rd party developer can get an API key and access the API. While I encourage API providers to be as open and transparent with their API portal, documentation, and other resources, I honestly can't criticize API providers for locking down APIs and requiring approval--especially when 3rd party developers can be so badly behaved.  Modern API management solutions allow for API providers to decide how open they want to be with their APIs, and while there are many benefits for having an open presence for an API portal, documentation, and other resources, I predict that many API providers will require approval before you get full access to resources in the future...

API Service Providers Please Have A Logos Page Like dreamfactory

26 September 2016
I was adding dreamfactory as one of my sponsors today. I have them in my in my API monitoring system already, so I have a logo for them, but whenever there is a significant event involving one of the companies I keep an eye on in the API space, I tend to make sure I have an update to date version of their logo. In the case of adding them as a sponsor I definitely want the latest logo--so I did what I always do, I Googled "dreamfactory logo". A while back I wrote about how companies who ask me to update their logo on my site(s) almost never have a dedicated logo page--which might have helped make sure I have had the right logo in the first place.  So when I Googled the dreamfactory logo", I was pleased to find tthe dreamfactory logo page as the first result, with a wealth of logos for me to select from...

The Sharing Of Data Via APIs Will Be Key To Viability Of Every Industry

23 September 2016
As I'm processing some guidelines around the importance of sharing data in the cybersecurity.theater a story on NPR came on the radio about the importance of data sharing when it comes to the emerging self-driving car marketing. I do API Evangelist, not to encourage everyone to do APIs and be the next Twitter, it is to help everyone understand the important of sharing machine-readable information in a secure and accessible way, to make all industries healthier, secure, and more viable environments for digital transformation (man I hate that phrase). APIs are about sharing information in machine readable formats like YAML, JSON, and XML. Modern approaches to API deployment and management makes this information available in a self-service, secure way, ensuring those who should have access do, in a 24/7, always-on environment...

Learning From The Sunlight Foundation Situation And Baking Transparency Into Projects

23 September 2016
As I work through the APIs, and Github repositories of soon to be gone Sunlight Foundation, I wanted to take some more time to help open data and API efforts realize the important of real-time transparency and openness of their projects--specifically how Github can help contribute to this. I'm super stoked at the number of projects on Sunlight Lab's Github account, but after identifying the actual gaps between what is there and what is available in their APIs, I want to emphasize the importance of doing our work out in the open on Github when working on these types of projects. In short, it is really difficult to package up any project once the hammer comes down, and a company or individuals are moving on...

Identifying The Important Work From The @SunlightFoundation I Would Like To See Live On

23 September 2016
I am saddened to hear the news of the Sunlight Foundation dimming the lights on their important work around government transparency. They have provided me a constant spotlight on government activity, and provide a model for me when it comes to opening up government data, and providing APIs that can make a difference. Having helped run non-profit organizations, working to make social change, I know this can be a very difficult thing to keep above water. I have already reached out to the Sunlight foundation staff letting them know I'm here to help with any API related projects, and happy to fund their existence until I can find a suitable, caring adoption situations for them. First up, I wanted to make sure and go through their APIs, and make sure there is a current OpenAPI Specification snapshot for each one, in case they get shuttered: Capital Words API - The Capitol Words API is an API allowing access to the word frequency count data powering the Capitol Words project...

How To Discover No Name And Description Twitter Accounts For Folks In The Enterprise

23 September 2016
I am always fascinated by the online fence sitting persona that is the enterprise tech industry employee. I know many them are there, but few ever retweet my work, respond to my posts via comments, or other channels. Usually, I only know that many of them are there from the occasional like on one of my stories, but I'm slowly developing other ways to build lists of Twitter users from behind the enterprise fence. One of the best ways to root them out is to write positive stories about their company, products, group, or their flagship clients. When you do this many of the no names, no description Twitter accounts for the enterprise fence sitters will come out of the woodworks. They can't help themselves it seems, when someone writes positively about what they are doing, as many are so starved for genuine praise, they will often retweet a story revealing themselves...

Decoupling The Solution Provided From The Product In Your Storytelling

23 September 2016
I come across a number of really useful stories about APIs in my regular monitoring of the space that can't seem to separate the solution their product delivers from the product itself. I get that you want people to know that your product does the really useful thing that you are telling the story about, but I want to help you understand that they are most likely turning people off to the solution by tightly coupling the solution story with your product and company.  This type of storytelling is more sales than it is evangelism. It shows you don't really have a good product in my opinion. If you can't talk endless about what your product accomplishes without mentioning the product name or the company behind, you probably don't have much of a thing in the first place...

Google Spreadsheets As An Engine For API Goodness

22 September 2016
I was watching my partner in crime Audrey Watters (@audreywatters) build the weaponized edu Twitter bot using a Google Spreadsheet as an engine. Something she learned from Zach Whalen, a professor at University of Mary Washington. Audrey is not a programmer, but she has become extremely proficient at building these little bots, and using the Twitter API--demonstrating the potential of Google Sheets as an engine for an API-driven bot solutions, or in this case bot mayhem. Zach's approach is extremely well defined--you will have to copy and go through the spreadsheet yourself to see. Everything you need to get the job done is there, from step by step instructions, to storing your API tokens, and planting the seeds for your bot intelligence...

API Branding Embeddables That Can Boost My API Rate Limits

22 September 2016
I'm expanding on my API branding research, putting some thought into how we might be able to include branding and attribution in API responses. Next, I'd like to brainstorm ways to incentivize both API providers, as well as API consumers to employ sensible branding practices. You'd think API providers would be all over this stuff, but for some reason, they seem to need as much encouragement, and structure as API consumers do--this is why I'm wanting to explore how I can drive both sides. First, why do I care about branding when it comes to APIs? Well, the more successful companies are with their APIs, the more their companies brand can be not just protected, but enhanced--the more APIs are seen in a positive light, rather than the threat to brand control that is often cast on them...

The Why Behind The Github GraphQL API

22 September 2016
I wrote a skeptical piece the other day about GraphQL, which I followed up with another post saying I would keep an open mind. I've added GraphQL to my regular monitoring of the space, but I don't have its own research area yet, but if the conversation keeps expanding I will. A recent expansion in the GraphQL conversation for me was Github releasing the GitHub GraphQL API. In the release blog post, from Github they provide exactly what I'm looking for in the GraphQL conversation--the reasons why they chose to start supporting GraphQL. In their post Github describes some of the challenges API consumers were having with the existing API, which led them down the GraphQL path: sometimes required two or three separate calls to assemble a complete view of a resource responses simultaneously sent too many data and didn’t include data that consumers needed They also talk about some of what they wanted to accomplish: wanted to identify the OAuth scopes required for each endpoint wanted to be smarter about how our resources were paginated wanted assurances of type-safety for user-supplied parameters wanted to generate documentation from our code wanted to generate clients Github says they "studied a variety of API specifications built to make some of this easier, but we found that none of the standards totally matched our requirements" and felt that "GraphQL represents a massive leap forward for API development...

Syndicating API Evangelist Posts To Medium Using Their API

22 September 2016
Now that I have API Evangelist up to regular levels of operation after a summer break, I'm working to expand where I publish my content, and next up on the list is Medium. Like many other popular destinations I refuse to completely depend on Medium for my blogging presence, but I recognize the network effects, and I'm more than happy to syndicate my work there.  To help me manage the publishing of my stories to Medium I wired up the Medium API into my API monitoring and publishing platform. I use the Github API to publish blog posts to API Evangelist, Kin Lane, and API.Report, and it is pretty easy to add a layer that will publish select stories to Medium as well. All I have to do is tag posts in a certain way, and my "scheduler" and the Medium API does the rest...

Providing Branding And Attribution Assets With Each API Response

22 September 2016
I am tracking on the approaches of API providers who have branding world together when it comes to platform operations. I'm always surprised at how few API providers actually have anything regarding branding in place, especially when it seems like loss of brand control, attribution, and other concerns seem to be at the top of everyone's list. I was hooking up the Medium API to my API monitoring and publishing system, syndicating select stories of mine to the platform and found myself thinking about how important an API branding strategy is (should be) to content platforms like them. Medium doesn't let you pull posts via the API (yet), but if it did, I would make sure branding and attribution was default...

A New API Programming Language SDK Icon Set

21 September 2016
I was working on a forkable definition of my API portal and I wanted to evolve the icons that I usually use as part of my API storytelling. I primarily use the Noun Project API, to associate simple black and white icons which represent the stories I tell, companies I showcase, and topics I cover. One area I find the Noun Project deficient is when it comes to icons for specific technologies, so while working on my project I wanted to find a new source. I fired up the Googles and got to work. I quickly came across Devicon, a set of icons representing programming languages, designing & development tools which you can use as a font or with SVG code. At the Github repo for the project, it says they have 78 icons with over 200 versions total...

Be Part Of Your Community, Do Not Just Sell To It

21 September 2016
A recent story from Gordon Wintrob (@gwintrob) about how Twilio's distributed team solves developerevangelism has given me a variety of seeds for stories on API Evangelist this week. I love that in 2016, even after an IPO, I am still writing positive things about Twilio and showcasing them as an example for other API providers to emulate. Twilio just gets APIs, and they deeply understand how to effectively build a community of passionate developers, demonstrated by this statement from Gordon's story on developing credibility: How do you have technical credibility? You have to really be part of your programming community. Each of us is a member of our community, not marketing or trying to sell to it...

The PSA Peugeot Citroën’s APIs

21 September 2016
I was turned on to the API program out of Groupe PSA,  the French multinational manufacturer of automobiles and motorcycles sold under the Peugeot, Citroën and DS Automobiles brands from a friend online the other day. Rarely do I just generally showcase an API provider, but I think their approach is simple, clean, and a nice start for a major automobile brand, and worthwhile to take note of.  Companies of all shapes are doing APIs, but very few have the awareness to make their API program public, and accessible to the general public. I think the PSA Peugeot Citroën’s APIs are a pretty interesting set of resources for making available to car owners, and worth talking about: Telemetry - Request data from the car: average speed, location, instantaneous consumption, engine speed, etc...

What I Mean When I Say API

21 September 2016
People love to tell me the limitations of my usage of the acronym API. They like to point out they were around before the web, that they are used in hardware, or are not an API unless it is REST. There are endless waves of dudes who like to tell me what I mean when I say API. To help counter-balance each wave I like to regularly evolve, and share what I mean when I say API--not what people might interpret I mean. When I say API, I am talking about exposing data, content, or algorithm as an interface for programmatic use in other applications via web technology. Application in "Application Programming Interface" means any "application" to me, not just a software application. Consider visualizations, image rendering, bots, devices, or any other way that web technology is being applied in 2016...

A Trusted Github Authentication Layer For API Management

20 September 2016
I am reworking the management layer for my APIs. For the last couple of years, I had aspirations of running my APIs with a retail layer generating revenue for API Evangelist--something which required a more comprehensive API management layer. In 2016, I'm not really interested in generating revenue from the APIs I operate, I'm just looking to put them to work in my own business, and if others want access I'm happy to open things up and broker some volume deals. To accomplish this I really do not need heavy security or service composition for my APIs, I'm just needed to limit who has access so they aren't just 100% public, and identify those who are using, and how much they are actually consuming...

Standards Evangelism

20 September 2016
As the API Evangelist, I spend a lot of time thinking about evangelism (*your mind is blown*). TFrom what I'm seeing, the world of technology evangelism has been expanding, where database, container, and other types of platforms are borrowing the approaches proven by API pioneers like Amazon and Twilio. As I'm doing work with Erik Wilde (@dret) around his Webconcepts.info work, and reading an article about industrial automation standards, I'm left thinking about how important evangelism is going to be for standards and specifications. Standards are super important, so I have to be frank--the community tends to suck at evangelizing itself, in an accessible way that reflects the success established in the API world...

I Am Feeling The Same About YAML As I Did With JSON A Decade Ago

20 September 2016
I have been slowly evolving the data core of each of my research projects from JSON to YAML. I'm still providing JSON, and even XML, Atom, CSV, and other machine-readable representations as part of my research, but the core of each project, which lives in the Jekyll _data folder are all YAML moving forward.  When I first started using YAML I didn't much care for it. When the OpenAPI Specification introduced the YAML version, in addition to the JSON version, I wasn't all that impressed. It felt like the early days of JSON back in 2008 when I was making the switch from primarily XML to a more JSON-friendly environment. It took me a while to like JSON because I really liked my XML--now it is taking me a while to like YAML because I really like my JSON...

D3.js Visualizations Using YAML and Jekyll

20 September 2016
I am increasingly using D3.js as part of my storytelling process. Since all my websites run using Jekyll, and published entirely using Github repositories wich are shared as Github Page sites, it makes sense to standardize how I publish my visualizations. Jekyll provides a wealth of data management tools, including the ability to manage YAML dta stores in the _data folder. An approach I feel is not very well understand, and lacks real world examples regarding how to use when managing open data--I am looking to change that. I like my data visualizations beautiful, dynamic, with the data right behind--making D3.js the obvious choice. For this work, I took data intended for use as a bar and pie chart and published as YAML to this Github repositories _data folder...

Why Would You Build A Business On APIs? They Are Unreliable!

20 September 2016
People love to tell me how unreliable APIs are, while also echoing this sentiment across the tech blogosphere. I always find it challenging to reconcile how the entrenreurs who spread these tales choose to put the blame on the technology, and not the companies behind the technology, or more appropriately the investment behind the companies. APIs are just a reflection of what is going on already within a company, and are good, nor bad--they are just a tool that can be implemented well, or not so well. I was taking some time this last week to work on my API monitoring system, which I call Laneworks. In addition to having my own API stack, I depend on a variety of other APIs to operate my business...

Putting The Concept Of The Public API To Rest As A Dominant Narrative

19 September 2016
APIs come in all different shapes and sizes. I focus on a specific type of APIs that leverage web technology for making data, content, and algorithms available over the Internet. While these APIs are available on the open Internet, who has the ability to discover, and put them to use will vary significantly. APIs have gained in popularity because of successful publicly available APIs like Twitter and Twilio, something that has contributed to these types of APIs being the dominant narrative of what APIs are. A lack of awareness of what modern approaches to API management can do for securing web APIs as well as the dominance of this narrative that APIs need to be open like Twitter and Twilio tends to set the bar to unrealistic levels for API providers...

A Twilio Process To Emulate Within Your Own API Operations

19 September 2016
Leading API providers do not always make me happy with they way they conduct themselves, but it always makes me smile that one of the top API providers consistently over the last five years, continues to do things right, and set a good example that I can write about. I am not delusional to think that everything is perfect behind the Twilio curtain, but a story from Gordon Wintrob (@gwintrob) about how Twilio's distributed team solves developer evangelism leaves me hopeful (once again) about the potential of APIs. There are several gems in this post, but one of them that stood out for me, and I think reflects the API potential which more companies should be emulating, is about how Twilio designs, develops and evolves new APIs...

Providing YAML driven XML, JSON, and Atom using Jekyll And Github

19 September 2016
The power of Jekyll on Github Pages as a data management solutions is not a very widely held concept. I'm always amazed at how technologists and programmers don't understand Jekyll, let alone how it can be used as a data engine--maybe I can help a little by sharing my own usage. As I develop examples of this in action, I want to publish them as Github repositories that anyone can fork and reverse engineer to use in their own work. While it was not love at first sight for me, I'm increasingly becoming a fan of using YAML for storing and managing a significant portion of the data I use across my business. Part of the reasons I'm using YAML is its readability. The other reasons stem from the augmented benefits of using Jekyll and Github Pages to store and syndicate machine readable YAML for use across my storytelling--when you put YAML data into the _data folder for any Jekyll site, it opens up a new world of possibilities...

My Dream API Sketchbook And Portfolio

19 September 2016
I have a vision of an API notebook in my head I desperately want to get out. First of all, I want to come up with another name for it, which is a journey that always starts with playing around with synonyms. Direct synonyms of notebook include a diary, journal, log, workbook, pad, and binder-yes, all of that is relevant to what I would like to see. After that, a few other words resonated, including album, collection, portfolio, and registry. This isn't just a folder to put my API definitions. It will be the place where I go to find all the definitions of 3rd party API which I depend on, as well as the APIs I'm designing, deploying, and operating as part of my own business. I want to be able to just record ideas, sketches, and thoughts I have as I'm thinking about APIs...

My Forkable Minimum API Portal Definition

19 September 2016
I am updating my minimum API portal definition so I can apply to my own API infrastructure, and since I operate 100% on Github using Github Page and Jekyll, I have made it a forkable API portal definition that anyone can put to work as their own API developer portal. This edition of my API portal definition uses Bootstrap for its UI, and Jekyll for the CMS, making it pretty extensible, and remixable once you fork it on Github. My goal was to make a simple, forkable API portal, that could act as a checklist for API providers looking to quickly set up a presence for their API. I know many companies, institutions, and government agencies do not have the resources to host one, let alone the time to pay attention to all the details--that is my job! To help API providers out, I have included what I feel is a complete API portal in the _config...

Learning From The Success Of Swagger UI

16 September 2016
I feel like we haven't really sat down and studied the success of Swagger UI. I'm not talking about the OpenAPI Spec (fka Swagger Spec), I am only talking about the interactive API documentation that you can find on Github. Aside from the shitshow that was the movement of Swagger to be OpenSpec API, I'm thinking there are some lessons available around just the interactive API documentation itself. First, we have to acknowledge that many people think Swagger is the documentation, and do not understand the separate nature of the specification, and the UI layer that is meant to be API documentation, and used within API tooling like the Swagger Editor. While there are numerous benefits realized from the concept of the OpenAPI Spec, the number one reason people implement is to deploy the interactive API documentation...

Standardizing API Documentation For Use Across The API Lifecycle

16 September 2016
I've been pushing for better API design tooling for some time now, something that significantly overlaps with movements I would also like to see around API documentation as well. In my opinion, we have made significant strides with the introduction of Swagger UI, as well as pushed the API documentation conversation to be part of the API design process by Apiary. This is something that was further re-enforced with the evolution of Swagger UI to be part of the Swagger Editor toolkit--where Swagger UI was used in real-time as part of the API design process, not just later down the road as API documentation for consumers. This demonstrates for me the importance of API documentation, not just in helping API consumers understand what an API does at integration time, but also for API providers at design, mock, test, and any other time during the API lifecycle...

A Look At The State Of API Documentation Solutions

16 September 2016
A friend of mine was asking where he should get started with upgrading the documentation for an existing API, and was asking for assistance on what tools or services he should be considering. The state of things when it comes to API document shifts and changes, which is why I do my research the way I do, to ensure I have a single static location I can go find the latest for my research in API documentation, when I get questions like this. Discussing API documentation like many aspects of the API conversation can be difficult, due to a wide range of views on exactly what is API documentation. Some people consider the entire API portal, including the documentation, some include other code libraries, etc, but I define it as specific documentation describing the API surface area (auth & request / response)...

Now Keeping An Eye On 66 Areas Of The API Lifecycle

15 September 2016
As I was firing back up API Evangelist after a break this summer, I took the opportunity to add in a couple of new areas to my research, that I've had sitting on the backburner, bringing the number of areas of my API lifecycle research up to 66. Each area operates as an independent Github repository, possessing the JSON, YAML, and HTML for each area of my API industry monitoring, research, and storytelling. I approach my work this way because the individual repositories allow me to put my blinders on when it comes to each project, while also scaling my work to include as many possible areas that influence what we like to call the API economy. Not all areas are as mature as API management, which has been being defined for well over a decade, but each area plays its own significant role that in my mind makes it worthy enough to be its own separate project...

The Next API Lifecycle Opportunity Will Be In Design And Definitions

15 September 2016
Looking through the numbers for my API Evangelist research, and tallying up what I've learned along the way, I feel like the next opportunity out there will be about API design and definitions. The release of the API Stylebook, and Materia reflect this opportunity--serving the growing appetite for API design knowledge, and tooling being generated as businesses continue waking up to the need for APIs. The API management landscape has been well defined by pioneers like 3Scale and Apigee, and validated by their acquisitions by Red Hat and Google this summer. What is picking up momentum now, is the world of API design services, tooling, and specification set into motion by early pioneers of API design like Apiary...

If You Have An Online Product Catalog You Should Have An API

15 September 2016
Octopart is the products company that I regularly use as a reference for how product-focused companies should be doing APIs. Octopart's is an electronic parts company who have a physical, product centered company which is easy for people to understand, that also happens to do APIs well. Octopart doesn't do APIs just because they are cool, they do APIs because it enables the purchasing of their products in other systems. When you land on the Octopart website you are given a product catalog search, allowing humans to browse their virtual electronic parts warehouse, but as soon as you scroll below the fold you also see a link to their API. The Octopart API is nothing fancy, but it has all the essentials, including a simple REST API for accessing /brands, /categories, /parts, and /sellers in their virtual electronic parts warehouse...

Harvesting Companies Who Are Doing APIs From Press Releases

14 September 2016
Press releases continue to be one of the best ways for me to discover companies who have embarked on their API journey. From what I can tell, even with the shrinkage around funding for startups, the number companies offering up APIs is increasing. The big difference in the current wave of companies doing APIs. is these are just regular businesses, using APIs to provide access to resources in web, mobile, device, and partner integrations--a more business usage of APIs, as opposed to startups where the product is an API. This class of SMB, and SME API provider tend not to be so good at sharing the documentation, code, and other resources for their API operations via their sites, but do see the value in pointing it out when issuing a press release...

Sharing Some Basic Numbers For API Evangelist

14 September 2016
I don't spend a lot of time worrying about the website traffic numbers for API Evangelist. Once a week I'll take a look at my Google Analytics or CloudFlare dashboards. I don't write for page views, but I do like to know which of my areas of research is of interest to the public, and generally what people are clicking on. To help me visit my numbers each week, I started publishing them to the API Evangelist repo, and sharing via a new numbers section on the site.  I wanted to start with seeing the page views across all of my API research projects, giving me an idea of the interest levels in each area: Next, I wanted to see the page views that each guide or white paper was getting in the top left corner of my site: After the views, I wanted to get a better understanding of what people were clicking on when it came to these guides & white papers: I also wanted to see which of the sponsor logos I include on the left-hand navigation were being clicked on by my readers: Numbers do not drive what I do...

Building The Case For Redefining The Mortgage Industry Using APIs

14 September 2016
I am trying to get better at showcasing the early stories I find about APIs making their moves into new industries. It helps to have a post to reference when I add an area as an official research project, and begin tracking on companies more closely in the industry. I'm sure I've seen mortgage-related API rhetoric before, but a post in the National Mortgage News, provides a pretty clear mark in the sand to begin building the case for redefining the mortgage industry using APIs. The description of the mortgage industry sounds like other industries where many disparate systems and players exist, with a minefield of technical, business, and politic considerations littering the landscape...

Tracking On Where The Politics Of APIs Intersects With The Business of APis

14 September 2016
While reviewing the details of Twilio's new enterprise plan, the one thing that stood out for me was the strong emphasis of the security and legal elements within this level of business integration. I've talked out security being included as part of plan details before, and is something I will keep talking about as leading providers continue to bring it front and center as part of API plans and operations. Advanced security is the focal point for Twilio's new enterprise plan, providing audit events, and public key client validation, but shortly after showcasing these security features, the next section is all about providing finer grain access management including customizable role-based access control (RBAC), and Single Sing-On (SSO)...

An API Data Retention Policy And Paying for Longer Storage

14 September 2016
I was reading the rules of retention, and how long does Bronto save data. Their clarity around offering a data retention policy grabbed my attention, but I also found the ability to pay for longer storage, increasing data retention worth highlighting as well. If longer storage is an option for inclusion in API plans, it might also make sense to charge for shorter periods? IDK--maybe pay for something to go away sooner, with a shorter overall time to live (TTL). Before I can see the Bronto data retention policy I have to create an account, so it won't happen today. I will make sure and get in there to document the moving parts of their policy as I am curious how much detail they get into...

API Providers Partnering To Provide A Developer Business Incubator

13 September 2016
Building on my earlier coverage of how API providers are investing in their API community like Amazon and Slack, I wanted to document the incubator over at Box. Acknowledging that "the enterprise applications of the future will be cloud-based and massively scalable", and to "support the development of these applications, Box Platform and Amazon Web Services are teaming up to provide you with everything you need to build and scale your business." Providing yet with another (AWS-powered) partnership and API community investment blueprint to put on the shelf. Examples like this are why I kicked off my API partner research but also reflects why I expanded to keep an eye on investment that is occurring in the space...

API Infrastructure To Help Your 3rd Party Developers Be More Efficient

13 September 2016
One of the popular narratives for why companies should be doing APIs emerged out of the last couple waves of startup investments, which encouraged investment in public APIs so that developers could build the next big web or mobile app (if you build it they will come). This narrative proved to not be true for many APIs, leaving API providers often feeling unsuccessful. The API providers like Netflix who were able to evolve and iterate until they found success with their APIs are the examples we should be following, not a single narrative around public API access. Netflix talks about their API, and open sources their API technology to attract the attention of developer talent. This is just one of many reasons why companies are doing APIs in 2016, a subject I want to contribute to through brainstorming about "what is API success"...

If An Algorithm Impacts Our Life It Should Be Opened Up With An API For Auditing

13 September 2016
As I was reading artificial intelligence is hard to see by Kate Crawford (@katecrawford), my brain once again begins crunching the different ways APIs can be applied to help us "see" the algorithms evolving around us. API all by themselves do not move things forward much, but when you combine with modern approaches to applying API definitions, introduce the access and authentication benefits of OAuth, employ sensible and robust logging practices, and work to develop API driven visualization layers for algorithms--I'm thinking we can really begin to move the conversation forward. Defining the Algorithmic Surface Area With An API And API DefinitionLeading API specifications formats like OpenAPI Spec and API Blueprint are allowing API providers and architects to define the request and response model for web APIs...

The General Bikeshare Feed Specification

13 September 2016
I came across a story about Stage Intelligence Adds Support for the GBFS Open Data Standard in my regular monitoring, and wanted to add the specification to my API definition toolbox, and share here on my blog. Staritng with the basics, what is the GBFS Open Data Standard? General Bikeshare Feed Specification, known as GBFS, is the open data standard for bikeshare. GBFS will make real-time data feeds publicly available online in a uniform format so that map and transportation based apps can easily incorporate this data into their platforms. Documentation is available on Github, including JSON definitions for the bikeshare data model. All it needs now is an OpenAPI Spec generated for it, providing one possible API definition for the GBFS specification (you know you want to build it)...

Adding To The Available Branding Resources For API Developers

13 September 2016
Spotify recently updated the available design resources and branding guidelines including their logos, icons and colors in their developer portal. I'm a big fan when any company has a dedicated page driving their API branding strategy, as it makes it easy for me to find logos, and understand how a company wants to be presented in my stories.  Spotify provides a range of design resources including logos, icons, display rules, minimum size, logo misuse, colors, fonts, and restrictions--all elements I'll consider adding as branding building blocks for API providers. I also thought that Spotify's quick description of their design resources is worthy of showcasing: Welcome to our hub for partner guidelines and assets...

Considering How APIs Are Influencing The Fundamentals of Software Engineering

13 September 2016

Where Is The Deploy To AWS and Google Button?

12 September 2016
I was playing around Prose.io's Gatekeep solution, a proxy for enabling the client-side application dance OAuth with GitHub. I tend to use Oauth.io for all of my oAuth dancing, especially client-side on Github Pages, but for the current application I am working on, I wanted a server-side proxy where I could work some other magic--which led me playing with Prose's Gateway. When you scroll down the page for the oAuth gateway, you'll find two deploy buttons, one for Heroku, and one for Azure--I want all APIs, and all API solutions that support API operations (like Prose's Gateway) to be deployed like this.  True open API solutions should operate this way, offering up server-side solutions in a Github repository, with one-click buttons for deploying in your infrastructure of choice...

Google Acquired Apigee

12 September 2016
The news came in late last week that Google was acquiring API management pioneer Apigee. The news caught me by surprise. I thought if there was still going to be an acquisition of Apigee that it would come from their flagship client AT&T or from other giants like IBM. While it was surprising, seconds after hearing it, the acquisition made total sense, and I think it just reflects the increased usage of APIs by businesses of all shapes and sizes. As I wrote about last week, we are entering a very boring and business age of APIs. My point is not that it will all be boring (as some of Twitter folks responded without reading), it is that it will be too boring for the Silicon Valley hype machine...

The New API Design And Deployment Solution Materia Is Pretty Slick

12 September 2016
I was playing with a new API design and deployment solution, from some of my favorite developers out there this weekend called Materia, which bills itself as "a modern development environment to build advanced mobile and web applications"--I would add, "with an API heart". Materia is slick. it is modern. While very simple, it is also very complete--allowing you to define your underlying data model or entities, design and deploy APIs, and then publish a single page applications (SPA) for use on the web, or mobile devices. Even though I'm one of those back to land, hand-crafted API folks, I could see myself using Materia to quickly design and deploy APIs.  I say this in the most positive light imaginable, but Materia reminds me of the Microsoft Access for APIs...

Considering The Hypothesis API Approach When Expanding The API Life Cycle Discussion

12 September 2016
I have been playing around with different ways to craft a web concepts and specification JavaScript library for API providers, and one of the approaches I've been considering is out of the annotation platform Hypothes.is. Their "mission is to bring a new layer to the web" allowing anyone to "discuss, collaborate, organize your research, or take personal notes"--while I'm looking to bring a new layer to the world of APIs, allowing API providers to weave in important web concepts and specifications across their API portals and documentation. Hypothes.is has a simple API, allowing you to search, read, create, update, and delete annotations on any HTML page available at a public URL. This is exactly what I'd like to see done for any OpenAPI Spec JSON files, with my earlier APIs...

API Stylebook: A Collections Of Resources For API Designers

12 September 2016
My friend Arnaud Lauret (@arno_di_loreto), the API Handyman, has released a very cool new project called the API Stylebook--a collections of resources for API designers. It is a brilliant aggregation of twelve API design guides from Atlassian, Cisco, Cloud Foundry, Haufe, Heroku, Microsoft, PayPal, Red Hat, The White House, Zalando. I think the API Stylebook purpose describes it well: The API Stylebook aims to help API Designers to solve API design matters and build their API design guidelines by providing quick and easy access to selected and categorized resources.In this first version, the API Stylebook provides direct links to specific topics within publicly available API Design Guidelines...

Prepare For The More Boring And Very Business Age of APIs

09 September 2016
I just went through all the APIs in my monitoring system looking for a diverse set of them to showcase in an API economy story I'm working on, and while I can point to some pretty exciting milestones along the history of APIs, I predict the future will be very boring. Think about the web between the first dot.com bubble burst and the web 2.0 years, that kind of boring--less money going around, but everybody is doing it. While looking through APIs there are so many robust, powerful, yet very yawn-worthy APIs in my book when it comes to accounting, marking, sales, and advertising. There are slow moving, the universe expanding API offerings coming out of mapping, satellite, and drone APIs. Banking, healthcare, insurance, and other similar areas are steadily talking about the benefits of APIs...

Everything Is Fragile In The World Of APIs

09 September 2016
I was working through some thoughts around programming language dependencies, looking through a service I came across called Bundler, and found myself thinking about API dependencies (go figure, man I have a problem), and the reliability of the APIs we are building on top of. Anyways, when it comes to the latest trends in programming languages in a production environment, I'm out of the mainstream current, and when I'm in over my head like this I usually turn to my API Evangelist Slack group for answers. I asked the group for any random thoughts about programming language dependencies vs. API dependencies. There weren't that many thoughts, except a single profound one from the king of making sure everything is 200 OK, John Sheehan (@johnsheehan)--who said: Everything is fragile! Deep shit, and so very true...

Providing Video Walk Throughs On Youtube For Your API or API Provider Services

09 September 2016
I like Postman's approach to using Youtube for providing walk-through's for specific actions users will want to take in their API client service. All of their video walk-throughs are very simple, straightforward, and seem to speak to specific things that users are going to want to tackle when design, developing, or even integrating with an API. Another thing I wanted to highlight, is that I came across Postman's Youtube Account because I saw @postmanclient tweet a link in response to a specific question, from a user about a specific need they had. This demonstrates for me, the importance of weaving video walk-throughs with your regular feedback loop and FAQ's, making sure you have video answers to the things your users are most asking about most--a great way to scale your support, while also increasing your SEO and SMM reach...

Regex Suggestion Discovery For Web Concepts And Specs During API Design Time

09 September 2016
I am working on taking the JSON feed of web concepts and specs and developing a simple website JavaScript tooltip library that API providers can employ to inject web literacy into their API developer portals and documentation. I have settled in on using an existing JavaScript tooltip library for the core functionality and have put some thought into a basic dictionary lookup that can be used in web and API literacy tooling. As I was brainstorming on what is possible within a basic dictionary which could be used to map specific keywords and phrases to the web concepts and specs that Erik Wilde (@dret) has showcased in his webconcepts.info work, it occurred to me that there should also be a regex layer to this dictionary lookup...

We Better Get To Work On Evolving An Open Emergency Response API Stack

09 September 2016
As I listened to the news about flooding coming out of Louisiana, and the impending hurricane headed up the east coast, I'm momentarily distracted from my monitoring of the API space. As I switch back to my work, I can't help but think about the stack of open APIs we will need to tackle future disasters (global climate change). No, APIs are not the silver bullet solution, but if the networking, storage, database, messaging, and any other gear in the disaster relief machine had a wealth available open API definitions, and open source software--the disaster relief machine could potentially be more efficient, scalable, and decentralized. I'm not even sure what the current emergency response stack looks like, something I'm sure looks very different at the municipal, county, state, and federal levels...

When Working With Our API Make Sure You Build Fault-Resistance Into Your Code

08 September 2016
As I was working my way through the USGS water services APIs, I came across their page for writing fault-resistant code. There are many things going on in the USGS developer portal I think are worth talking about, and the reminder for developers to write more resilient code is one that I feel needs constant discussion, from many different angles. I know that this is one area I will get comments about hypermedia as a solution, but for right now I want to think through what is coming out of existing API efforts on the ground like USGS. The USGS provides 13 separate pieces of advice to help you achieve more fault-tolerant code as you integrate with their water APIs: Join the Water Data System Notification Service Check HTTP error codes If your application is server-based, acquire data in XML if the format exists If your application is browser-based or client-based (such as a native app), acquire data in the JSON format if available If a service offers a version number, request that version of the service Write your queries efficiently Why you should avoid tab-delimited (RDB) files Parse XML using an XML parser Use standard libraries Consider using curl or wget to acquire data Use scheduled tasks to automate data collection Guidance on how often you should fetch data I am not sure all of these apply universally, but I like the idea of API providers sharing their view of how developers can write better code when integrating with their APIs, based on their own experiences...

A Dictionary To Lookup Web Concepts And Specs For The JavaScript Tooltip

08 September 2016
I am working on taking the JSON feed of web concepts and specs and developing a simple website JavaScript tooltip library that API providers can employ to inject web literacy into their API developer portals and documentation. I have settled in on using an existing JavaScript tooltip library for the functionality but I needed to brainstorm what I'd like to see as the dictionary lookup for web and API literacy tooling. First, I want the JavaScript library to be able to copy and paste into an API developer portal HTML header and just work. By default, it should spider the body, look for any words that are already in the web concepts and specs JSON feeds provided by Erik Wilde's (@dret) webconcepts...

Are You Being Transparent With Your API Infrastructure To Attract Top Talent Like Netflix Is

08 September 2016
I consider Netflix to be the most successful API failure ever. Even though their public is completely private, exclusively for internal and partner uses, they are still very transparent and open with how they operate and open up the code behind. The reason behind this is simple, and self-serving, but is one that I can get behind 100%--making sure they are hiring the best developer talent, that reflects the company culture. You see always see these motivations present in the closing paragraphs of their blog posts: "If you are interested in helping us tackle this and other equally interesting challenges, come join us! We are hiring for several different roles." I've also had this discussion with Daniel Jacobson (@daniel_jacobson), the VP of Edge Engineering at Netflix (responsible for API and Playback), where he was pretty clear about preferring the type of developer who isn't afraid that the story of what their building will be public on the blog, and their code published openly to Github...

When The Latest Tech Bullshit Has Me Down I Will Work On Water APIs

08 September 2016
I come across a lot of really bad ideas for startups and APIs, as well as many badly behaved companies with great API implementations. With so much money flowing around space, the incentives for behaving badly have increased, and it seems like people's appetite for it, and willingness to even defend it, seems to only grow. When I come across this activity, historically I allow my feathers to get pretty ruffled, but going forward I'm trying to adapt and evolve in different ways. As I work to dial in my "real time" for maximum efficiency, and acknowledge that real time is often in service of what "they" want and not what I want, I'm finding new ways to respond the stupidity in the space--one that is healthier for me, and minimizes my service to the machine...

Defining API Surface Area By Converting HTML Forms To Open API Specs

08 September 2016
I'm investing some time learning about the USGS Water Services. They have some pretty interesting APIs, providing access to a wealth of data about water table levels, river flows, and other key points across all USGS sites. While their developer area has a wealth of information available, it is also pretty verbose and tough to absorb. I wanted to help make the information more accessible, filterable, and remixable by turning it into an OpenAPI Spec. It is A LOT OF WORK to craft a complete OpenAPI Spec for a robust API like the six that are available from the USGS. One way I help alleviate this work is to scrape API documentation. As I was preparing to do this I noticed they also have testing tools for 5 out of the 6 APIs, which are just HTML forms containing a definition of the surface area for each API...

Just Because The Enterprise Will Never Get APIs Does Not Mean You Should Not Try

07 September 2016
The response on Twitter and via email to my post about how the enterprise does not know(care) how big and destructive it is to APIs, is usual to this type of post, which I usually write about every six months to shake the enterprise trees. My enterprise readers rarely ever favorite or share posts, and engage in conversation on social media, and writing the occasional anti-enterprise posts is a sort of roll call for some of them--who I would never know exist unless I ruffle their feathers (thanks for sharing your thoughts).  I strongly believe that the enterprise (machine) does not care about APIs, but this doesn't mean that the enterprise (individual) does not care about APIs, and can't find meaningful success by employing APIs...

A Web Concepts And Specifications JavaScript Library For API Providers

07 September 2016
One of the prototypes I am going to build on top of Erik Wilde's (@dret) WebConcepts.info work, is a simple JavaScript library that you can embed on any API documentation page, and point at the body, or any other element on the page and it will find and replace any keywords or phrases with popup  showing a definition, with a link to Erik's work and the standard(s) home page.  I'm reminded of the need for something like this as I'm looking through the USGS Water Services site. There are little web literacy nuggets all over the documentation for the USGS's six APIs, and I'd like to see this approach get standardized by building on Erik's work to make web concepts and specs for accessible to API designers and developers, in a consistent way...

The Netflix Public API Was The Most Successful API Failure Ever

07 September 2016
I have written about the continuing Netflix API story over the years, which despite shuttering their public API, is an API effort that just keeps giving to the public. It is an API story that better reflects the reality of APIs, not the bullshit version you often get from the tech sector, and in my opinion is the most successful public API failure of all times--definitely one of the API stories I'll catalog in my history of APIs. Netflix's recent story about the engineering trade-offs and the Netflix API re-architecture was just the latest reminder of how transparent Netflix is with their API operations, even though they do not have a public API--shifting the traditional discussions around open vs...

The Burden On API Providers When It Comes To Web Literacy

07 September 2016
I am working through the USGS water data services, which include some REST APIs, and investing some of my work hours to one of my passions and concerns--water data and APIs. There is a wealth of water data available via the federal government web services, and as I'm making my way through the materials, I'm reminded of the heavy burden on API providers when it comes to web literacy.  The USGS water services APIs documentation are about 30% education about common web concepts, and specifications like gzip, CORS, ISO-8601 Duration format, SO-8601 Date format, what is JavaScript Object Notation (JSON), and much more. I see this approach often with API efforts that offer both REST and SOAP services, where the education of developers around key web concepts is much more necessary, but it also depends on how much the API providers actually care about their developers being literate--I guess USGS cares more than many other more commercial providers...

Using The Phrase Open API In Patents Shows How Broken Patents Are In A Digital World

07 September 2016
I am spending a lot of time reviewing patents that mention application programming interface or API in their title, abstract, or in the detail of the patent. Many of the patents lightly reference providing or consuming of APIs, but there are some of them that are directly looking to patent the API itself--which in my opinion just shows how broken the concept of the patent is when applied in a digital world. One patent that stood out in my reading this week was patent #EP20120170800 for "open API video system and method of making and using same"--which is: A video player unit, system and method, and a video hierarchy. Included are at least one memory device, a plurality of communication access points for receiving at least one program play, an open application programming interface associated with the at least one memory device, wherein a plurality ofapplications correspondent to the open application programming interface allow a user to manipulate metadata associated with ones of the programs plays, wherein the metadata relates to interframe interactivity with detailed aspects ofthe ones of the program plays, and at least one correlation engine in communication with the open application programming interface, wherein the at least one correlation engine provides for correlation among at least for the interframes of the program play to ones of the interframes of other ones of the program plays...

A JSON Feed Of Critical Web Concepts To Integrate Into API Design Service And Tooling

06 September 2016
I created a JSON feed of the web concepts and specs over at Erik Wilde's (@dret) site WebConcepts.info, so that I could easily import the specs into my Twitter and LinkedIn scheduling tools. I want to be able to schedule a tweet a day until I've exhausted all of the critical web concepts and supporting specs that Erik is showcasing in his work. Digital literacy, when it comes to these concepts, and proficiency at applying the specifications across the APIs that are driving growth in the sector is super important, so I want to help. After I created the JSON file, Erik went ahead and crafted an official one derived from mine, but he did a nicer, and more complete job than I did. He initially only did the web concepts, but right before I was ready to publish this he did the specs edition as well...

Stoplight Displays API Definitions By Default With Their API Doc Service

06 September 2016
I was doing some maintenance on my bots and APIs research, and processing the information for the bot analytics provider Botlytics, and as I was going through their API I noticed the prominent placement and availability of OpenAPI Specs for the API. Making your API definitions as prominent as possible is something I have been advocating for some time now, something I reinforced again recently by asking API providers to make sure and show as an icon, or other very visual element. This is a very important part of the API life cycle, that when also supported as a default feature by API service providers, just keeps giving to the API community, and helps makes it truly more open, consistent, while also helping it be more machine readable...

Working Tips and Tricks Into Your Regular API Evangelism Efforts

06 September 2016
I usually don't have to look very far to find good examples of API evangelism in the field, because the best technology providers are usually pretty consistent and vocal about their practices--allowing me to just pluck from my feeds, and rework as a story for my API provider readership. One of the consistent sources for me out there is from the Docker community, and from what they like to call Docker Captains. One of the things I see regularly from this Docker community leadership is the sharing of their platform tips and tricks and in-person and online meetups. This is definitely something I recommend other API providers do when possible, but I would also recommend working to integrate the concept into your regular evangelism activities like blogging, weekly newsletter, and Tweeting...

Connecting My API Logging With My API DNS Using CloudFlare Page Rules API

06 September 2016
As I'm spending time learning more about what my DNS provider CloudFlare offers when it comes to securing my APIs. To facilitate this, I am playing around with how I can utilize my Apache log files, to help me better drive the definition of DNS security using the CloudfFare API. I guess this is kind of a real time reactive, but also hopefully eventually a proactive solution to quantifying and defining the frontline of my API operations. I originally embarked on this endeavor to help me manage some of the shift in the API Evangelist network and help mitigate 404 errors across my network of API research. I had recently migrated what I call my API Stack research to a new domain (stack.network), and I am anticipating quite a few broken links in stories over the years that reference this area of my work...

Imagine If Tim Berners Lee Or Roy Fielding Had Patented Their Work

06 September 2016
I'm back wallowing through my API patent work, which I'm sure a portion of my readership is like, "oh gawd, hurry up and move on", which is the same way I feel, but the shit is so deep in this area of my API research I find myself often getting stuck. I just do not know enough about the law, intellectual property, and the patenting algorithms to argue coherently against API focused patents, but in my heart, I know that the API itself should be excluded from the process that is being defined. I know that many folks think I'm anti-patent. This is the default stance of intellectual property believers. I am not. I get the concept in many circumstances, but when it comes to the Internet, and web technology I think the concept needs an overhaul...

23K Patent Applications With API References Since 2005

02 September 2016
I am working to organize the 23,414 API related patents from between 2005 and present day, submitted by 4,283 companies--present in my API patent research. Not all of these APIs are "web APIs", but I think each companies portfolio tells a lot of what they are doing with APIs, their motivations behind, and is also a reflection on the overall state of the industry. To help me better understand the growth in API related patents I'm slicing and dicing the data, and publishing in different ways--I recently dumped the number of patents by year and published as a D3.js bar chart. It is pretty depressing to see the growth in patent applications that mention "application programming interface"...

I Am Keeping My Mind Open And Looking Forward To Learning More About GraphQL

02 September 2016
I wrote a post the other day sharing my thoughts around GraphQL seeming like we were avoiding the hard work of API design. Shortly after publishing Sashko Stubailo (@stubailo) from Apollo, a GraphQL solution provider, wrote a very thoughtful response to me comments and questions about GraphQL. First I wanted to say that I really dig this approach to responding to other people's blog posts, with a blog post of your own, within your own personal or company domain. I don't think Sashko has convinced me 100% that GraphQL is the solution we are looking for, but he has convinced me that I should be learning more about it, keeping a closer eye on the technology, and better understand how people are putting it to use...

After Looking Through 23414 API Patents I Think It Will Just Come Down To Who Litigates

02 September 2016
After looking through the 23,414 API related patents from between 2005 and present day from 4,283 companies, it is clear that the API patent game will be all about which companies decide to litigate using their "intellectual property". There is definitely a lot of education that could occur across all industries where these patents will be put to work, and hopefully we can see some reforms at the USPTO regarding how important it is to the economy that the APIs themselves to remain open and reusable, but I think that ultimately the world of API patents will be hammered out in courts across the United States, and other countries around the world. While I'm not a fan of the concept of the patent, especially when they are applied to algorithms and abstract ideas, I cannot intelligently argue for companies to not patent the "process that occurs behind the API" (at the moment), however I feel pretty strongly that it is pretty critical that the concept of the API should be left out of the process...

Be Straight Up About Internal Challenges When Hiring Your API Talent

02 September 2016
I see an increasing number of job postings on LinkedIn and other job websites from companies who are actively seeking an API rockstar, ninja, lead, owner, or product manager, and because of my connections in the space I know that some of the intent behind them are less than sincere. Don't get me wrong, I think ALL companies should be embarking on their API journey, and if that means bringing in outside talent--get it done! My motivation in writing this post is to help companies be more realistic during their talent search, and hiring process, as well as internally with their teams. As an IT and lead developer veteran, I have been brought in to take the reins on a number of teams and I have seen a wide range of toxic situations...

API Patent Search As Way To Discover Companies Who Are Doing APIs

02 September 2016
I have been pulling all the patent applications from the USPTO for a while now. As I work to fire API Evangelist back up, I'm working to be more regular about processing these files, and track on which companies who are including the phrase "application programming interface" in their title, abstract, or full description. So far I have 23,414 API related patents from between 2005 and present day from 4,283 companies--not all of these APIs are "web APIs", but there are many that directly reference being a method for providing and consuming an API for whatever process is being defined. Microsoft Corporation (2407) International Business Machines Corporation (1803) The United States of America as represented by the Secretary of the Navy (490) Sun Microsystems, Inc...

API Design Skills Required For Cyber Intelligence and Counter Intelligence

01 September 2016
It is hard for me to track on everything in the API space as a one man show, but one thing I keep an eye on, but rarely add to my research (yet) are the increasing number of job postings I come across that have an API focus. An interesting one this week, which follows a new vein in the API space that I'm mining, is out of the applied science technology research organization Battelle. They have an interesting job posting for a cyber computer scientist with Battelle’s Cyber Innovation Unit (CIU) providing "a broad range of products and services including Cyber Intelligence and Counter Intelligence, Cyber Research and Development and Fundamental Science, On­site Advisory Services, and Mission Focused tools including Embedded Systems Reverse Engineering...

Mapping Your Social Media Footprint As Part Of Your API Security Strategy

01 September 2016
Profiling the social media footprint of API related companies is what I do for a living. If you are doing something mildly interesting with an API I will add your Twitter, and Github accounts to my database. I will also go through Twitter, LinkedIn, and Github looking for all your employees and profile them. This is how I monitor the world of APIs, by profiling, and staying in tune with the companies, and what their employees are up to. While immersed in some "dark reading" I was pleasantly surprised to see "identify your organization’s social media footprint (companies, accounts, and key individuals)", as the top item on the list of things you can do to "shore up their social media and network defenses"...

The Sustained API Storytelling Assault On The Banking Industry

01 September 2016
After monitoring the tech space, and specifically the API space for six years now I really have feel for how stories are used try incite change in a variety of industries. There are many different waves of storytelling out of companies and tech blogs, which in the moment might seem like reality, but if you wait a month or two the topics run out of steam and go away--very few are sustained unless there is something really there there. Many companies are just throwing spaghetti at the wall to see what will resonate with the tech blogs, and their readers. Unless you monitor ALL the blogs like I do, you most often won't see these trends as being seeded by specific companies, VCs, and those looking to see what sticks...

Why Do Companies Who Ask Me To Update Their Logo Never Have Branding Page?

01 September 2016
When processing the news for API.Report, and the over 150 areas of my API industry research, I spend a good deal of time looking for images to represent my stories, and the companies I'm covering. When looking for an image to best represent a company I always search google for "[company name] logo branding", and look for an official branding and logo guidelines page for a company--secondarily I switch over the image search if there is no official page available. After a blog post, news piece, or research update goes live, I will sometimes receive a DM or email from a company asking me to update the logo, to a newer option than what I found via a Google search. I'm always happy to update the logo, and since my images are centrally stored on Amazon S3 it is pretty easy to do so...

Making Web Concepts and Specs Present As Real Time Help In API Design Tooling

01 September 2016
.gist-data {max-height: 500px;} I took the Github repository for Erik Wilde's (@dret) Web Concepts work and forked it, then generated some JSON which I could use to import into my API monitoring system. I've been manually adding specs to my Tweet and LinkedIn scheduling system, but I keep forgetting to go back to the site and add more entries. So I wanted to go ahead and import all the concepts and specs, and schedule out the tweets and LinkedIn posts for everything, over the next couple months. First I generated the JSON for the concepts: Then I generated the JSON for the specs: I left out the relationships between the concepts and specs, as I will just be linking to Web Concepts, and let people explore for themselves...

Treating New API Startups Like The Companies They Will Become

31 August 2016
I get a number of eager new entrepreneurs contacting me, looking for wisdom and insight about the API space. I've always worked to make myself accessible to people who are looking for knowledge around what is possible with APIs, and what is happening across the API space. Sadly, after six years and watching many companies come and go, I'm slowly changing this practice when it comes to startups. I have always been open with my knowledge on the space, and happy to schedule time for a gHangout or Skype call with each wave of new API startups, but after watching many of them grow up, get more funding, find their exits, acquisitions, and failures--I just can't keep doing it in good conscious. In my experience, only about 5% of these companies actually care about the space, their customers, and the rest are only focused on their own success and the success of their investors...

The Internet of Things Is An Opportunity For API Deployment As Well As Consumption

31 August 2016
Overall I am pretty underwhelmed by the Internet of Things. Most of the ways in which devices are being connected to the Internet are not very interesting, if not just a bad idea. Even with the overwhelming ways in which I am being underwhelmed by IoT, there are a handful of areas that I do find interesting, like industrial implementations, drones, and the general potential of the concept when you do it thoughtfully and securely. One of the differences between IoT and the other areas that are fueling APIs in 2016 is that they can be both an API provider, as well as an API consumer. While mobile applications have historically been the biggest driver of API development, they are just API consumers, as are most websites...

Enterprise Does Not Know (Care) How Big And Destructive It Is To APIs

31 August 2016
I feel like the enterprise has successfully rounded up the escaped experiment that is API, and got it under control. With its size and scope it didn't really even notice APIs until 2012 or so, and once it did it quickly joined the "conversation" to make sure it wasn't left out of what the cool kids were doing. Now in 2016, if you want to get the funding you have to have enterprise customers already, and if you are doing APIs and selling to the enterprise you have to speak in their terms "microservices"--as the concept of APIs never actually got approved by legal--microservices has. It seems like the simplicity, low cost, and user-centricity of APIs will be paved over at every turn, replacing the web in API with more vendor-friendly solutions with an HTTP facade that smiles like it's the web...

Why APIs Are Just The Next Step Of The Web And Not The Latest Trend

31 August 2016
I am always amazed at the amount of hype, rhetoric, and FUD that is stirred up by analysts, vendors, and the tech blogosphere when it comes to APIs. APIs are the next big wave in vendor solutions! APIs are going away because of bots! People love to build them up to be something they are not, something which I mostly blame vendors, venture capital investment, and the analysts and tech blogosphere for stirring this pot to meet their objectives. To help cut through the BS, I like to always have a basic demonstration of what an API is handy, and its relationship to the web, in hopes that I will educate the muggles (my new word--thanks @caseysoftware), and balance the BS scales a bit as we go along...

Company X's Competitive Advantage Is That They Have An API

31 August 2016
I have been thinking about the Twilio IPO a lot lately, as it seems to be well received by the market. I am trying to be realistic about this, and work to understand how much the API thing actually has anything to do with how well investors have received the company which we all love to showcase in the API space. I would like to think the "muggles", as my friend Keith Casey (@caseysoftware) calls them, understand the competitive advantage an API brings, but I just can't quite sell myself on the fact that this is the reality. As I'm mulling over this I am also working to get my API.Report news channel back up and running after taking a break this summer, and I'm noticing more companies are showcasing the existence of an API when talking about acquisitions, partnerships, and other market-related events...

The Ways That API Providers Are Using Twitter

30 August 2016
I am using Twitter more like an RSS feed these days. I pull the Tweets of the companies I track on once a day, and I scan / read them (when I have time), and either curate them or mark as read. I'm not happy with the Twitter algorithm, and I'm looking to get information straight from the horse's mouth, when I want, on my terms. I cringe at the fact I'm using Twitter as an RSS / Atom feed, but it is working well for me. I'm seeing several benefits of this approach, but one of them is getting a feel for some of the common patterns around how API providers are putting Twitter to work. So far I am seeing some pretty distinct approaches emerge: Not At All - They have a Twitter account, but they rarely ever Tweet anything...

Taking A Moment To Catch Up With APIs Before Moving To Next Big Thing

30 August 2016
Maybe with the current funding priority shifts in the tech world, and some of the push back on the startup way of life, we could pause a little bit and just let everyone catch up with their API strategy, before moving on to the next big thing. I get emails, DMs, and the occasional phone call from journalists looking for wisdom on what is next for the API space, where my answer is always, "more of what we have been doing". Sadly, my quote(s) never see the light of day--I am ok with that. Before companies look at doing bots, internet of Things, or begin playing with any of the new shiny objects on the landscape, we should just focus on doing APIs, doing them well, and realizing the fundamental benefits they bring to the table before getting distracted (yet again)...

Why I Added Cybersecurity To My API Monitoring Research

30 August 2016
I recently added a new area of research to API Evangelist focused on cybersecurity. I added this area of research not because APIs are being used to hack systems, which does happen occasionally. I did this because I wanted to better tune into this area because APIs are being applied by all sides (are there sides?) to communicate, evaluate cybersecurity events, and spread their message--which is a significant part of what is cybersecurity. When APIs aren't properly secured, and a breach occurs, I consider this a security topic and file it under my API security research. If something occurs in the wider global security theater, I file it under my cybersecurity research. This research doesn't always directly touch on APIs, but in many cases like the recent DNC hacks APIs are being used to analyze, study, share stories, and communicate around these often ongoing cybesecurity events...

GraphQL Seems Like We Do Not Want To Do The Hard Work Of API Design

30 August 2016
We were talking about GraphQL in the API Evangelist Slack channel the other day, and the consensus seemed to be that GraphQL is a way to avoid the hard work involved with properly getting to know your API resources, and it is just opening up a technical window to the often messy backend of our database-driven worlds. As an old database guy (1980s) I love me some SQL, but I am also a believer in what the API design, deployment, and the management life cycle can bring to the table. APIs are about taking often very technically defined resources, and making them accessible, and more intuitive (not always) to the people who are consuming and putting API resources to work.  Technologists love their new shiny toys that reflect their tech ideology, and this is what GraphQL seems like to me on the surface...

Keep Publishing Your API Definitions To Github So We Can Find Them

30 August 2016
I was just getting started evolving upon my API definition discovery tools before I left this summer, and is something I am just picking up again, now that I am back at it. Historically there are three ways in which I find API definitions like OpenAPI Spec and API Blueprint for APIs: Behind API Document - When I come across API documentation deployed using Swagger UI or Apiary, I know that behind them there is an API definition -- sadly they are usually obfuscated rather than proudly shared with an icon + link. Website Harvesting - When I find a company who is doing things with APIs either because they have a public API portal, or have issued a press release, I add their URL to my crawler and I suck down their entire site and sift through the results for API definitions...

APIs Are Not Just Meant For Killer Apps, They Can Also Be A Lifeline For Users

29 August 2016
In the Silicon Valley rat race users often become collateral damage amidst the entrepreneurial quest to get rich building the next killer startup. I've heard many startups like Snapchat and Pinterest state the reason they don't want to do APIs, is they don't want developers building unwanted applications on their services, something that stems from a mix of not understanding modern approaches to API management, and not really thinking about their end-users needs (both these companies now have APIs but for different reasons). I am sure that these platforms are often more concerned with locking in their userbase, then allowing them to be able to migrate their data, content, and other media off the platform for their own interests and protection...

Github Is Quickly Becoming My Most Important Discovery Source For API Space

29 August 2016
I have monitored the Github accounts and organizations for individuals and companies doing interesting things with APIs for some time now. However, recently this channel is increasingly being the way that I discover truly interesting companies, individuals, specifications, tools, and even services. The most interesting people and companies doing things with APIs usually understand the importance of being transparent and aren't afraid of publishing their work on Github. Developers are often very poor at blogging, tweeting, and sharing their work, but because Github allows me to follow their work, and provides additional ways to surface things using Github trending, I'm able to find things often before they'll show up on other common channels like Twitter, LinkedIn, etc--if they do at all...

The API Lightbulb Went On For Me When Amazon EC2 Launched A Decade Ago

29 August 2016
It is the 10th anniversary of the launch of Amazon EC2 this month, and I think it is a good time to revisit what this has meant to the API space. If you have heard any of my keynote talks where I visit the history of APIs and share my story of how I became the API Evangelist, you have heard this before, but is something I feel is worth repeating so that my new readers can play catch up. In March of 2006 Amazon launched their new Amazon S3 service, and in August of 2006 they followed up with their launch of Amazon EC2. The Amazon S3 release interested me and I signed up right away, but the Amazon EC2 release is when the lightbulb went on for me when it came to the potential of web APIs--which eventually led to me launching API Evangelist in July of 2010...

Add A Prominent Icon Link To Your API Definition On Your Documentation Page

29 August 2016
In an effort to help folks understand the many layers of just exactly what is an API and how people are using them, I'm going to emphasize (again) the importance of sharing your API definition publicly. I'm not going to talk about why you should have an API definition for your API, if you need a reason, go look at the growing number of ways that API definitions are driving a modern API life cycle--this post is about making sure you are sharing it properly once you have one crafted. I'm increasingly stumbling across OpenAPI Spec-driven Swagger UI documentation for APIs which I then have to fire up my Chrome developer tools to reverse engineer the path of the OpenAPI Spec--this is dumb. If you have an API definition available for your API, make sure it is available in a prominent location within your API portal, preferably using an easy-to-find icon and supporting link...

Beyond Just API Discovery: The Technical, Business & Political Decisions Needed At Runtime

29 August 2016
I was included in a conversation the other day on Twitter about runtime API discovery which reminded me of some thoughts I was processing before I walked away from work this summer, and before I dive back into the technical work, I wanted to refresh these thoughts and bring them to the surface. Blogging on API Evangelist, and other channels which I publish my work on is how I work through these ideas out in the open, something that saves me expensive time and research bandwidth while I'm down in the trenches doing the coding and API definition work. The Wider Considerations Of What Is API DiscoveryLike APIs themselves, the concept of API discovery means a lot of different things to different people...

Is Your Sales Deal Size Just Too Big To Be Reading API Evangelist?

26 August 2016
I am blessed to have people in the space who have supported what I do for the last six years. Companies like 3Scale, Restlet, WSO2, Cloud Elements, and others have consistently helped me make ends meet. Numerous individuals stepped up in May to help me make it through the summer--expecting nothing in return, except that I continue being the API Evangelist. I do API Evangelist because I enjoy staying in tune with the fast-growing landscape of industries being touched by APIs. I believe in what is possible when individuals, companies, organizations, institutions, and government agencies embark on their API journey (aka digital transformation). I do not operate as the API Evangelist to sell you a product, service, or to get rich...

Going The Distance To Help API Consumers Find Their API Keys And Tokens

26 August 2016
I am always amazed at how difficult it can be to obtain the API keys, or fire up an initial set of oAuth tokens when kicking the tires on a new API. I would also say that I am also regularly impressed the distance API providers will go to help API consumers obtain the keys they need to make a successful API call. One example of this is present in the new Stripe API documentation. Their new code samples give you a slick little alert every time you see a demo key and mouse over. The alert gives you a quick link to log in and obtain the keys you need to make an actual call. While I like this approach, I also  like the way Twitter does this and gives me a dropdown listing all of my applications, allowing me to choose from any of my current apps I have registered--maybe it is something that could be merged? Both are great examples of API providers going the extra distance to make sure you understand how to authenticate with an API, and get your API keys and OAuth tokens...

I Am Digging Stripes New Interactive API Documentation Walkthrough

26 August 2016
I am digging Stripes new documentation release, and specifically their interactive API documentation walkthrough. The new "try now" section of their documentation provides an evolve look at what is possible when it comes to providing your API consumers the documentation they need to get up and running. The new documentation provides not just a code example of processing a credit card charge, they walk you through accepting a credit card, creating a new customer, charge the card, establish a recurring plan, and establishing a recurring customer subscription. The walkthrough is simple, informative, and helpful. It helps you understand the concepts at play when integrating with the Stripe API, in a language agnostic way...

Using Anchors In Your FAQ And Other API Support Pages

26 August 2016
I was going through some of the Twitter feeds of the APIs that I track on and noticed Spotify's team providing support to some of their API users with quick links / anchors to the answers in their API user guide available at developer.spotify.com. This might sound trivial, but having an arsenal of these links, so you can tweet out like Spotify does can be a real time saver. @SoundiizExp hello! You have reached the rate limit! More info available here: https://t.co/PjBWWqDlfr — Spotify Platform (@SpotifyPlatform) August 16, 2016 This is pretty easy to do with a well-planned API portal and developer resources but is something you can rapidly add / change to using a frequently asked questions page for your API...

More Considerations When Providing An Anonymous App For Your API Service

25 August 2016
I wrote a post the other day about Postman.io having a limited, anonymous version of their API modeling tool. I stumbled across it while I was trying to upgrade my Stoplight.io account. Shortly after I tweeted out the blog post, John Sheehan (@johnsheehan) from Runscope chimed in with some wisdom on the subject. @kinlane we had a ‘one-click trial’ 24-hour account once, no email required. i regret the hours i wasted building it. — John Sheehan (@johnsheehan) August 19, 2016 @kinlane was basically just used for abusive cases. only one ever converted to a real user — John Sheehan (@johnsheehan) August 19, 2016 @kinlane hurl.it and requestb.in have the same problem...

Providing A Dedicated Mobile SDK Page For Your API

25 August 2016
Every API provider will have slightly different needs, but there are definitely some common patterns which providers should be considering as they are kicking off their API presence, or looking to expand an existing platform. While there are some dissenting opinions on this subject, many API providers provide a range of specific language, mobile, and platform SDKs for their developers to put to use when integrating with their platforms.  A common approach I see from API providers when it comes to managing their SDKs is to break out their mobile SDKs into their own section, which the communications API platform Bandwidth has a good example of. Bandwidth provides iOS and Android SDKs and provides a mobile SDK quick start guide, to help developers get up and going...

Managing The Apps Across All My API Accounts

25 August 2016
I am going through all of my online accounts changing passwords, and one of the things I do along the way is check which applications have access to my digital self. Increasingly my accounts have two dimensions of applications: 1) apps I have created to allow me to make API calls for my system(s) 2) apps I have given access to any account using OAuth. This is a process that can take quite a bit of time, something that is only going to grow in coming years.  The quickest example of this in the wild is Twitter. I have authorized 3rd party applications to access my account, and I have also developed my own applications, which have various types of access to my profile--this is how I automate my Tweets, profiling of the space, etc...

Watching Out For Your API Keys & Tokens On Open Internet

25 August 2016
I was just learning about Auth0's new password breach detection service, adding to the numerous reasons why you'd use their authentication service, instead of going at it on your own. It's an important concept I wanted to write about so that it was added to my research, and present in my thinking around API authentication and security going forward. Keeping an eye out for important identity and authentication related information used as part of my API consumption is a lot of work--it is something that I'd love to see more platforms assist me with. I've written about AWS communicating with me around my API keys, and I could see an API key and token management solution be built on top of their AWS Key Management Service...

Adding An Atom Feed For The API Evangelist Blog

25 August 2016
The API Evangelist platform is far from perfect, there are always portions of it that just aren't finished yet (always work in progress). I am always thankful that people put up with my API Evangelist workbench, always changing and evolving. Even with this unfinished status, there are some unfinished or broken elements that are just unacceptable--one of these is the lack of an Atom feed for my blog. Thankfully I have other folks in the space who are kind enough to remind me of what's broken when it comes to specifications, and ultimately what is broken on my website. all very much agreed: syndicate everything! but if you're setting it up, please use #Atom. #RSS simply is broken. https://t...

An OpenAPI Spec For A Building Permits API

24 August 2016
One of the reasons why crafting API definitions like OpenAPI Spec for our APIs, and openly sharing them on the web, is so that the pattern will get used, and reused by other API providers. That might sound scary to some companies, but really that is what you want--your API design used across an industry. Your API definition is not your IP, it is the magic behind your API, and the way you approach all the supporting elements around your API operations. There are numerous industries where I'd like to see a common API definition emerge, and get reused, and one of the more obvious ones is in the area of building permits. Open Permit has shared their API definition, by publishing the OpenAPI Spec to drive their Swagger UI documentation...

CRX Extractor Wins For The Best Customer Quote Ever

24 August 2016
Having quotes from your customers on your company website is a no-brainer. Finding the best examples of brands and companies putting your valuable service, or tool to work demonstrates it has value, and that people are using it. While playing around with a new chrome add-on reverse engineering tool called CRX Extractor, I noticed the quote at the bottom of their page: They win in my book for having a funny, but also pretty realistic endorsement for why you should be using a product. I'm using the tool to better understand how browser add-ons are putting APIs to work and evolve my own creations as well, but I can see reverse engineering them to make sure they are secure is a pretty important aspect of operating your company securely online...

If You Use API Definitions There Is No Excuse For Not Having An API Sandbox

24 August 2016
I have long been a proponent of using API definitions, not just because you can deploy interactive API documentation, but because they open up almost every other stop along the API life cycle. Meaning, if you have an OpenAPI Spec definition for your API you can also generate SDKs using APIMATIC, and API monitors using Runscope.  One of the examples I reference often is the API Sandbox solution appropriately named Sandbox. One of the reasons I use Sandbox in this way is that API mocking using API definitions is a pretty easy concept for developers to wrap their heads around, but also because their home page is pretty clear in articulating the opportunities opened up for your API when you have machine-readable definitions available...

You Can Make Money While Also Doing Important Work For The API Space

24 August 2016
I see a lot of companies doing things with APIs, and I often find myself struggling to find companies who are doing important things that benefit the community, have a coherent business model, and providing clear value via their services. In the drive to obtain VC funding, or after several rounds of funding, many companies seem to forget who they are, slowly stop doing anything important (ie. research, open source, etc.) with their platform, and seem to just focus on just making money.  One phrase I hear a lot from folks in the space is, "it's just business", and that I should stop expecting altruistic behavior around APIs, and within the business sectors which they are impacting--APIs are about making money, and building businesses hippie! Often times I begin to fall for the gaslighting I experience from some in the API space, then I engage with services like CloudFlare...

A Wicked (Good) Open Source API Deployment And Management Stack

24 August 2016
I was introduced to a new open source, Dockerized API operations solution called Wicked, that was developed by the integrated cloud and desktop solutions provider, the Haufe Group. There are a number of open source API management solutions out there, and an even greater number of API frameworks that can help you deploy your APIs, but Wicked is the first to span several areas of the API life cycle including DNS, deployment, containers, authentication, management, and documentation, Built On Existing Open Source API GatewayThe Haufe Group built the core of Wicked on top of an existing open source API management solution, further augmenting, evolving, and improving on an existing solution: Kong API Gateway - Use Mashape Kong to protect and proxy your backend APIs Why reinvent the wheel? It makes sense to build on existing solutions for API management, developing on top of what is already being used by API architects and developers...

Sharing Your API Platform Road Map And Telling The Story Like Readme.io

23 August 2016
Sharing your platform's road map with the public, and your community is an often overlooked aspect of API operations but is one that can go a long way to communicate your plans for the future with your community. This is why I carved the concept out into its own research area, to help me better understand how the successful API providers, as well as API service providers are publishing, sharing, and communicating around their road map. One example of this recently is out of the API documentation service provider Readme.io, who didn't just publish a nice, simple, and clean road map for their platform, they also told the story of the process. This is a great way to announce that you have a road map for the platform but is also something you should repeat as often as possible, telling the story of what you just added to the road map and as much detail on why...

Prioritizing Commonly Requested Information With Your API Deployment

23 August 2016
I was reading the post from open data service provider Socrata about "putting citizens first" when it comes to opening up city, county, state, and federal government data. One of the headlines they showcased was "Texas overhauls open data portal, prioritizes commonly requested info"--which is a pretty sensible thing to consider for not just government, but also companies thinking about what to open next. First, let me emphasize that I am talking about open data that is already published on the web in another format (or should be). What the State of Texas is doing is what I call the low-hanging fruit for API deployment--if it is on your website, it should also be available in a machine-readable format...

The Expanding API Layers That Overlap Our Physical And Virtual Worlds

23 August 2016
I wrote the other day about the interesting opportunity opening up within the satellite imagery API layer, and earlier about the similar opportunity that is being expanded within the fast growing dimension of our world being opened up with drones. Layers within maps are nothing new, and is something that Google has pushed forward early on in the history of APIs with Google Maps, but I feel is further being expanding on as APIs open new dimensions like satellites and drones. Then being further expanded on by adding API access to each layer for augmenting, and injecting other valuable API resources into these newly created API dimensions. Let's see if I can successful describe the multiple API dimensions being opened up here...

Who Is Going To Do The DevOps Aggregation API Platform?

23 August 2016
There are two distinct types of APIs I keep an eye on. One is what I call my life cycle APIs, which are the APIs of the service providers who are selling services and tools to API providers and developers. The second category is what I call my stack network, and these are the individual API providers, who offer a wide range of API resources--you can find both of these types on the home page of API Evangelist.  The 50+ life cycle APIs I track on can be used by companies to manage almost every stop along a modern API life cycle. In theory, all of these service providers have APIs. In reality, they do, but they do not practice what they preach and often do not make their APIs easily discoverable...

API Providers Could Add A Page To Showcase Their Bots

23 August 2016
I am coming across more API providers who have carved off specific "skills" derived from their API, and offering up as part of the latest push to acquire new users on Slack or Facebook. Services like Github, Heroku, and Runscope that API providers and developers are putting to work increasingly have bots they employ, extending their API driven solutions to Slack and Facebook. Alongside having an application gallery, and having an iPaaS solution showcase, maybe it's time to start having a dedicated page to showcase the bot solutions that are built on your API. Of course, these would start with your own bot solutions, but like application galleries, you could have bots that were built within your community as well...

What Is A RESTful API And Why Does It Matter To IoT?

22 August 2016
I'm pretty skeptical about many of the reasons behind why companies are connecting devices to the Internet using APIs--I am just not convinced this is the best idea when we already have so many security issues with the standard, and mobile web. Regardless, I'm constantly working to understand the motivation behind a company's motivation to do APIs, as well as what they are telling their customers.  I published a story last week about defining the industrial programmable automation controller (PAC) strategy using an API, which focuses on the approach by Opto 22. To support their efforts the industrial automation provider offers up a dedicated page to educating their customers on why you would want to use REST, providing some bullets: Archive I/O and variable data from the PAC directly into Microsoft SQL Server using Microsoft's T-SQL—no OPC or ODBC required Read data from and write data to the PAC from your browser or web-based application using JavaScript...

Thinking In Terms of API Skills And Moving Beyond Just API Resources

22 August 2016
The APIs which have seen the greatest adoption across the API space, always provide the functionality that developers are needed in their applications. It is either because the platform is already in use by their users (ie. Twitter, Facebook), or just provides the core feature that is required (ie. SMS, Email). There are an unprecedented number of high-value APIs out there, but I think many API providers still struggle when it comes to defining them in a way that speaks to the needs that web, mobile, and device app developers will be needing. I have explored this topic before, discussing the importance of exposing the meaningful skills our APIs possess for use in the next generation of messaging and voice apps, as well as asking whether or not our APIs have the skills they need in a voice and bot enabled world...

The Racial Bias Being Baked Into Our Algorithms

22 August 2016
My "fellow" Presidential Innovation Fellow Mollie Ruskin (@mollieruskin), was doing some work with veterans recently and stumbled across a pretty disturbing example of how racial bias is being baked into the algorithms that are driving our online, and increasingly offline worlds. This morning I was searching #‎Google for images of #‎Veterans for a project. I stumbled upon a photographer who had taken hundreds of beautiful photographs of Veterans all in the same style. I clicked on a few striking portraits...I quickly noticed something very troubling. When doing image searches, I often use the 'related images' feature to uncover more pictures relevant to what I'm hunting for, as was the case this time around...

Delivering API Docs Using OpenAPI Spec Driven Templates For Angular

22 August 2016
I have been talking with Nick Houghton over at Sandbox about the state of OpenAPI Spec driven API documentation, and the lack of a machine-readable core when you deployed Slate driven documentation. He was wanting the same thing--a good looking, dynamic API documentation that was OpenAPI Spec driven. He recently got back to me and found a solution that worked for them: "Ended up just templating the Swagger JSON myself rather than relying on Slate etc to do it. So model/resources are Swagger annotated, CI pushes out Swagger JSON and Angular UI parses in the browser, works quite well I think". Nick is on a similar path that I am, as I work to simply API documentation using OpenAPI Spec, and provide specialized views of APIs using Liquid...

The Expanding World of Technology Evangelism

22 August 2016
Technology evangelists are nothing new, but are something I think is continuing to expand as the Internet continues to crack open more of the core areas of the tech sector. I specifically chose the term API Evangelist to define what I did evangelizing for all APIs, but all I was really doing is following the lead of evangelism pioneers like Amazon, Google, and even Microsoft.  There has long been discussion around evangelism vs advocates, and I've seen companies also choose to adopt an ambassador format. I have also been interested to see the evolution of Docker's Captain's program--who are "Docker experts and leaders in their communities who demonstrate a commitment to sharing their Docker knowledge with others"...

When Your API Consumption Influences The Acquisition Of Your Startup

19 August 2016
I saw that the contact API solution FullContact recently purchased the professional network management solution Conspire. Thankfully FullContact is good about blogging about the move, and the details of the motivations behind their decision -- without this type of storytelling I wouldn't even have known it happened. One thing I noticed in the blog post was that "Paul, Alex, and the entire Conspire team have been fabulous partners with FullContact, having utilized our Person API as a part of the Conspire offering". Acquisitions from within an API ecosystem is not new. It is why many companies do APIs in the first place, to help identify talent within their ecosystem like Paypal does, and complimentary companies and teams like FullContact has done...

Providing An Anonymous Layer To Your API Provider Service Like Stoplight.io

19 August 2016
I was playing around with the free and the now paid layers of Stoplight.io, and wrote a previous piece about their lack of a public pricing page, and I noticed they provided an anonymous layer to their API modeling service--without logging in, you can play around with their HTTP client tool, and make requests to an API. The anonymous version is super limited compared to their full solution, but I think the presence of an anonymous edition opens up an interesting discussion. It appears Stoplight.io has done a lot of work lately to separate the layers of v2 of their service, and provide a public, free, as well as paid, and enterprise editions of their API modeling solution. With the shrinkage of freemium these days in the API space and the tightening down on free trials, an anonymous layer is compelling...

I Know It Is Hard When You Are Just Getting Started, But Please Make Your Pricing Page Public

19 August 2016
I received an email from Stoplight.io about their version updates, which included the phasing out of the free beta period--makes sense. I clicked on the "you can view pricing, and setup billing, on your account billing page" in the email, and was taken to the register page.  To clarify a little bit, I have an account with Stoplight.io, which I registered using my @kinlane Github account. I'm logged in as my @apievangelist Github account presently as I'm doing some work with multiple repos, and I really didn't want to log out of @apievangelist and log in with my @kinlane just to see the pricing. So I head directly to the public website of Stoplight.io to look for pricing--which I can't find within 30 seconds (standard approach)...

Providing Multiple Types of API Sandboxes To Develop Against

19 August 2016
I was going through the Cisco Devnet ecosystem and stumbled across their sandbox environment. I thought it was worth noting that they provided several different types of sandbox environments, with a rolling list of available sandbox instances at any point in time. Cisco provides seven different types of sandboxes: Networking - The Networking Sandbox allows you to remotely access Cisco Networking technologies. Each Sandbox contains either simulated or physical network elements as well as access to developer tools. Some Sandboxes also provide for the creation of synthetic traffic.  Collaboration - The Communication and Collaboration Sandbox allows you to remotely access Cisco Collaboration technologies in a cloud lab...

Maybe A Save As JSON Option For Excel Wasn't Forward Thinking Enough

18 August 2016
In September of 2015, I asked when are we going to get a save as JSON in our spreadsheets? I was doing a lot of work saving spreadsheets as CSV files, something I can easily do programmatically, but I was doing it manually as part of a workshop. After I downloaded each CSV file, I then converted to a JSON file--leaving me asking, "where is the save as JSON"? As I've been reviewing new Microsoft's Excel API, I got to thinking about the need for a save as JSON option, and now I think that this line of thought was not forward thinking enough. A "save as" just does not speak to the future of machine readable spreadsheet interactions in an online world. Save as CSV, TSV, are very desktop oriented visions of using Excel, and in 2016 we need more...

The Historic Newspaper API From The Library Of Congress

18 August 2016
It always bums me out that the cool kid startup APIs always get the lion share of the attention when it comes to APIs in the tech news. Which I guess makes it my responsibility to show the ACTUAL cool kid APIs, like the Chronicling America API from The Library of Congress, which provides access to information about historic newspapers and select digitized newspaper pages. The Library of Congress provides APIs for searching the newspaper directory and digitized page contents using OpenSearch, auto suggesting of newspaper titles, links using a stable URL pattern, and JSON views of all newspaper resources. They also provide linked data allowing you to process and analyze newspaper information with "conceptual precision" (oooooh I like that), as well as bulk data for your deeper research needs...

Providing Additional Support Options For Your API In Your Twitter Bio

18 August 2016
As I was writing up a story on Mailjet tweeting out the iPaaS opportunities around their email API, I noticed their Twitter bio. It is subtle, but having spent a great deal of time looking for the support channels for an API, this is a potentially huge time saver. It is what I do best, discovering these simple, subtle things that the successful API providers are doing. I always encourage API providers to use Twitter as a support channel because it doesn't just provide support, it also is a public demonstration that you give a shit about your API consumers, and will actively work to help them solve their problems. I've seen APIs who offer no support, or a minimal number of support channels, while also seemingly working very hard to hide them--leaving you feeling like you will never get help when you need it...

Expanding My Awareness Of How APIs Are Being Used At The Network Level

18 August 2016
I work as hard as I can to understand every sector being opened up using web APIs, and the network level is one that I need to push my awareness of, partially because I find it interesting, but mostly because of the impact it can have on every other aspect of how the Internet works (or doesn't). To get started I went over to Cisco Devnet, and took a look at their pxGrid solution, which is a "multivendor, cross-platform network system that pulls together different parts of an IT infrastructure such as security monitoring and detection systems, network policy platforms, asset and configuration management, identity and access management platforms", which provides "you with an API that will open up a unified framework that will enable you to integrate to pxGrid once, then share context with any other platform that supports pxGrid"...

Tweeting Out The iPaaS Opportunities That Are Available For Your API

18 August 2016
I've been an advocating for API providers to embrace integration platform as a service provider (iPaaS) for three years now, encouraging them to make sure their API is accessible via popular platforms like Zapier. While I don't push these as a required building blocks for all providers, they definitely are what I'd consider as the common building block across many of the successful APIs I keep an eye on. Making sure your API is available on iPaaS platforms, and you are showcasing these opportunities is becoming more and more important. Another positive move you can make when it comes to iPaaS, is to tweet out what is possible on a regular basis like #mce_temp_url#the transactional and marketing email API provider Mailjet does--here are a couple examples of this in the wild: Connect @Mailjet + @send_with_us to leverage email marketing with awesome deliverability Sync @Mailjet + @Fullcontact to auto add contacts from business cards to email lists  Sync @Mailjet + @GravityForms to automatically create contacts from new form entries Sync @Mailjet + @Evernote to save new subscribers to a new note automatically I may add this type of activity to my list of common API evangelism building blocks...

Continuing My Struggle For Reciprocity As ETL Evolves Into The Cloud As iPaaS

18 August 2016
Early on in 2013, I started a research project to keep an eye on a specific type of API driven service provider, like IFTTT and Zapier, who were enabling individuals and businesses to move data around in the cloud. This new wave of startups was moving from what we traditionally called ETL in the enterprise, which was about extracting, transforming, and loading data between various systems, into the cloud era.  I'm an old enterprise database guy, and ETL has been an essential tool in my toolbox for quite some time--according to Wikipedia ETL is: Extract, Transform and Load (ETL) refers to a process in database usage and especially in data warehousing that performs: Data extraction – extracts data from homogeneous or heterogeneous data sources...

Zapier and The Excel API

17 August 2016
I have been finding quite a few nuggets of wisdom out of the recent release of the Microsoft Excel API. This is what I enjoy doing as the API Evangelist, evaluate and gather any positive or negative activities performed by the leading API players, craft blog posts in hopes that other API providers will read, enabling them be more successful in their own API operations. As part of my monitoring, I am also looking for significant trends that may reflect other wider industry opportunities, beyond any individual API. I am always telling API providers to think about integrating iPaaS solutions like Zapier into their operations as early as possible, and I think Microsoft's acknowledgment in their release emphasizes the importance of iPaaS...

The Support Flow Over At The Microsoft Excel API

17 August 2016
I am pretty impressed with the casual release of the Microsoft Excel API, which I think is a pretty significant milestone for the world of APIs. One of the subtle elements of their API release that I think is worth noting, is the support flow they provide. Here is the actual text from the release blog post for the Excel API: "Give us your feedback on the API and documentation through GitHub and Stack Overflow, or make new feature suggestions on UserVoice." This is the most open, and casual I think I've seen Microsoft ever be. They are allowing the community to suggest edits to their API documentation using Github, encouraging the conversation on their own forum, as well as outside their ecosystem, on Stack Overflow...

Instead of Just Discussing Via Phone You Should Publish Your API Goings On To Your Blog

16 August 2016
At any point in time, there are numerous emails in my inbox, LinkedIn messages, and DMS, asking me if I would "just jump on the phone to discuss the latest" about an API. I get a regular stream of these, which makes it pretty impossible for me to actually make time to do, and if I did make time to talk to each of these API providers, I wouldn't have time to actually write up stories and guides for my site. I'm sure it can be frustrating for folks who just want to share the latest with me, but I hope you will understand that I am just a one man show, and I have to prioritize. I recommend that you also get better at managing your time, and write up each of the things you wanted to talk to me about as a blog post, and then share out via your API platform's Twitter, LinkedIn, and Facebook (you have all those right?)...

Not Having RSS For Your Blog And Just Relying On Tweeting

16 August 2016
I regularly come across organizations who have blogs without RSS feeds. Sometimes I will drop people a line and ask if they have one, or let them know it would be very useful to have an RSS feed easy to find. This is also a topic I write about regularly to help remind folks that RSS is not dead.  Almost every time I write about the topic I get a handful of people who tell me you don't need RSS anymore, you just tweet out your blog posts--nobody uses RSS readers after Google Reader went away. While it might be true that some folks have abandoned their feed readers, I think they were casual readers in the first place, and serious analysts still very much depend on RSS. I wish I could help folks understand the power they are giving away to Twitter by thinking like this...

API Definitions Are Slowly Becoming More Important Than Having SDKs

16 August 2016
As the debate over whether you need an SDK for your API or not has rumbled over the last couple of years, API specification formats like OpenAPI Spec, Postman, and API Blueprint have been gaining traction. As this has progressed, I've asked myself several times whether or not API providers even need SDKs anymore. Not just because of the complexities of developing and maintaining, but because more developers are using web clients like Postman and DHC to evolve their integrations. Apigee Explorer and Swagger UI documentation demonstrated that many developers needed to play with an API as they were learning about what resources were available, and how to use them. I think the evolution of API clients like Postman, DHC, PAW, and others have shown that this phase of playing, exploration, and non-code integration can go well beyond just integration and should actually be neverending across stops along the API life cycle...

Defining The Industrial Programmable Automation Controller (PAC) Strategy Using An API

16 August 2016
I was learning more about the Programmable Automation Controller (PAC) API from Opto 22 and fouind myself intrigued by their usage of the word strategy to describe the role a web API can play when it comes to making the industrial automation process more programmable. I'd say the over API design is still very rough and represents the engineer's view of a PAC, but the potential for industrial IoT strategy orchestration is still present. I'm learning about PAC APIs through the lens of my drone API research, where the role an API can play in the devices strategy creation, as well as execution. Meaning, with a drone, I can use the API to get at the data from one or many drone flights, as well as use the data, then the API again, to help me execute on the strategy...

Not All APIs Are Created Equal So Make Sure You Set Expectations Properly

16 August 2016
I've heard of numerous API providers shutting down their API programs after a couple months because they didn't see the number of new users, and integrations they had hoped for. It is so easy for us technologists to shoot for the moon, while also simultaneously shooting ourselves in the foot when it comes to defining where the bar should be for our operations.  Remember, we are not all Twilio. For most of us our API will never be our primary product, and operating it will be less than a glorious affair--meaning you will never be written up in Techcrunch ;-). We are entering into the really mundane, business as usual phase of the API industry, and things will not be as exciting or sexy as they have been, and we need to make sure our APIs stay real, and reliable amidst all of the tech delusions we have on a regular basis...

Putting The Industrial Into IoT With Programmable Automation Controllers (PAC) APIs

15 August 2016
When you hear about the Internet of Things (IoT) you often hear about the hopeful consumer side of thing, like with Nest thermostat, and the next wave of Internet-connected devices that will change our personal worlds forever. Personally, when I think about the concept of Internet-connected devices actually seeing adoption, and getting traction, I think of it being applied in an industrial setting.  The RESTful programmable automation controllers (PACs) APIs out of Opto 22 resemble this vision of IoT which I have in my head. APIs making everyday objects used in a variety of industrial processes, programmable, and accessible over wired or wireless networks. Making everything from manufacturing to water and energy facilities more automated and efficient, while potentially generated data that can be used to monitor, and optimize these industrial workflows--this is IoT...

API Service Composition Baked Into The Cloud With Usage Plans For Amazon API Gateway

15 August 2016
Being able to provide different levels of access for a single API has been one of the telltale characteristics of any modern web API. Savvy API providers know they don't just make their valuable API resources publicly available for anyone to use, they know you can craft a logical set of plans that are in alignment with your wider business objectives, outlining how any developer can put an API to use--this is the essential business of APIs. Mashery was the first API management provider to standardize this approach to API access, something further evolved by 3Scale, Apigee, and others. Amazon's release of their API gateway wove API management into the fabric of what we call the cloud, and the introduction of usage plans, does the same for API service composition...

Introducing Vendorless APIs and Microservices

15 August 2016
I'm a big fan of the concept of serverless APIs and microservices, but not so much of the name. I get it, the space needs new concepts to rally around, and I'm the first to admit even the concept of an API is bullshit, but when people say serverless, it always makes me chuckle--especially when people work so hard to sell it (who am I to make fun of that). Often when I come across a serverless solution, it is often bundled with the phrase "100% serverless", a description which usually then contains the 2-6 vendor solutions used to deploy said serverless solution. I know there is no use in pointing out there are always servers behind serverless solutions, but can I at least point out the vendor dependencies involved? Are the vendor dependencies better or worse than our dependencies on servers (that never went away)? IDK...

Constant Contact Provides Good Blueprint For An API Getting Started Page

11 August 2016
I was going through the getting started pages for the APIs that I keep an eye on, pulling together an outline of what I'd consider to be some of the best elements across all the API providers. Then I came across the getting started page from Constant Contact, and I'd say they win for being the clearest and concise API getting started page of them all.  Constant Contact's approach to their getting started page has given me a good start for my outline, including essential links to setup your account, create a new application and get your keys. Constant Contact also provides required documentation, an API tester, and supporting code libraries. Additionally, they encourage you to certify your integration as a partner and get published in their integration marketplace--providing a pretty well thought out getting started page in my opinion...

Investing In Your API Community Like Amazon And Slack

10 August 2016
The messaging platform Slack made waves when they launched their Slack Fund as part of their API release, putting up $80M to invest in developers who were interested in building cool things on the API. Slack has continued telling their story, talking about how they have invested some of the fund and are being pretty transparent about which API integrations made the cut.  After reading about the Slack Fund I wanted to see which other APIs were investing in their communities like this. Next, I came across the Alexa Fund where Amazon is investing in developers building voice-enabled apps, giving their Echo platform the boost of applications it will need to find success. After poking around the AWS platform, you also find they have also had their AWS Grants program, investing in the best of breed projects that use the AWS platform to give back to the world...

The Release Of The Microsoft Excel API Is A Pretty Significant Milestone

10 August 2016
I am all about marking down the important milestones that help define the API sector. It is what I've been working to define as my history of the web APIs for the last six years. An API has to make its mark in pretty big way before I'll add as an official milestone in my version of the last 17 years of the web APIs.  I'll give it some time, but I'm thinking the recently released Excel API from Microsoft is going to get added pretty quickly. I think the next five years of API evolution is going to be much less exciting than the previous five years, with numerous small businesses publishing their valuable data, content, and complex algorithms via the Excel API. This stage of API deployment won't be filled with API heroes like Amazon, and Twilio, but will still make a seismic shift in the landscape just through the pure volume of data that is made available--we won't be able to keep up...

Google For API Code Examples Just Like Your New Developers Will

10 August 2016
I am always looking for simple advice I can give to API providers to make their developers and would-be developers integration as friction-less as possible. When it comes to making the code available for your API I recommend providing a wealth of samples, libraries, and full blown SDKs for your developers. Also make sure these code resources are as easy to find within your developer portal, as well as being openly licensed and available on your API platform's Github profile. Adding to this advice I would also recommend that you take the top 10 programming languages and platforms out there, and perform a quick Google search for the key phrase, and see what comes up, on a regular basis. I tend to find interesting conversations around an API when I do this...

Where Is The Ethical Line When Defining And Securing The API Landscape?

09 August 2016
I was reading a post from the Electronic Frontier Foundation asking some great questions about having a safety protocol for things like the DARPA's Cyber Grand Challenge. It is good to see EFF leading this conversation, providing us with some important things to consider as part of any security related work, whether it's in the cyber theater or just guiding your ethics as a small business, analyst or freelance hacker (I happen to be all three).  To hopefully contribute somewhat to the conversation, I wanted to think through some of the questions I ask when defining and helping folks secure their slice of the API landscape. There are two distinct portions of the conversation I wanted to chime in on, speaking to the areas that I find the most friction with when mapping out, and securing infrastructure...

Will Your Approach To Technology Be More Like Siri Or Alexa?

09 August 2016
I am still learning about the recent API release out of Apple, and working to keep up with the volume of resources coming out of the Amazon Alexa ecosystem, but one thing I know for sure is Amazon is way ahead of the game, and Apple will have to invest a lot more resources if they expect to catch up. Apple may have the device advantage, but Amazon is leaps and bounds ahead when it comes to how you develop a community in support of voice-driven applications. I wouldn't be surprised if Apple's release was in response to the waves Amazon is making with their voice platform. When it comes to the platform battles between tech giants, they can throw the necessary resources at things to play catch up, but it is something that other smaller players will not be able to always navigate...

Fascinated With The Algorithm

09 August 2016
According to Wikipedia, in mathematics and computer science, an algorithm is a self-contained step-by-step set of operations to be performed. Algorithms perform a calculation, data processing, and/or automated reasoning tasks. These often very abstract inventions are increasingly guiding our personal and professional worlds from deciding what we read on Facebook, scanning the videos uploaded to your Twitter and Vine feed, to whether or not you might commit a crime again, and even predict potential police misconduct. I see the concept of an algorithm applied in many different ways, some are very simple and easy to understand, and some are not so easy to understand, and operate as black boxes...

Doing More To Invest In Web Literacy Across The API Community

09 August 2016
When I talk about how much I believe in APIs, all I am really saying is how much I believe in the web. The web is how humans are consuming and sharing data, content, and algorithms with each other using the Internet, and APIs are how systems, applications, and devices are doing this via the Internet. I do not advocate for any single API, company, tooling, or technology. I am evangelizing for an open web. This is why I am always a little ashamed at how incomplete my understanding is of the core concepts that make up the web and the specifications that are driving it. Thankfully there are people like Erik Wilde (@dret) who work tirelessly to help us understand them, and make available in a simple way like he did with his Web Concepts project...

Overlay API Data On Satellite Imagery Then Make Available Again Via API

08 August 2016
I wrote a story last week about how Airmap is positioning itself to be an API broker within the fast growing Drone industry. I also stumbled across the satellite imagery API out of Astro Digital, and specifically their 3rd Party Real-Time Data API which is designed "to combine mass amounts of data, like adding live weather data on top of imagery"--resembling the layer of the drone industry which Airmap is investing in. Airmap is delivering geo-intelligence for applications used when flying drones, Astro Digital has an API which injects geo-intelligence at the satellite image layer--I guess the satellite layer would be one layer up from the drone layer when it comes to APIs providing access to our physical world...

Access To Satellite Imagery Via A Web API

08 August 2016
In 2006 Amazon introduced me to the idea that you could deploy global infrastructure using web APIs. This was when web APIs went from the hobby level (ie. photos, social, links) workbench, and became a tool I could actually use in my business toolbox. Web APIs weren't just used or fun and games anymore, opening up my eyes to the endless possibilities when you make the web programmable using APIs.  In 2016, I see a number of APIs show up on my monitoring radar, and honestly, most of them are not that notable--then you come across the solutions like the dead simple satellite imagery API from Astro Digital. I'm increasingly finding myself tracking on the collision APIs are having with our physical world, so I see a lot of interesting (and some not so) APIs, but I find the notion that you can get the latest picture of a specific place on earth is a pretty significant milestone for web APIs...

Reconciling How Reliable APIs Are While Also Embracing Tone Set By VC Investment

05 August 2016
I have done a lot of reading in the last week, catching up on my monitoring of the API space. I have read a couple of posts about the reliability of APIs, and the overall viability of building applications, and businesses based upon them. A couple of the posts were focusing on the shuttering of ThinkUp, but a couple others were just part of the regular flow of these stories that question whether we can depend on APIs or not--nothing new, as this is a regular staple of bloggers and the wider tech blogosphere. My official stance on this line of thinking is that I would not want to be building a business, and application that depends on leading API platforms like Twitter, Facebook, Instagram, and others, but I will happily build a business, applications, and system integration on APIs...

Airmap Is Positioning Itself To Be A Critical API Broker For The Drone Industry

05 August 2016
I first came across Airmap as I was learning about them acting as the middle man for DJI drone updates via the Department of Interior. After this story, I added them to my database of companies that I track on. Then as I was monitoring my feeds I saw they were now working with IBM to get weather information for use by drone manufacturers, operators, and those impacted by drone activity.  Airmap positions themselves as "airspace Intelligence", offering low-altitude airspace management solution for unmanned aircraft. When you consider the drone as just one of many devices being connected to the Internet, the role intelligence providers like Airmap will play when it comes to system to system integrations, and web or mobile application development in each space--the company seems to be well-positioned for success in the drone industry...

I See A Number Of Incomplete API Efforts That Come Out Of Connected Device Providers

05 August 2016
I've seen quite a few incomplete API efforts in my time as the API Evangelist. It is why I aggregate the most common building blocks I see across successful API providers like Twilio and organize them into blueprints anyone can follow like my minimum viable API footprint definition. It doesn't take much effort to pull together a basic API presence like this and is something that can go a long ways to help onboard new API consumers.  There are a number of interesting APIs out there like the AirControl API, which gives you programmatic access to enterprise-grade wifi and wireless network solutions from Ubiquiti Networks, but then quickly reduces a pretty robust API effort to being just a PDF document...

Diff Tooling For JSON, YAML, And Markdown Versions Of API Definitions

05 August 2016
As the number of available API definitions out there grows, I am increasingly coming across variations of APIs that I already have included in my API Stack. It can be tedious to try and sync these with existing copies, so I wanted to take a look and see if there was anything already available out there, that would help provide a diff for either OpenAPI Spec, RAML, or API Blueprint. The most common one I found referenced was a Ruby one for OpenAPI Spec from Civis Analytics. Next, I found a pretty interesting web tool, which provides its Node.js source code on Github, including a CLI edition. After these two solutions, I only found one more for RAML, but couldn't find anything for API Blueprint...

Thinking About The Better Business Bureau API In Context Of The Overall API Economy

04 August 2016
I was happy to stumble across the Better Business Bureau API the other day. I was working on a piece about "the API economy", and looking for real world examples of how APIs could actually contribute positively (or negatively) to the actual economy, and found the useful API.  The Better Business Bureau provides five API endpoints for consumers: Organization Search - This endpoint will allow you to search for Organizations that are known to the BBB.  Organizations may include businesses or charities. Organization Collections - BBB Partners will need to be able to identify collections of Organizations that they care about and be able to manage those collections and receive Organization info and updates on them as needed...

Shaming People For Not Being Or Understanding REST Is Why We Have So Much Inconsistency In API Design

04 August 2016
I was reading some of the blog posts, Reddit and Hacker News threads about Microsoft's release of their API design guide. While many of the comments are technically correct, the tone in which they are delivered, and the intent behind their delivery is one of the biggest contributing factors to why we have such wild inconsistencies in API design across the landscape.  API Evangelist was born in 2010 out of frustration with the Restafarian pundit class. I made it my mission to help tell stories of the technical, business, and politics of APIs in an inclusive way, that didn't make people feel stupid for what they didn't understand. Even after six years of doing this, I am still learning things about APIs and being regularly reminded that there are few absolutes when it comes API design, definition, deployment, management, or any of the other 50+ stops along the API life cycle that I track on...

Pushing For More Algorithmic Transparency Using APIs

04 August 2016
I saw the potential for collaboration when it came to using web APIs back around 2004 and 2005. I was seeing innovative companies opening up their digital assets to the world using low-cost, efficient Internet technology like HTTP, opening things up for potentially interesting approaches to collaboration around the development of web and mobile applications on top of valuable digital resources. This approach has brought us valuable platforms like Amazon Web Services and SalesForce.  Common API discussions tend to focus on providing APIs to an ecosystem of developers and encouraging the development of web and mobile applications, widgets, visualizations, and other integrations that benefit the platform...

IoT Extends Software Terms of Service And Licensing To Our Every Day Objects

04 August 2016
I find myself thinking about what the terms of service we agree to for online services are doing to our lives. Whether we see the effects or not, they are guiding almost everything we do in our personal and professional worlds. They are something that began on our desktop computers, migrated to our more mobile laptops, then deeper into our personal lives via our mobile smartphones. We rarely understand what we are agreeing to when we check the box for these terms of service, which leaves me really surprised to see us accept the application of terms of service to everyday objects we depend on, as part of the Internet of Things movement. As physical objects in our lives get connected to the Internet, they begin to generate valuable data, requiring software to manage--all being directed by the terms of service set forth by the manufacturer...

All Facts And Statistics Should Have An Interactive Experience Like US Census Bureaus Quick Facts

03 August 2016
I wish every time you came across facts and statistics in any news story, blog post, report, and beyond, there would be an interactive experience like you get with the US Census Bureau's QuickFacts tool.  QuickFacts provides statistics for all states and counties, and for cities and towns with a population of 5,000 or more, and provides everything I think you need to make the case behind any facts and statistics you are presenting. Using the tool you get a table, chart, map, data download, email results, and share via popular social networks as well as embeddable tooling. The QuickFacts experience should be a default for all storytelling around open data.  The Census team has clearly worked very hard to make a wealth of very complicated data much more accessible, usable, and easily understood through proven approaches to telling stories using open data...

Uses And Disclosures Of Protected Health Information (45 CFR 164.502)

03 August 2016
I am working my way through Title 45, which is the principle set of rules and regulations issued by federal agencies of the United States regarding public welfare. I've made my way through the security standards, and the breach notification portions, but can't help but feel that much of the "uses and disclosures of protected health information" section should be closely evaluated for consideration beyond healthcare. I am currently processing this, for use as building blocks in my privacy research: (a) Standard. A covered entity or business associate may not use or disclose protected health information, except as permitted or required by this subpart or by subpart C of part 160 of this subchapter...

Making Scientific Research More Real Time And Collaborative Using APIs

03 August 2016
I had heard about the Zika virus research that was going on at the University of Wisconsin listening to an NPR episode this last spring. I finally had the time to dig into the topic a little more, and learn more about where the research is at, and some of the software behind the sharing and collaboration around the research. The urgency in getting the raw data and results of the research out to the wider scientific community caught my attention and the potential for applying API related approaches seems pretty huge. When it comes to mission-critical research that could impact thousands or millions of people, it seems like there should be a whole suite of open tooling that people can employ to ensure sharing and collaboration are real time and frictionless...

Certifying The Network And Storage Is In Country Before We Adopt Internet Connected Devices

03 August 2016
I've been reading a number of stories about concerns within the Department of Interior about the usage of DJI drones as part of their UAV operations. Whether or not the federal agency actually issued a ban on using the drones is another story, regardless I wanted to extract this concept and apply to the wider world of Internet of Things, in which drones are definitely a poster child for. In our race to connect devices to the Internet, at the consumer and industrial level, what considerations are being made regarding what data is collected, how this information is transmitted (via which networks), and ultimately where is data being stored (which country). Obviously, this is something the federal government is beginning to think about, but I'm guessing hasn't fully formed an approach to dealing with this problem consistently across agencies...

The Opportunity For API-Driven Algorithmic Transparency At The Mobile Data Plan Level

02 August 2016
API Evangelist is focused on helping push for sensible API-driven transparency wherever I can get it. When done in sensible ways an API can crack open the often black box that is the algorithm, giving us access and more control over our online experience. One of the most significant algorithmic bottlenecks that govern our daily lives is our mobile data plans. All of our mobile phones are governed at the data plan level--this is where the telecom companies make their money, throttling the bits and bytes we depend on each day.  The mobile data plan is a great place to discuss the algorithmic and data transparency that APIs can assist with, and one example of this in action is with the Google Mobile Data Plan API...

Direct Government Connection Into Internet of Things Devices Like We Are Seeing With Drones

02 August 2016
I have been spending a lot of time this summer thinking about how devices are being connected to the Internet, specifically when it comes to drones. As I was traveling around the countryside flying drones, I increasingly came across stories about drones being a nuisance, and most notably being a big huge problem for firefighting crews.  I am flying a DJI Phantom 3 Professional drone, so I was interested to see DJI recently enable real-time geofencing capabilities for drone pilots. If you are unfamiliar with how these drones work, your drone controller is simply an iPad enabled joystick and a mobile application which becomes your control center. Before you can fly the drone the application goes through a whole series of checks making sure all of the drones variety of systems are all in check...

Getting Back To API Evangelist

01 August 2016
I am starting the process of getting back to work on API Evangelist, and wrapping up our Drone Recovery project. We will continue working on things throughout the summer, but I need to start looking at what's next for myself, and thanks to the API community, what I'll be doing next with API Evangelist.  Thanks to the generosity of the API community we were able to stay afloat while spending May through July hiking the hills of Oregon. We are now spending the final months of summer and fall, getting the kid on his feet in Portland, as well as figuring out what our own next steps are. Thankfully we still have an apartment to come back to, and I have API Evangelist domain to work under--I just need to figure out what is next for this production...

The Community Has Spoken: API Evangelist Will Stay As It Is

28 May 2016
I came out of the wilderness this week (literally, the Kalmiopsis Wilderness) to an inbox full of emails and a Twitter stream full of messages and DMs. I expected a little buzz from my exit, but not to the extent that it did, let alone the direction it took. I am incredibly humbled by the community's response, and honestly, I'm not well equipped to deal with this type of attention. I know there are some folks out there who think I am some sort of attention seeker, but that is the part of all of this that I really struggle with the most. I have to step aside from myself to be able to write. Otherwise, I'm left incapacitated. I am incredibly thankful for the API community. I have had the bar set pretty high for this community throughout the last six years, and you managed to raise it beyond what I had already set in my mind...

API Evangelist Is Up For Sale - Get Your Bids In By Friday

23 May 2016
It has been six years since I started API Evangelist. A personal matter has come up which will require my attention for at least six months, probably upwards of a year. Which in the tech world can be centuries--when you are dealing in real time.  With this in mind, I will be putting the apievangelist.com domain, and @apievangelist Twitter account up for auction. When I come back (if I do), I'm perfectly happy starting over, and I need all the funds I can get to get me through the summer, and API Evangelist is the only asset I own. I am very sorry for the impact on my business partners, but family and human beings come first, and I'm sure they will be fine. If you want the short and sweet on what I'm doing head over to kinlane...

The API Evangelist API Management Guide

12 May 2016
API management is the oldest area of my research. The area has been being defined since Mashery first opened its doors in 2006 and continues to be defined with the recent IPO by Apigee, and the entry of AWS into the sector with the AWS API Gateway. API management is often defined by the services offered by these companies, but also by the strategies of leading API providers in the space. My API management research walks through the common building blocks of the space, the open source tooling, and API service providers who are serving the space. I first started this guide in 2010 and 2011 and have worked to evolve with each release, as well as the fast pace change that seems to occur in the space...

Oracle vs Google: APIs Are Kind Of Hard To Understand

11 May 2016
One of the things that stood out for me reading through the Oracle v Google trial coverage today was Sarah Jeong's acknowledging how APIs are kind of hard to understand, and is something that is casting a shadow over the case -- something that is probably my top concern. The whole thing where APIs are kind of hard to understand — still casting a shadow over this case — sarah jeong (@sarahjeong) May 10, 2016 Also pointing out what I think is true of the Oracle legal team: I am not entirely sure this Oracle lawyer understands what an API is, I'm not entirely sure I understand what an API is — sarah jeong (@sarahjeong) May 10, 2016 While this might be more about bringing things down to a lower level for "normals", I think it still represents how difficult it is for people to grok what APIs are: jfc I think both sides have brought LITERAL PHYSICAL FILE CABINETS as visual aids to explain what a API is — sarah jeong (@sarahjeong) May 10, 2016 Then continuing with more of the skeuomorph theater: Google's has a big 8...

The API Evangelist API Design Guide

11 May 2016
In the last couple of years, I've seen the concept of API design go from being something the API elite discuss, to something that involves business users, and something that has spawned a whole ecosystem of service and tooling providers.  This API design research covers the concepts people often associate with API design, like REST, and Hypermedia, but also touches on other media types, API definitions, and many of the services, tooling and other solutions that have emerged to serve the space. I fund my research through consulting, selling my guides, and the generous support of my sponsors. I appreciate your support in helping me continue with my work and hope you find it relevant in your API journey...

Enabling A Patients HIPPA Right To Access Their Personal Health Information (PHI) With APIs

11 May 2016
I am reading through the API task force recommendations out of the Office of the National Coordinator for Health Information Technology (ONC), to help address privacy and security concerns around mandated API usage as part of the Common Clinical Data Set, Medicare, and Medicaid Electronic Health Records. The recommendations contain a wealth of valuable insights around healthcare APIs but are also full of patterns that we should be applying across other sectors of our society where APIs making an impact. To help me work through the task force's recommendations, I will be blogging through many of the different concepts at play In addition to highlighting the usage of "patient-directed APIs" that I wrote about earlier, and taking a healthy stance on privacy and security when it comes to healthcare APIs, I wanted to separate out the conversation around a patent's right to access their own personal health information, and how APIs are being used as the enabler...

A Healthy Stance On Privacy And Security When It Comes To Healthcare APIs

10 May 2016
I am reading through the API task force recommendations out of the Office of the National Coordinator for Health Information Technology (ONC), to help address privacy and security concerns around mandated API usage as part of the Common Clinical Data Set, Medicare, and Medicaid Electronic Health Records. The recommendations contain a wealth of valuable insights around healthcare APIs but are also full of patterns that we should be applying across other sectors of our society where APIs making an impact. To help me work through the task force's recommendations, I will be blogging through many of the different concepts at play.  Beyond the usage of "patient-directed APIs" that I wrote about earlier, I thought the pragmatic view on API privacy and security was worth noting...

Cutting Through The Smoke & MIrrors Of IT Discussions Using API Definitions

10 May 2016
I get brought into a lot of API discussions with IT departments from companies, institutions, and government agencies, which are often coordinated by business groups who are interested in better meeting their goals using APIs. This is often an immediately charged conversation, with IT coming to their table with a whole array of baggage.  In about 75% of the situations, IT, and developer representatives are nice, or rather they are tight-lipped, relying on a myriad of smoke & mirrors to defend their dark arts. Let me stop for a moment, and put out there that I was IT director from 1998 through 2010. I'm not saying IT are bad people, but there are a wide variety of ways we slow, obfuscate, and distort the conversation to be in our favor -- takes one to know one...

Twitter Collection Of @SarahJeong, @Xor & @Swiftstories Oracle vs Google Coverage

10 May 2016
The next round of the Oracle v Google Java API Copyright battle has kicked off again in San Francisco after being sent back to the lower court by the United States Supreme Court. This round is all about deciding if Google's usage of the Java API in their Android platform was allowed under fair use. If I was in San Francisco I would be there to hear the case first hand--I am lucky there are some really smart folks covering the case and live tweeting things. I went through the Tweets from Sarah Jeong (@sarahjeong), contributing editor at @Motherboard, Parker Higgins (@xor), EFF activist, and Mike Swift (@Swiftstories), Senior Correspondent for MLex. They are all providing some smart, and pretty amusing commentary on what is going on, so I wanted to organize the relevant Tweets into a Twitter collection summary for inclusion in my research...

The Concept of Patientdirected APIs

10 May 2016
I am reading through the API task force recommendations out of the Office of the National Coordinator for Health Information Technology (ONC), to help address privacy and security concerns around mandated API usage as part of the Common Clinical Data Set, Medicare, and Medicaid Electronic Health Records. The recommendations contain a wealth of valuable insights around healthcare APIs but are also full of patterns that we should be applying across other sectors of our society where APIs making an impact. To help me work through the task force's recommendations, I will be blogging through many of the different concepts at play.  One phrase that is used regularly across the task force recommendations that really caught my attention was the concept of "PatientDirected APIs"...

The API Evangelist API Definition Guide

10 May 2016
How we define our APIs has dramatically changed in recent years. Since Swagger came onto the scene around five years ago, there has been a rapid growth in the number of open formats, tooling, and services to help us define APIs. Companies are using API definitions like OpenAPI Spec, Postman, and API.json to communicate about their APIs at almost every stop along the API life cycle. This is my research to better understand all the moving parts in this fast growing sector. This guide focuses on API definition formats like OpenAPI Spec and API Blueprint, as well as schema formats like JSON Schema, and MSON, but I also touch on media types, link relations and other common building blocks for defining our APIs so they speak a common language...

Providing A Set Of API Keys For Developers To Test Out Different API Outcomes

09 May 2016
I wrote a post about Twilio using magic phone numbers that let their developers test out functionality without incurring any charges for deploying live phone numbers, making calls, and sending SMS. After publishing my post, Runscope CEO, John Sheehan (@johnsheehan) said he was behind the original spec for the Twilio magic numbers. @kinlane ha I wrote the magic numbers spec. The implementation was better than my design but it’s funny to see it recognized so much later — John Sheehan (@johnsheehan) May 9, 2016 John continued to share some of the logic that went into his original spec: @kinlane I borrowed the idea from payment processors using magic numbers to generate specific kinds of outcomes like declines — John Sheehan (@johnsheehan) May 10, 2016 Which I think adds another dimension to the concept of having test numbers like this...

APIs Will Wither On The Vine And Never Reach Their Full Potential

09 May 2016
As I push out stories on the next round of the Oracle v Google API copyright case, considering how I will write about API deprecations and acquisitions I'm privy to, and document the continued march by the enterprise into the world of APIs -- I begin to see how APIs will continue to wither on the vine, and never reach their full potential in an increasingly toxic environment. The Oracle v Google is just the first of many battles to occur between tech giants when it comes to APIs and the application of intellectual property laws. With the number of patents out there that focus on APIs as the thing that is protected by IP, not just the thing behind the API being protected, the copyright of the common API patterns we enjoy will just be the tip of the iceberg...

Quality of Service API Endpoint For Your API Platform

08 May 2016
I'm spending a lot of time in the Twilio API ecosystem this week, so you will hear multiple stories about what they are up to. This one is highlighting their Call Feedback API and the growing amount of what I'd consider as infrastructure APIs from leading API platforms. The more API platforms mature, the more I see APIs deployed to assist API consumers manage their integrations, as well as get a the core API resources being made available. Twilio's feedback API focuses on a single API resource, a call, but could just as easily be applied equally as a quality of service feedback endpoint for anything you are serving up, like video, bot responses, recommendations, and beyond. I like the idea of having one endpoint for serving up a resource, and another endpoint for reporting the quality of service around the resource...

An Acceptable Business Model Page For Your API Platform

08 May 2016
One thing I look at closely when I review API platforms is how they approach the monetization of their API resources, and the resulting plans, pricing, and access tiers. How platforms think about, and present this aspect of their operations provide a wealth of insights into what a company's motivations are behind their API operations. I found the approach by 3D printing API platform i.materialise to be an interesting approach which goes beyond just charging for API access and focuses on helping API consumers align their business model with i.materialises. i.materialise presents API consumers with two possible routes, with the first being referral based, and the second being a deeper, white label relationship...

Serverless Approaches To Deploying Code Will Help Unwind Some Of The Technical Debt We Have

07 May 2016
I am sure there is some equation we could come up to describe the amount of ideology and / or dogma present alongside each bit and byte of code. Something that exponentially increases with each additional line of code or MB on disk. An example of this in action, in the wilds of the API space, is the difference between an SDK for an API, and just a single sample API call.  The single API sample is the minimum viable artifact that enables you to get value from an API -- allowing you to make a single API request and receive a single API response. Very little ideology, or dogma present (its there, but just smaller quantities). Now, if an API provider provides you with a Laravel SDK in PHP, or a JAX-RS SDK in Java, and React...

Twilio Provides Test API Credentials With Magic Phone Numbers

07 May 2016
I am always on the hunt for the little things that make API integration easier, and while working to certify my Twilio API definition, I noticed their test credentials. When you are playing with the Twilio API, it's pretty easy to add new keys, and create new apps, but they also offering test credentials along with what they call "Twilio's Magic Numbers" so that you can play without connecting to real phones or making actual charges on your account. Many APIs provide you access to data or content, but Twilio enters the additional realm of much more complex, programmatic API resources. When getting up and going with these types of APIs, it really helps to have a sandbox to play in, and a ready to go set of test credentials provides this for users by default...

I Am Seeing Significant Returns From Investing In Definitions Over Code When It Comes To My API Strategy

07 May 2016
I am doing way more work on the creation of machine-readable OpenAPI Specs for APIs, indexed using machine-readable APIs.json files than I am the actual creation of APIs lately. About half of the API definitions I create are for existing APIs, with the rest of them describing APIs that should exist. With the existing APIs, in some cases, I am creating client-side code, but mostly just focusing on a well crafted API definition. When it comes to the new API designs, I am focusing on a complete API definition, but also crafting both server-side, as well as client-side code around the definition--when needed. Even when I do craft server or client code for an API definition, the value of the code is significantly lower than the definition(s)...

The API Evangelist API Deployment Guide

05 May 2016
There are many different ways to actually deploy an API. If you are a larger, more established company, you probably have existing tools, services, and processes set forth by IT for deploying APIs. If you are a startup, your developers probably have their own frameworks, or possibly a cloud service they prefer using. This guide looks to map out the world of API deployment, and some of the common ways companies, organizations, institutions, and government agencies are deploying APIs in 2016. This API deployment guide breaks out many of the common companies, and tools while also looking to identify some of the common building blocks employed by leading providers, in support of API deployment across organizations of all shapes and sizes...

APIs At Brigham Young University

03 May 2016
I have been tracking on how APIs are used in higher education for some time now, keeping an eye on almost 50 campus API related efforts. I have my University API guide that I regularly update, but I was eager to push forward my storytelling around what is going on, so I have been working on some papers telling the story behind some of the top higher ed API implementations which I have access to. What better way to kick this off, than to showcase my favorite campus API group, over at Brigham Young University (BYU). The team led by CIO Kelly Flanagan (@kelflanagan) have embraced APIs on campus in a way that keeps my excited about APIs, and what is possible. In my opinion, BYU isn't just using APIs to shift IT strategy at the school, they are using APIs to shift how their students and faculty see technology, and put it to work on their terms...

HTTP Header Awareness: Using The Link Header For Pagination

02 May 2016
I was revisiting the concept of pagination for a specific project I am working, and after consulting my API research, I came up with a suitable approach using a Link Header. Beyond applying this in my specific project, I thought the usage of the header for pagination would be a suitable topic for helping with HTTP header awareness -- a topic I will be writing about regularly, to help folks be more aware of useful approaches to using HTTP headers. Github has the best example of using the link header for pagination that I could find. Github uses the Link response header to hold a handful of Hypermedia link relations including next, last, first, and prev. Providing a nice way to handle not just pagination, but potentially any other related action you might want to take around an API response...

Thinking About An API Proxy To Add Link Header To Each API Response

02 May 2016
I was learning more about using the Link header for pagination yesterday, as part of my work on the Human Services Data Specification (HSDS), and this approach to putting hypermedia links in the header got me thinking about other possibilities. Part of the reason I was considering using the Link header for pagination on this particular project was that I was looking to alter the existing schema as little as possible -- I liked that I could augment the response with links, using the header. Another side thought I had along the way were around the possibilities for using it to augment 3rd party APIs, and APIs from an external vantage point. It wouldn't be too hard route API requests through a proxy, which could add a header with a personalized set of links tailored for each API request...

The JSON Schema Is Proving To Be As Valuable As The OpenAPI Spec

02 May 2016
As my API Stack work gets more attention, folks are reaching out to me to see if I have done certain APIs, or see if I'd prioritize some of the ones already on the list. One thing I'm also noticing is that people are often looking for the JSON schema of each of the API responses, just as much as they are looking for the OpenAPI Spec for the API surface area. I had someone looking for the complete schema for the Reddit API today, while I was working to authenticate, and record the responses to each endpoint for AngelList, AlchemyAPI, CenturyLink, NTT Docomo, Stripe, Twilio, and Verizon. An OpenAPI Spec for the request structure of an API will get you a long ways in on boarding and learning about an API, but you will need the schema to complete any integration...

Working To Establish A Complete OpenAPI Spec For Leading APIs

02 May 2016
I am always working as hard as I can to develop as complete as possible OpenAPI Specs for the APIs that I monitor. I call this my API Stack research. When possible, in addition to mapping out API operations for an API using APIs.json, I also work to create a machine readable OpenAPI Spec for each API. In most cases I only have the time to profile the surface area of an API -- the host, base url, all properties, and required parameters. I don't always have time to reach what I'd consider to be a complete API definition. This is something that takes authenticating, achieving a successful request and response for each endpoint present, then generating JSON schema for each response -- this takes a significant amount of effort to do properly...

The Month At A Glance, Road Map, Support, And The Recent Posts For Your API Platform

30 April 2016
I was playing with Microsoft's API Catalog, a tool to visualize and analyze the API overlap between standards specifications and type systems within browsers, and their footer caught my eye. I am always looking for quality examples of companies doing platform communications and support well, and I think their layout, and available building blocks in their footer, is worthy of showcasing. For me, these numbers, and the available communication and support building blocks, send the right signals--that a platform is alive and active. These are the data points I tune into, to understand how well a platform is doing, or not doing. There are no absolutes when it comes to this type of monitoring, as anything can be gamed, but sign Github activity, road map evolution, and blog storytelling can provide a vital heartbeat for any healthy API platform...

What Are The Most Relevant API Topics To Discuss At @APIStrat in Boston This Fall?

28 April 2016
We are picking up speed with the planning for @APIStrat in Boston this November, and with the event committee assembled, and the call for talks open, we are looking at what the possible topics are for sessions. We have seeded the list with the usual suspects like API design, management, testing, monitoring, and others, but we want to also consider what the alternative topics are, and what is relevant to the API sector in 2016.  What is most important to you in 2016? Is it the trendier topics like bots, voice, and IoT? Is it more practical things like evangelism, versioning, and discovery? Is it the technical, business, or politics of APIs that are impacting your operations most in 2016? If you want to come and present on it, make sure you submit your talk by May 20th...

More Patents Turning APIs Into An Invasive, Royalty Generating Virus

28 April 2016
The relationship between API provider and consumer is a fragile one. As an API provider I am offering up my valuable digital asset, data, content, and digital resources. I would like you to take this Application Programming Interface or SDK that I have built, and put it in your business systems and applications. As an API consumer, I'm given access to valuable business API asset, which I'm expected use in a respectful way, that is always in alignment with a providers terms of service -- an environment where so much can go wrong, and does each day. I watch companies take a wide range of tones when it comes to setting the stage for this relationship. Some companies are super protective of their valuable content (like Marvel Comics), some are very communicative and inviting like Slack (inject your bot into us)...

A Regular Reminder That Storytelling Is The Most Important Tool In Your API Toolbox

28 April 2016
I was reminded by my friend Mike Amundsen of the importance of storytelling in our world. When I am asked by anyone doing APIs, what is the most important thing they should be doing, my answer is always "storytelling". I don't care if its internally, publicly, on the corporate blog, or your personal blog, tell the story of what you are doing. I do not care how good your API is, if you aren't telling the story of this, nobody is going to care.  When I hold up storytelling as the most important tool in your toolbox within developer groups, they often snicker, dismissing it. I also have a contingent of my NOT fanbase in the API space who love to dismiss me with -- nobody reads or cares about stories! I'm never phased by these folks, my focus is on the people who are truly trying to build community, and reach their intended audience...

The Wikimedia Unique Devices Data API

26 April 2016
I came across the Wikimedia Unique Devices data set, which also is served up as an API endpoint, along with the other APIs the platform offers. The data set and API provides access to a list of unique devices that have visited Wikipedia, for a specific period of time. The data set and API only has data back to January currently, but I'm sure is something that will evolve over time. I really like the fact that we have organizations who are operating at scale, and are open and willing to share their data. This type of information is high value, and is something that can help us all better understand the ever shifting digital landscape around us--thank you Wikimedia for making accessible. While playing with their Unique Device API, I also noticed how transparent they are with their page view data, also making it available as simple set of API endpoints...

API Providers & Consumers Keeping In Touch Is How You Can Set The Right Tone For An API Community

26 April 2016
One of the side effects of the recent bot craze, is that I'm getting to showcase the often very healthy API practices of Slack, as they grow, scale, and manage their developer ecosystem. Slack is beginning to renew my faith that there are API providers out there who give a shit, and aren't just looking to exploit their ecosystems. There are two Slack blog posts that have triggered these thoughts, one on the Slack platform road map, and a little thing about release notes, both of which reflect what I would love to see other API providers emulate in their platform operations. Slack is going the extra mile to set the right tone in their community, with what I consider to be some of the essential communication building blocks of API operations, but they simply call "keep in touch": Recent updates - We improve the Slack platform every day by releasing new features, squashing bugs, and delivering fresh documentation...

Content That Lives On When You Invest In The Right API Stories, Training, and Guides

26 April 2016
I am working with my partner Cloud Elements to build out a community of evangelists, who are interested in delivering on many of the essential building blocks I track on when it comes to API evangelism. I get regular requests from companies who are looking for evangelism and advocacy resources -- in desperate need of smart folks who can help craft content, crank out code, in the service of evangelizing a platform. The work I'm doing with Cloud Elements, is the early work to help deliver on what API providers, and service providers are needing. Right now we are on-boarding new folks to the concept, and getting feedback on what some of the common elements, and challenges will be. One of the folks I'm engaging with on this is expert PHP and API developer, tech lead, author, consultant and open source maintainer, Lorna Mitchell (@lornajane)...

Vital Resources Like The Court Listener API Depend On Our Donations To Operate

25 April 2016
Despite popular belief in Silicon Valley, there are many different ways to fund the design, development, deployment, and operation of valuable API resources. Not all APIs are destined to be the next Amazon, Twitter, or even Twilio. Some APIs just need exist, be available, and will never be a revenue engine--one of these APIs is the Court Listener API. Version 3.0 of the Court Listener API possesses 15 valuable endpoints, providing access to courts, dockets, opinions, people, sources, ratings, and other details about how laws are made in the United States. With their latest release containing a comprehensive database of judges and the judiciary, to be linked to Court Listener’s corpus of legal opinions authored by those judges...

Slack Meets The Minimum Viable API Platform Requirements

25 April 2016
I am using my minimum viable API operations definition tool to continue profiling the API sector, this time to size up the Slack API community. Slack is kind of a darling of the API space, so it kind of seem silly to profile them, but profiling those who are doing this API think right, is what API Evangelist all about--whether I follow the hype or not. Using my minimum viable API definition, I went through the Slack API portal looking for what I'd consider to be the essential building blocks that any modern API platform should have. API Overview Name: Slack API Description: All of our APIs can be used alone or in conjunction with each other to build many different kinds of Slack apps...

OpenAPI Specifications For 642 Of The Schema.org Types

25 April 2016
I am gearing up for another wave of API definition work, so I am taking the opportunity to produce some more tooling that assists me in the process. One of the tools I want to build, is a simple solution for walking me through one or many OpenAPI Specs, and push me to make sure every parameter has a complete set of descriptions. I possess amazing powers of bullshit, and can craft default description for almost anything I come across, but it would be nice to have an an ever evolving autocomplete dictionary to augment my existing super powers.  I already have an APIs.json driven autocomplete tool, that loops through all the parameters within the OpenAPI Specs that are indexed. I just needed a rich set of fields and parameters to pull from -- Schema...

Using My APIs.json Annotation Tool To Drive An API Design Conversation Via Github Issues

23 April 2016
I am working on one possible API definition for the Human Services Definition Specification (HSDS), and the next phase of this work involves bringing in a small group of technical, and non-technical folks to have discussions around their API designs, in context of the master specification I am looking to pull together.  To help drive the discussion I am wanted to use the OpenAPI Specification that I created for HSDS, and I also knew I wanted to use Github issue management to help keep track of the synchronous, and asynchronous conversation that would occur around it. However Github tends to have a perceived barrier to entry for many non-developers (which I don't fully get), so I wanted to leverage the platform, but also soften the way everyone discussed the overall specification, as well as each individual endpoint...

I Like Working With JSON On Github Because CORS Is Never An Issue

23 April 2016
I tend to only work in environments where I have full control over the server, so Cross-origin resource sharing (CORS) is never really an issue for any of the APIs I have control over, but is a pervasive problem for APIs, and JSON files I come across on the web. This is one of the reasons I really enjoy the fact that I publish all of my JSON driven, hacker storytelling projects using Github Pages and Jekyll. In the last couple weeks I have been working on a bunch of micro tools that deliver specific functionality which can then be used throughout the API life cycle. All of these apps are developed using JavaScript, and depend on being able to read from any number of JSON file stores. Sometimes these files are stored within the project, but most likely I'm calling the remote JSON files of other projects, something that depends on the sharing of resources across domains...

I Am Working With @HitchHQ Team To Help API Providers Build Their Communities

22 April 2016
I'm always on the hunt for like-minded folks who I can partner with, and bring needed products, services, and tools to the API space. If someone is selling something to the API space, its likely I have had a conversation with them about the sector at some point. I always enjoy these regular encounters, but its the handful of them that continue, and evolve into deeper relationships that I enjoy the most. One of most recent relationship which I have been cultivating, is with a new API startup called Hitch. I have a long history with both the founders Bruno Pedro (@bpedro) and Luke Miller (@lukeam), in their previous lives with API Changelog and 3Scale, but began talking with them more heavily bout their vision for Hitch earlier this year...

Helping Folks Leave Their Platform and Language Baggage At Home Using API Definition Formats

22 April 2016
I was just participating in an interesting conference call about multiple API implementations, which are putting the Human Services Definition Specification (HSDS) to use. The call was brought together discuss a shift in the current path one of the projects was taking, which involved using Azure Search Service, and whether or not the original vendor solution was still necessary, because the cloud solution appeared to meet all their needs. I sat and listened to the pros and cons of each approach. Why Azure allowed them to quickly meet the project needs, and could scale. Why the other vendor solution had a more holistic view of the problem, and shared the investment from many implementations...

Empowering You To Make Informed Decisions Around Your Information Is What The Personal API Is About

22 April 2016
My friend Tom Woodward is continuing his personal API journey on his blog, sharing more of his thoughts around taking control over his information, and sharing some of the conversational exhaust that his journey has generated. The conversation around what what is "personal API", is where the value in all of this for me, something that is full of endless perspectives, and views of what APIs do. Which is one of the things I truly love about APIs, as they mean so many different things to different folks. As i mentioned before, when I mention the concept of personal API to some of my engineering friends, they seem to always focus on people designing, developing, and operating an API stack on their own server, or at home...

API, RSS, and The Ability To Look At Your Company Through An External Lens

21 April 2016
A  huge pet peeve for me is when a company has a blog, but not provide an RSS feed--it really grinds my gears! Although it is something that aggravates me, I understand many of the reasons behind it. People just don't see their blog through an outside lens. They visit other company blogs when they want to read them, usually via a bookmark, or possibly rely on an email digest once a week--they aren't RSS reader users. RSS consumers were always a niche (that almost went mainstream), but is one that has taken a big hit with the closing of Google Reader. I'm sure most of the companies would immediately turn on an RSS feed if I dropped them an email, but I'd rather write about it, and reach just the cream (my readers) on top of the API space...

Sizing Up The i.Materialise 3D Printing API With My Minimum Viable API Operations Definition

21 April 2016
I always have an inbox full of requests from companies asking me to take a look at their APIs, and provide any feedback that I can. I do conduct a more formal review for some companies, but I also enjoy looking through the API operations of any API, just as part of my regular monitoring (if I have time). When I do have time, the first part of any scope of review, is to see if it meets my definition of a minimum viable API operation. This is a definition I've been refining for over five years now, looking through thousands of APIs. Even with all this refinement, I still need a single place I could go, and quickly apply to any of the APIs that are in my review queue. My objective in doing these reviews is partly to help me get to know what an API does, but also provide feedback to the API providers, as well as generate stories that I can share with my readers, helping them polish their own strategy along the way...

The Average Person Will Never Care About Their Digital Stuff Enough For Personal APIs To Be A Thing

19 April 2016
I've heard the same thing for years--that the average person will never care about their digital stuff enough to ever want to learn about APIs, let alone for the concept of the personal API to ever be a thing. People love to comment, and tweet it at me anytime I talk about evangelizing APIs to normals, about reclaiming your domain, or the concept of the personal API.  First off, you aren't original. IT has been telling the normals to not worry their :pretty little head" about the technical details for many, many years. It is how those with the power stay in power. If people are technically literate, and we built simple technology solutions for people, they wouldn't need us, or buy our bullshit...

Competing Views Around The Value And Ownership Of Digital Resources Impacting API Security

19 April 2016
I was reading a post about how having an unclear sense of ownership hurts API security, which showcases the different views on who owns security, when it comes to exposing corporate digital assets via APIs. When I read the title, I anticipated the story being about a difference in how ownership of the asset(s) itself is viewed, but it ended up focusing on the ownership of security itself, not ownership of the assets which are being exposed -- something I think gets closer to the root of the problem, than who "owns security".  In short, the IT and developers who are often charged with exposing corporate assets via APIs will view those digital resource in some very different ways, than other people at the company...

The Pricing & Plans For 250 API Platforms

16 April 2016
I track on the API operations of around 2000 companies. Honestly, most of the 10K+ APIs in the ProgrammableWeb API directory have long been gone, deprecated, acquired, and had the lights shut off. There are only a couple thousand companies, institutions, organizations, and government who are doing public APIs, with only a couple hundred doing them in an interesting way. This should not diminish the API conversation, as public APIs are just one aspect of the API discussion, and honestly it is one are that not all companies and organizations will have the stomach for. However, a certain amount of available public APIs will always play an important role in setting the tone for the entire API space, providing us with a (hopefully a diverse amount of) lead(s) when it comes to crafting our own strategies for operating our businesses on the Internet...

Providing An Approved Developer Catalog For Your API

15 April 2016
I was going through the Expedia Affiliate Network again yesterday, as part of my Travel Stack Network work. Having individual research projects that pop up on my radar, and force to me take a fresh look at API providers is a huge part of what I do. As I was going through their portal, taking a fresh look at things, their approved developer catalog was something that stood out for me. A list of approved developers for any API is something I get asked about fairly regularly, so I want to keep referencing examples when I come across in the wild. Each developer entry in the catalog has the following details: Logo - A company logo, or photo of individual developer. Name - Name of the company or devloper...

Making The Right First Impression With Your API Developer Signup Email

15 April 2016
I sign up for a lot of APIs, and I am always surprised at what I see, or don't see, when I first signup for an API service. Personally I really enjoy the ones that have a simple, getting started formula to their signup emails. I signed up for Rosette a text analytics API yesterday, and I thought their registration email was a good example of this. This is all I do in the space, is explore, and experience the various APIs available today, and share my thoughts about what I see. I'm looking to organize these elements, into best practices that I can share with other companies as they work on their own strategies. Oh, I also look to apply some of these to my own operations -- I know my registration process needs some love too...

Staying True To My API Core And Seeing Bots As Just One More Design Constraint

14 April 2016
Over the last five years many of us have been pushing forward our API design skills to deliver valuable resources to mobile apps. The multi channel opportunity for delivering data, content, and other resources to not just websites, and web applications, but also to iPhone, Android, Windows, and other mobile platform is clear. Alongside delivering web apps to multiple browsers (IE, Chrome, and Firefox), we had to learn to deliver to an increasingly diverse mobile ecosystem (iOS, Android, Windows). When you have an API core, crafting new endpoints that speak to new channels is not as daunting of a task. I'm thinking through how to deliver API Evangelist knowledge into a Slack channel, Facebook Messenger discussions, and via Alex Voice for use at our APIStrat Conference in Boston this fall...

Formalizing My Approach To Identifying The Low Hanging API Fruit

13 April 2016
I get approached by folks all the time who are looking to do APIs at their company, organization, institution, or government agency. The reasons behind these desires to do APIs vary widely. Some want to do API to deliver a specific web or mobile app, while many others just understand they need to get started somewhere, but are unsure of exactly where to begin with this daunting, never-ending task.  In these situations I always tell people to start with the low hanging fruit, which means, if its already on your website, it should also be available as an API. If you are publishing data or content to your website, as HTML, CSV, XML, XLS, or JSON, you should have available via an API. The average company has a mess of information made available via a website, and the API journey is about untangling this mess, and make it available for not just the web, but also mobile, messaging, bot, voice, and other emerging channels in which people are getting their information...

Using Forms As An Introduction To World Of APIs For Normals

13 April 2016
I am working to identify the low hanging fruit for deploying APIs at Davidson College. It is a process where I target the domain, at the request of someone on campus, then slowly spider the website over a couple week period, and identify CSV, XML, XLS, and JSON files, as well as any tables with over five rows--now I"m also tracking on the presence of any HTML form.  At the same time I'm talking with Form.io about some of their case studies and client implementations, working to better understand how their form-centric API solution is making an impact with small business owners. Form.io lets anyone built forms, which then does all the heavy lifting of deploying an API that drives each of the form implemented...

Some Of The Common Building Blocks Of API Deprecation

13 April 2016
I spend my days mapping out the API life cycle, keeping track of what I consider to be the 50+ areas of a modern API life cycle, based upon the approach I am seeing from leading providers. One area of this life cycle I'm spending way more time than I want to be lately, is in the area of API deprecation.  This is why I conduct my API research in the way that I do, because when people approach me for advice, guidance, or brain dump in any of these areas, I have a wealth of resources I can pull from. Sadly I have a couple of folks ask me for input on what I'd consider to be a good approach to individual API deprecation, as well as entire company, platform, and API deprecation. Sadly, there very few "good approaches" to shutting down your APIs in the wild...

Developing API Tooling For The Average Business User Over At Form.io

12 April 2016
When I am review API services and tooling, the majority of what I see is targeting the API elite, the most technical, and specialized of us in the API space. Rarely do I come across approaches that really speak to the average business person, but each time I talk to the Form.io team I am reminded that these tools can, and do exist in the wild.  I get regularly walk through from the team, so what they do is no surprise, but each time I see it in action, I'm moved by what is possible, and the inroads they are building into everyday businesses. Using Form.io you can build forms, but these aren't forms, they are apps, and they are APIs, as well as being a form. When you are building a form, you are building an API, and when you hit publish, it publishes the API, with the form as the first web or mobile app that is consuming the API...

API Deprecation Art

12 April 2016
I'm in the middle of a sprint, where I am going through 50 of my main API stacks, to see what has changed, and who is still home. I'm always fascinated by the number of APIs that just fade away into a 301 redirect to a domains home page. Some projects get gobbled up by domain squatters, where others almost rise to the level of API deprecation art. I might get this one framed. I thought the background, combined with the message was a great representation of the current state of API affairs. Its getting harder and harder to operate an API, keep it up and going, and live up to the hype and expectations. I am going to start saving more snapshots of what happens when an API goes away--who knows maybe some day I'll have an interesting collection...

The API Purgatory Museum

12 April 2016
While I am on the subject of API deprecation, showcasing some of the interesting ways folks deprecate their APIs, I want to actually send out a message to API operators, that if you are considering, preparing (or not preparing) to deprecate your API, I wanted to talk with you including it in the API Purgatory Museum.  I was joking about missing Google Wave today, as I read about the army of bots, and bot platforms today, which resulted in Stefano Buliani jokingly asking about my API purgatory list.  @kinlane @dberkholz think there should be an API purgatory, do you have the list? — Stefano Buliani (@sapessi) April 13, 2016 Which is something that actually isn't a bad idea...

Do You Have All The Links To Pricing, TOS, And Other Critical Info For The APIs You Depend On?

11 April 2016
I was going through the list of APIs that I depend on, auditing the services that I'm paying for, and trimming the budget where I can, a process that involves spending time on the pricing and plan pages for the APIs I pay for--understanding pricing. I have all of my internal APIs defined as an APIs.json collection, as well as the 3rd party APIs which I depend on. This allows me to easily navigate all the moving parts of these APIs, and quickly get at what I need during times like this. As I was browsing the pricing pages, and evaluating the replacement of a couple of these systems I wanted to better understanding the terms of service, and licensing for these APIs I am employing. I try to keep the legal department for all of the API I use indexed with APIs...

Using APIs To Provide Building Blocks For Still And Motion UAV Imagery Media Applications

10 April 2016
I see a lot of APIs in my daily work. The diverse number of ways in which APIs are being used is one of the things that keeps my ADD brain interested in all things APIs. While the technical, business, and politics of the API game infinitely has ways to keep me paying attention, I find myself engaged more lately, not just for the belief in the potential of APIs for good, but around the potential for misuse--at a troubling pace.  Increasingly I am stumbling across API implementations, that when I am initially learning about, the 12 year old boy in me is immediately interested, but then the 43 year old skeptical in me recoils, like I am seeing a car accident on the highway. Insitu's Tungsten Software Development Kit has this effect on me -- Insitu makes technology for unmanned aerial vehicles (UAV)...

Playing With One Possible OpenAPI Spec For The Human Services Data Specification (HSDS)

09 April 2016
As I was preparing for my talk with Dan from Open Referral, I published some of my thoughts on the organization, and the Human Services Data Specification (HSDS). One of the things I did as part of that work was generating of a first draft of an OpenAPI Spec for the Open Referral API. To create that draft, I used the existing Ohana API as the base, exposing the same endpoints as they did in the Code For America project.  Over the last couple days, I spent some more time getting to know the data model set forth by HSDS, and got to work evolving my draft OpenAPI Spec to be closer in alignment with the data schema. To do this I took the JSON Schema for HSDS that was available on the Github, and generated used it as a framework to add any missing elements to the API definition, resulting in almost 70 API paths, in support of almost 20 separate entities dictated in the HSDS...

Providing Specialized Views Of An API Surface Area Dynamically With OpenAPI Spec And Liquid

09 April 2016
I just published the OpenAPI Spec I just created for the Human Services Data Specification (HSDS) into one of my default portals, which once the OpenAPI Spec is indexed via the portals API.json, I get a ready to go landing page, documentation, and other tooling for supporting the API. I have been pushing forward my API documentation, beyond the (now) standard issue Swagger UI, keeping the OpenAPI Spec core, but evolving the UI portion using Jekyll and Liquid.  I have a default API docs implementation, which loops through all OpenAPI Spec included within a project, and renders HTML documentation for each path, verb, etc. I'm still working on how I recreate the dynamic functionality brought to the table by Swagger UI, but so far I'm really, really enjoying the flexiblity with the user interface, and overall experience I get using this approach--I know the interactive portion will come...

My API Life Cycle Research From Design To Deprecation

08 April 2016
It always makes me smile, when I talk to someone about one or many areas of my API research, sharing how I conduct my work, and they are surprised to find how many areas I track on. My home page has always been a doorway to my research, and I try to keep this front door as open as possible, providing easy access to my more mature areas like API management, all the way to my newer areas like how bots are using APIs. From time to time, I like to publish my API life cycle research to an individual blog post, which I guess puts my home page, the doorway to my research into my readers Twitter stream, and feed reader. Here is a list of my current research for April 2016, from design to deprecation...

We Are All Responsible For Freemium Not Working

08 April 2016
I had another conversation with an API service provider today about their freemium accounts not converting. I've been sharing my thoughts about these freemium service account conversations, as I work to understand a shift that is occurring, and what my own feelings are. At this point, I feel like we (providers and consumers) are all responsible for freemium not working, than it is about the concept itself not working. Some of the poor behaviors of service providers: No Business Models - Everything being free, and not having a coherent business model. No Ascension Possible - There is free account, maybe one more paid level, then unobtainable beyond. Credit Card Trap - Requiring credit card on demos, trials, without easy way to not be billed...

Example Of API Service Providers Making Onboarding With Services Easier Using API Definitions

08 April 2016
API definitions like OpenAPI Spec, API Blueprint, and Postman, have been gaining in popularity over the last couple of years, mostly because of the their ability to deploy interactive documentation like Swagger UI. However, the API providers who have been using them the longest, have also realized these machine readable definitions can be applied effectively at almost every step along a modern API life cycle, from design to deprecation. I'm always encouraging companies, who are selling software services to the API space (aka API service providers), to make sure and have APIs for their entire stack, as well as speak in as many of the leading API definition formats as you possibly can. To help in this effort, I try to regularly showcase the API service providers who are doing it right--this round, its the folks over at APImetrics...

A Rogue Embeddable Button For Snapchat

08 April 2016
I see quite a few rogue APIs, and often rogue SDKs, but this is the first time I've come across a rogue embeddable button. While browsing Product Hunt this morning I came across this rogue Snapchat embeddable button, which allows you to promote your Snapchat account on any website. It just makes me sad that platforms don't just ignore platform fans and advocates like this, but actively work to lock things down to prevent this kind of serendipity from happening. Why would you want to shut down people who are looking to promote your tool? You should be enabling them. If Snapchat had a proper API portal, they would take this signal, internalize it, and turn it into an official set of embeddable tools for the messaging platform...

The API Assertions We Make, Believe In, And Require For Our Business Contracts

08 April 2016
I am spending time evaluating the evolution of the three applications offered by Restlet, as they work to bring the experience across API Spark, Restlet Studio, and DHC, into closer alignment. To describe what Restlet does in my API terminology, API Spark is an API deployment solution, Restlet Studio is an API design solution, and DHC is an API client solution. These are extreme simplifications, but helps me keep the fast moving API space somewhat organized (for me), and helps me share stories that (hopefully) make sense (for you).  Every couple of weeks I spend an hour or two talking with Jerome Louvel (@jlouvel), the founder of Restlet, about their road map, and where the wider API space is going...

Slack Nails The Reasons Why You Open Up And Share Your API Road Map

07 April 2016
Many of the core areas of my API research, and the common building blocks of the API life cycle that I talk about regularly, often seem trivial to the technically inclined, or the purely business focused segments of my audience. To many, having a road map might be a thing you have when developing and deploying an API, but really doesn't matter if you share publicly. I'd say, with technical folks they often don't even think of it, with the more business focused individuals often deliberately choose not to, seeing it as giving away too much information to your competition.  I think Slack nails the reason why you want to open up and share your API road map. I can talk about this kind of stuff until I'm blue in the face, but people just don't listen -- they need leadership like Slack brings to the table...

I Have An API, Now I Need Some Help to Identify What Is Needed To Manage My API Presence

07 April 2016
It is pretty easy to design, define, and deploy APIs these days, and I get a number of folks who approach me with questions about how to get going with the operations and management side of things. While each company, and API provider, will have different needs, I have a general list of the common building blocks used by the leading API providers I track on across the API sector. So that I have an up to date URL to share with a couple of my partners in crime, I wanted to organize some of the common building blocks across my almost 50 areas of API research, into a single list, that can be considered when anyone is planning on deploying an API. For this guide, I wanted to touch on some of the building blocks you should consider as part of your central API developer portal, documentation, and other elements of the management and operations, what I feel should be a minimum viable presence for successful API providers...

Some Very Different Views Of What API Are And What APIs Can Do

07 April 2016
I am regularly reminded of the wide spectrum of what API means to any single person. What is API, and what APIs enable, are all in the eye of the beholder, with only a handful of common aspects shared by any single group of people. This is one of the things that make it very difficult to answer the common newcomer question of where they should start with APIs. This is what makes it so difficult for APIs to ever rise to the expectations of leading architects, and API visionaries. For me, APIs are about enabling API providers to open up access to their resources, and empower API consumes to get at the resources they need to be successful in their every day worlds. Some folks out there enjoy regularly reminding me that APIs are not for everyone, and they should only be used by a handful of sanctioned tech practitioners, to facilitate the technical, business, and political / ideological motivations of these per-ordained--my dreams of enablement and empowerment are nice, but they are just not reality...

I Have An API Deployed, And A Base Presence Established, What Can I Do To Help Me Get The Word Out?

07 April 2016
To augment my last post about when you have an API, but you need some help to identify what is needed to manage your presence, I wanted to talk about some of what you can do once you've established your base API management, operations, and presence--now you need to get the word out, and get people using your APIs. Whether your APIs are intended for a public, partner, or internal group, there are many well established techniques, that are employed by successful API platforms, that you can employ. When I first sat down to write this guide, I was going to label it simply as API evangelism, but after pulling together the building blocks that I needed from across my research, to support a specific point, I shifted to make sure it was more of a week to week guide of things that should be considered...

That Thing You All Are Doing With Slack Integrations, @Blockspring Is Doing It With Spreadsheets

07 April 2016
One common thing you hear from the growing number of integrations and bots that are leveraging the Slack API, is all about injecting some specific action into the platform and tooling, we are all already using. Startups like Current, who are providing payments within your Slack timeline, use the slogan, "transact where you interact". I began to explore this concept, in what I call API injection, and is something I'm sure I'll be talking about over and over in the future, with the growth in bot, voice, and other API enabled trends I am following. The concept is simple. You inject a valuable API driven resource, such as payments, knowledge base, images, video, or other, into an existing stream, within an existing platform or tool you are already putting to use...

If Your API Is Worthy Of Mentioning In Your Press Release It Should Also Be Linked On Your Website

06 April 2016
I process many press releases to feed the of API.Report beast. The primary reason I do this work each week, is to identify new APIs, being done in interesting business sectors. One common thing I see, is companies that reference their API in their press release, and when I head over to their website -- no API, or information to be found.  Ok, I only spend about 30-60 seconds looking for a link to a dedicated API area, but its pretty clear that people either haven't though making it accessible, or are holding their cards close to their chest. I'm sure there are a whole spectrum of reasons why people do this, but it just doesn't make sense for you to talk publicly about your API, while also making it so difficult to learn more--it is not very API-like...

APIs Needs To Augment My World With A Tangible Benefit In Order To Achieve Relevance

05 April 2016
I am spending time talking to more API providers, and API service providers, about the challenges they are facing, while reaching out to potential customers, thanks to the support of my partners Cloud Elements. One of the conversation I had last week was with Diego Oppenheimer (@doppenhe) of Algorithmia (@algorithmia), who shared with me the challenges he faces in getting senior engineers to realize the potential of APIs, and the  value API driven platforms like Algorithmia bring to the table.  Diego expressed that the biggest thing they face is convincing their engineer, senior dev, and other tech-focused consumers, that Algorithmia isn't just something new they need to add to their existing stack, and that it is more about enabling what is already in place...

API Integration Service Providers Should Have An API So That Their Actions Are Embeddable

05 April 2016
During the latest IFTTT flareup, I realized how much I haven't written about my feelings surrounding API integratio service providers, iPaas, or whatever else you call it. Something that always frustrates me in the future, as I am unable to reference my earlier thoughts with a specific URL. So while I am ranting about the lack of APIs for these integration platform as a service (iPaaS) provider, let me add to my list of critical elements I feel are missing from the space: Embeddability! As a user of your service, provide me an API, so I can embed your API recipes into any website, web and mobile application. While the fact that Zapier does have a public API, where IFTTT does not have one at all, the Zapier API doesn't not provide me any access to what API integration recipes (Zaps) are available (ie, core business value)...

Who Is Working On The Twitter Cards For Slack Messages, Unfurl, and Attachments?

05 April 2016
As I study the approach of bot, and messaging platform integrations like Current, I keep thinking about the potential for API injection at this layer of messaging. In this scenario I am thinking about Slack, and how you craft messages, approach the unfurling of links, and customize attachments. I am envisioning a Twitter Cards, but a more open approach, that can help companies deliver nice looking, well designed, and media rich messages that deliver what messaging users are looking for. The service would be cross platform, allowing me to design for Twitter Cards, Slack Messages, or any other messaging platform that finds its 15 minutes of tech fame. With just a little bit of exploration of how to craft a good looking, and functional Slack message, I can see this being a full time job for someone...

The API Integration Providers Who Have API Access to Actions Will Be Successful In Bot Environments

05 April 2016
It has been acceptable for integration platform as a service providers (iPaaS) like IFTT and Zapier to focus on delivering the end-solutions that their consumers have needed, and requiring them to visit your domain to discover and then make the magic happen. While I have always been an advocate for more accessibility, I have to admin that the current "closed" approach has brought a number of new people to the world of APIs, as people realize that IFTTT and Zapier are possible because of APIs! However to me, it is a no-brainer that if you build a business on top of public APIs, you should pay it forward by providing an API, but I understand many of you startups follow a different philosophy than I do...

Hello Pinboard Customers, From Linden Tibbets, the CEO of IFTTT

31 March 2016
Here is the email I received from the CEO of IFTTT, in response to the whole Pinboard kerfuffle, a few minutes ago. It looks like they've done a little soul searching, and wanted to apologize: Hello Pinboard Customers,  We've made mistakes over the past few days both in communication and judgment. I'd like to apologize for those mistakes and attempt to explain our intentions. I also pledge to do everything we can to keep Pinboard on IFTTT. IFTTT gives people confidence that the services they love will work together. There are more services in the world than IFTTT can possibly integrate and maintain alone. We are working on a developer platform that solves this by enabling service owners to build and maintain their integration for the benefit of their customers...

Gathering My Thoughts About Open Referral And The Human Services API

31 March 2016
I am working on several very rewarding API efforts lately, but one I'm particularly psyched about is Open Referral. I'm working with them to help apply the open API format in a handful of implementations, but to also share some insight on what the platform could be in the future. I have been working to carve out the time for about it, and finally managed to do so this week, resulting in what I am hoping will be some rewarding API work. As i do, I wanted to explore the project, work to understand all the moving parts, as well as what is needed for the future, using my blog. I am not recommending that Open Referral tackle of all this work right now, I am just trying to pull together a framework to think about some of the short, and long terms areas we can invest in together...

Where Do I Start With APIs? The Independent Liberal Arts College Edition

30 March 2016
I'm engaging in another conversation with a higher education institution about where to start with APIs on campus. A new CIO has assumed a leadership position, and some very forward thinking folks on campus asked me to come visit, talk with IT about APIs, and try to understand where they can get to work with APIs on campus--a perfect opportunity to get to work developing an API culture at Davidson College. As their Twitter profile says, "Davidson is a highly selective independent liberal arts college committed to access and equal opportunity." Sounds like a rich environment to get to work empowering students, teachers, and faculty using APIs. Which leaves at the familiar place of being asked by folks on campus, where do we start with APIs? First we need a place to coordinate the getting started with APIs effort at Davidson with: Creating a Github Repo - To help facilitate the discussion, as well as store any code, data, and content that is generated...

Best Buy Will Not Issue API Keys To Free Email Accounts And Wants To Get To Know Your Company

30 March 2016
Best Buy is one of the many of the recent responses I am seeing from public API providers, as they work to strike a healthy balance within their API community. In an attempt to incentivize the behavior they desire within the Best Buy API community, the platform will not be issuing API keys to any email address that comes from the popular free email platforms (@google.com, @yahoo.com, etc.). While I hate seeing any public API access be tightened up, I can't help but sympathize with their move, and I have to support any API providers who works to set a healthy balance within their communities. While I am not sure limiting access based upon email account may not be the solution they are looking, they hit all the right notes for me: Develop Human Relationships >> If we want to have a better relationship with you, our active users, we need to make better connections between your alpha-numeric key and the services we provide to you Respect For What You Build >> If we disable a key because the email address is old, we may break an app...

I Am Seeing More API Platforms Manage Their Blog Presence Using Medium

30 March 2016
One thing that struck me as I wrote my post about Best Buy stopping issuing API keys to free email accounts, was the fact that Best Buy operates their developer blog on Medium--something I am seeing more of. As I discover new API-centric companies via my blog, Twitter, Product Hunt, AngelList, and the many other ways I tune into the space, I'm seeing more companies operating the blog portion of their presence in this way.  One of voices in my head points out that this just doesn't seem like a good idea. It reminds me of hosting our blogs on Posterous. Medium doesn't let you map your domain, or sub-domain to your blog (invite only), but I'm sure is something they'll do soon. They don't have RSS, and they don't have a read API either? *warning bells*  While I get the Medium thing, it seems like one of those neatly tended gardens, where as many roads out are gated off with friendly hand-painted signs...

Managing Your API Terms of Service And Privacy Policies On Github Like Medium Does

30 March 2016
I always dig it when API stories spin out of control, and I end up down story holes. I'm sure certain people waiting for other work from me do not appreciate it, but these are where some of the best stories in my world come from. As I was writing the story about Best Buy limiting access to their API when you have a free email account, which resulted in the story about Best Buy using Medium for their API platform blog presence, which ended up pushing me to read Medium's terms of service. Anyways, to help manage the evolution of the terms of service, privacy policy, Medum uses Github to establish a historical record of all the changes to all legal documents that impact platform, and API operations...

The Annotated Code Walk-Throughs and Tutorials Over At Twilio

29 March 2016
I am always trying to identify the common building blocks employed by leading API providers, and Twilio is one of the usual suspects I showcase. This time it is focusing their annotated code walk-throughs and tutorials, which provides a pretty good model that other API providers can follow when planning their own tutorials. Twilio offers up a tutorial for almost every API endpoint they offer. Some of the more popular tutorials have versions for almost every programming language, while some of the lesser traveled ones only have a single version. Once you click in to each tutorial, it delivers as the title implies, an annotated walk through, showing you how to get up and running, making the API call, in the language of choice...

The Lack Of An API And Healthy Partner Integrations Is An Early Warning System For Service Providers

28 March 2016
I was disappointed to see the email in my inbox this morning from IFTTT about their Pinboard integration. I also helped amplify Pinboard when he was Tweet'n up a storm earlier, and I recommend you read his post: My Heroic and Lazy Stand Against IFTTT. However I had work to get done on an essay about the API effort over at Brigham Young University, and prepare for some meetings I have this week around the Open Referral API definition, to help people find government services--IFTTT bums me out, but priorities. The loss of Pinboard integration in IFTTT sucks, but there is always Zapier. ;-) I began moving away from my IFTTT support back in 2014, after I began seeing their lack of an API, and the absence of a forward-facing business model, as an early warning sigs about the sustainability of IFTTT as an service provider...

Exploring A New Way To Fund API Life Cycle Tooling By Open Sourcing The API Garage

28 March 2016
The news out of Runscope makes today a good day to kick off discussion around a project that I've been helping push forward with the API Garage team, assisting them find the healthiest path forward for their API client tooling. As Runscope demonstrates, it is a tough time for API startups, something that adds fuel to my personal mission to do what I can to help startups find success.  First, what is API Garage? It is one of the HTTP / Web API Client tools available today, including Postman, Paw, DHC, and Stoplight. API Garage is an Electron based solution, you can download and put to work in helping you integrate with web APIs, allowing you to make calls, see the requests / response, all without having to write code...

Some Milestones From The Last 15 Years Of Web API History

27 March 2016
History is everything. Understanding where we have come from is critical to knowing where we are going. While pushing forward with the latest technology, it is always healthy to pause and take a look at that past. Someone Tweeted the link to my history page, and I realize it has been three years since I refreshed my view of the overall history of the space, so I wanted to take some time and add a few other milestones that I feel were significant along the way. When I talking about APIs, I'm focused one version that was born out of the enterprise, during the Service Oriented Architecture (SOA) movement, which sometime around 2000, a portion of the SOA experiment left the enterprise and found a more fertile environment in the world of start-ups...

This Is How APIs Will Deliver The Change We Need

27 March 2016
I recently caught a glimpse of how APIs are going to deliver the change we need in this world. It began while I was attending a gathering of indie ed-tech folks on the campus of Davidson College in North Carolina. Where 20-30, mostly non-developers, discussed what is indie ed-tech, something which included many visions of what was dubbed "the personal API". While the gathering was very enlightening, it was what this gathering has set into motion, after we all parted ways, that I think has the most potential Since the gathering occurred, a rolling wave of API driven awarenss has been picking up speed, with Indie Ed Tech, Colleagues/Friends, APIs, Unexpected Emergent Ideas, and dot dot dot and Can The JED-API Power a Certification with a fellow who barks about and plays with web tech...

The More I Gather OpenAPI Specs The More I Realize How We Obsess Over The Unecessary

25 March 2016
I spend a lot of time gathering, creating, and organizing machine readable OpenAPI Specs, as part of my API Stack, and personal API stack work. I'm not insane enough to think I can create OpenAPI Specs for all of the public APIs out there, I'm just trying to tip the scales regarding how many API definitions that are out there, to increase the usage and value of open tooling, which in turn will increase the number of people who will create their own OpenAPI Specs. (just kind of sort of insane) As I do this work, I realize how easily I can obsess over unnecessary, and meaningless metrics and goals in the tech space. Two things have stood out for me as I do this work: Overall Number of API Specs - Much like our obsession over the completely meaningless and incorrect number of APIs that are in the ProgrammableWeb directory, the number of OpenAPI Specs means nothing...

The Unintended Consequences Of API Patents

25 March 2016
As I was reviewing patent #20160070605: Adaptable Application Programming Interfaces And Specification Of Same, from yet another person I know, after I pick my head up off the desk, I begin thinking about all of the unintended consequences of API patents. Here is the abstract from this work of beauty: Aspects of the disclosure relate to defining and/or specifying an application programming interface (API) between a client and a computing device (such as a server) in a manner that the client, the computing device, or both, can evolve independently while preserving inter-operability. This is something that WE ALL should be building into our clients, and is fundamental to all this API shit even working at scale...

FullContact But For OpenAPI Specifications

25 March 2016
I get these regular updates from FullContact when there is new information available about the contacts I have added to my contact list of people I care about. Anytime there is a new photo, social network, or other element of their contact information updated, I get notified, andI  can choose to update it in my CRM. Would someone go ahead and create this, but for OpenAPI Specifications? All you have to do is use Github, and build your own index of the websites of leading companies who are publishing APIs (common crawl is good start), and begin keeping track of ALL of the OpenAPI Specs, and API Blueprints that are increasingly spread across the web. Then you will need to develop some sort of API definition diff solution (which I've talked about before), and then send me any changes or updates that I do not have in my directory of API definitions--which you know, because you have indexed already...

Deploying The API Service Providers That I Depend On Within My Own Infrastructure

24 March 2016
I play with a lot of services that are looking to provide solutions to the API industry, and I'm always looking to better understand what leading API services providers are using to deploy their warez. I was test driving the testing and monitoring solutions from Opsee this week, and separate from the solutions they provide (which I'll talk about later), I thought the deployment of their API testing and monitoring solutions was worthy of talking about all by itself. Opsee deploys as a micro-instance within my AWS stack, and gets to work testing and monitoring the APIs that I direct it to, providing a very precise, and effective way of doing monitoring. I do not think this approach will work in all scenarios, for all API providers, but I think packaging up the services, so that API providers can deploy within their stack, and run within the cloud or on-premise environment they choose, is a potentially very powerful formula...

Exposing The Meaningful Skills Our APIs Possess For Use In The Next Gen Messaging And Voice Apps

23 March 2016
As I'm working through my morning work monitoring the API space, I'm proccesing stories about the availability of valuable resources, like the House Rules Committee data being released in XML formats, and ExoMol, the molecular line lists DB used in simulation of atmospheric models of exoplanets, brown dwarfs & cool stars.  I feel fortunate to live in a time where the world is opening up such valuable resources, making them available online--available for anyone to use, remix, improve, and make better. My faith in APIs doesn't come from any single API, it comes from the possibilities that will exist when individuals, companies, organizations, institutions, and government agencies all publish valuable resources using APIs...

Savvy API Providers Submit Pull Requests To Update Their OpenAPI Specs In My Github Repo

22 March 2016
I'm constantly working to hand-craft, scrape-craft, and auto-generate OpenAPI Specs, and APIs.json files for as many of the top APIs I can. It is something Steve Willmott (@njyx), the CEO of 3Scale always flicks me shit about, saying I shouldn't have to do that--API providers should be doing this! While I agree, I feel like we haven't reached the point where all providers understand the importance of having an up to date OpenAPI Spec available for their API (some even have them, and work to hide them!) This is something the savvy API providers like SendGrid are doing, rolling around Github, making sure copies of their OpenAPI Specs are up to date.  Thank Elmer, you da man. Now I just need to convince another 2K other API providers of the importance of having up to date machine readable API definitions available, and actively maintain them...

What I Am Seeing As A Minimum Viable Bot Presence

22 March 2016
I have looked at way more Bots than I should have in the last couple days, and I'm beginning to see  similar patterns emerging across bot implementations, in sync with what I shared as part of my advice to API service providers. After you look at hundreds of APIs, and now a couple hundred bot implementations, you really begin to see what some of the common building blocks of the successful bot implementations are: Domain - Having a domain dedicated to the bot, its operations, and the community around it. Website - Simple, modern, and informative website for your folks to discover, and put your bot to work. Logo - Having a simple, modern, and often clever logo and overall branding to your bots presence...

Your Microservices Effort Will Fail If You Only Focus On The Technical Details

22 March 2016
I have self-censored stories about microservices, because I have felt the topic is as charged as linked data, REST, and some parts of the hypermedia discussion. Meaning there are many champions of the approach, who insist on telling me, and other folks how WRONG they are in the approach, as opposed to helping us work through our understanding of exactly what is microservices, and how to do well. For me, when I come across tech layers that feel like this, they are something that is very tech saturated, with the usual cadre of tech bros leading the charge, often on behalf of a specific vendor, or specific set of vendor solutions. Even with this reality, I've read a number of very smart posts, and white papers on microservices in the last year, outlining various approaches to designing, engineering, and orchestrating your business, using the "microservices diet"...

I Am Hearing A Lot More Talk About Restricting Free And Freemium Tiers Of API Access

22 March 2016
I'm seeing a significant shift in the conversations around how SaaS, and API-first platforms are planning access to their APIs. I'm seeing a pretty significant back peddling around free, and freemium access levels. I'm trying to keep notes on what I'm hearing, so that I can better understand what is causing this, and see if I can identify where the balance might exist in providing self-service access to API our valuable resources. Let' me explore some of the main reasons I'm hearing for reducing, restricting, or completely doing away with these lower level areas of access: Too Many API Freeloaders - There is a growing number of poorly behaved API consumers who are just looking for a free ride...

Sucked Into The World Of Bots And APIs

21 March 2016
I am slowly getting sucked into the world of bots. I've been tagging stories related to Twitter bots for some time, but it was the growing buzz of Slack bots that has really grabbed my attention. It pushed me to light up a research area, so that I can begin to look at things closer, and work to understand the common building blocks, like I do for the other areas of the API space. The world of bots intrigues me, from the perspective of how APIs can be used to execute bots, but also provide the valuable resources needed to deliver bot functionality. I feel like the list of categories of available Slack bots are somewhat telling of the business potential for bots: Analytics Communication Customer Support Design Developer Tools File Management Health & Medical HR Marketing Office Management Payments & Accounting Productivity Project Management Security & Compliance Social & Fun Travel While I find Twitter bots creative and interesting, there are many I also found annoying as hell...

Further Simplifying My API Docs And Providing API Samples

17 March 2016
For some workshops preparation this week, I needed to isolate just the best of the API calls and documentation from handful of APIs I am trying to teach my intended audience about. I have almost twenty separate companies targeted, with a couple hundred individual endpoints across the API provided served up by these companies. I needed to a way to easily define, organize, and present a subset of API samples, intended for a specific purpose audience.  In this workshop, I need the simplest, most intuitive samples possible across these popular APIs. For Twitter I need to be able to just send a tweet, or list friends, and on Facebook I need to post to my wall, and search for user. I need simple actions, that will be meaningful to my higher education audience--most likely students...

Personal APIs Are Not Just A Local Destination, They Are A Journey

16 March 2016
I am preparing a project for the conversations, and a workshop I have on my schedule this week at Davidson College, called: Indie EdTech & The Personal API. I'll be going on campus, talking to campus leadership, administrators, teachers, and students about APIs. To put myself into the right frame of mind, I wanted to explore what the concept of a personal API. The Concept Of Personal APIs Is RidiculousFirst, I'll set the stage with what is a common reaction, when I mention the term "personal API" to other API folk in the space: "Its a nice idea, but it just isn't something the average person will ever need, let alone care about what an API is--it is a non problem." To me, that response sounds just like what you'd hear in early 2000's when asked if any single individual would ever need a web presence--something that blogging and the social media star has continued to  evolve, while also proving the naysayers wrong...

Do My APIs Have The Skills They Need To Compete In A Voice And Bot Enabled World?

14 March 2016
I'm evaluating the Alexa Voice Service ecosystems alongside leading API messaging platforms like Telegram, and Slack, who are changing the way users engage and communicate, but also are evolving how we are putting our API driven resources to work. As I do this research, I keep finding myself coming back to Amazon's concept of an Alexa Skill, and thinking about how it applies to average everyday APIs like mine. Do my APIs have the skills they need to compete in this new voice and bot enabled world? It is bad enough that I don't always have the skills necessary to compete as a programmer, but now my APIs have to have the right skills? WTF ;-) Seriously though, I feel the Amazon's concept of the "skill" reflects a wider experiental shift in the API space, where APIs need to deliver information and other digital resources in the context of how they will be experienced by users, and not just how they are stored and maintained by developers and IT operations...

API Definition Driven UI Elements: Path, Verb, And Tag Autocomplete

14 March 2016
I was experimenting with breaking apart API definitions over the weekend, and exploring different ways of assembling the moving parts into different types of tools, visualizations, and other goodies. I do not have any particular objective with this work, other than just pushing the boundaries of we dynamically tell the story of our APIs, and hopefully assist in moving forward the current available API documentation toolbox we have for API providers, and consumers. Yesterday I published a short piece on API definition driven tag clouds, and this morning I have an API definition driven autocomplete text box, providing access to the paths, verbs, or tags present in any single, or multiple OpenAPI Specs that are indexed using APIs...

API Definition Driven Visualizations: Verb Tag Clouds

13 March 2016
I am playing with different ways of exploring APIs, building on documentation solutions like Swagger UI, Lucybot Console, and Slate. I want to push the boundaries of how we document, tell stories, and understand our APIs. I'm playing with two different formats, one is driven using Jekyll + Liquid, and the other are more embeddable JavaScript editions. I haven't hit on anything groundbreaking, but I am having fun breaking up the API definitions of common APIs, and organizing them for different experiences. This weekend I took my API Stack tag cloud, and made it driven by API collections defined using APIs.json and OpenAPI Spec. Instead of driving it from a simple tag JSON file, I wired it up to the APIs...

When The Products We Own Use APIs To Order Their Own Replacement Parts (Or Service)

11 March 2016
I was reading a post on Amazon's new SMART(Surveillance Marketed As Revolution Techonology) water pitcher, which is more about Amazon's new connected device partner commerce strategy, than it is about this individual connected device example. The quote from the story explains the strategy pretty well. Last week, Amazon.com curiously devoted an entire press release to a water pitcher. But not just any water pitcher. Rather, Amazon detailed a new partnership with Brita to bring consumers the $45 smart Brita Infinity Pitcher. Just connect it to your Wi-Fi, and the Brita Infinity Pitcher will automatically track how much water passes through its filter. Then, using Amazon Dash Replenishment, it'll automatically order a new filter when a replacement is needed...

Datensparsamkeit: Data Minimization

10 March 2016
I am borrowing from the very prescient post from Martin Fowler, an older post, but is a topic that should be revisited regularly. Google translate tells me Datensparsamkeit means "data minimization". I prefer Fowler's translation: It's an attitude to how we capture and store data, saying that we should only handle data that we really need. My partner in crime Audrey Watters (@audreywatters) sent me the link, and expressing that it was very telling that we (United States) do not have a word that applies for this concept. I think data minimization gets the point across, but I think Fowler elevates it from being just a data process, to something that should be rooted in company culture. I am adding Datensparsamkeit as a building block to any area of the API life cycle that will potentially store data...

An Imbalance In Investment Priorities That Will Continue To Slow API Growth And Adoption

10 March 2016
One topic that has been present in numerous discussions lately is just how much work goes into designing, deploying, and managing APIs, as well as around the integration between the growing number of APIs. It keeps coming up in conversations with existing API service providers, as well as internal actors within small business, enterprise, and government API efforts. When you live and breathe API, it all just makes sense in your head, but as API architects, designers, and believers trying to shepherd forward your API within existing organizations, it will come up against many unanticipated challenges. I have discussed this before with my stories about 75% of your API efforts in the enterprise being cultural and political, not technical, and with a short one on your API strategy providing a glimpse into your company culture...

Adding A Dead Pool Page To Each API Research Area So We Remember The Past

10 March 2016
When a startup goes away, either through acquisition, or any other reason, and I find the site dormant, with a friendly goodbye message, or just gone, I usually just remove the tag from them in my primary system, and they are gone from my research with the next publishing of the project.  When Parse announced they are turning off the lights, and Kimono Labs said they were going away after an "acquisition" by Palantir, I started putting more thought into what I was going to do at the time of deprecation. I want to be able to capture more of these stories. I actually have a lot of data, content, notes, and analysis on these companies that are going away, and I need to do a better job making it all accessible...

New Icons For Helping Me Communicate How Open Or Closed An API Is

08 March 2016
If you follow my blog at all you know I love Noun Project icons. I started using them with my last minimal website design, and is something I've carried over with the latest edition. I've been using some images for so long I even started reworking, remixing, and making my own images, to help me tell my API stories.  I find it difficult to conjure up just the right image, or images, to represent many very abstract API concepts, so it is something I am constantly working on alongside my research, as well as writing. As I was working on the content for a workshop I am doing at Davidson College this month, I wanted to have a simple, icon-based way for expressing just how open an API is (or isn't)...

While It Does Suck Parse Went Away, I Wish Every Service That Shutdown Left Behind The Same Page

08 March 2016
It definitely sucks that Parse went away like they did, but you have to commend them on the page they left behind. Facebook put up the download link to an open source version of Parse Server, and a link to the migration guide. I like that they also left up the blog, which I think is almost just as important as the code, telling the story of what happened, right up to the end. I come across newly deprecated API providers, and API service providers all the time. Most of the time they are just dormant, nothing going on but the site is up, and other times the website is just gone, with no message at all. I rarely ever come across anyone who puts up an open source version of their platform, with instructions on what to do next, and leave the blog up...

Playing With Concepts Around Simplifying The API Docs That Are Generated Using API Definitions

08 March 2016
I am building on my conversation with Abhinav Asthana (@a85), the Co-founder and CEO of Postman, around how we can simplify the API documentation we are providing to our API consumers. As part of my work to profile the 50+ stacks of APIs I list on my home page, I am playing with different ways of listing APIs, sharing the valuable endpoints available within, and other key aspects with users. All this work is being driven by APIs.json, and Open API Spec listings. First I've rewritten my main API listing page using Liquid, running in Jekyll, which uses a _data folder full of APIs.json, and OpenAPI Specs published as part of each of my API life cycle, or API stack research. To operate, this listing just mounts the _data folder, and loops through all APIs...

Four Buckets To Organize My API Deployment Research Into

08 March 2016
I was being interviewed by an IBM group the other day, and I scribbled some thoughts on a piece of paper as I was rambling, which I just picked up trying to make sense of what was going through my mind, before I archive the chicken scratches.  It look like during the call I was talking about how I see the world of API deployment, based upon how I am currently organizing providers, services, and tooling that I find. I was discussing with them how I am moving towards breaking things down into four buckets: Gateway - The more enterprise focused, IT department led API efforts, usually conducted at larger enterprises, and institutions. Artisan - A more farm to table, hand crafted approach that employs organic open source REST frameworks in the process...

Thinking Through The Design Of Your Pricing API Would Help You Think Through Your API Plan

07 March 2016
As I made my way through nine of the leading SMS providers, profiling the details of their API plans, trying to bring it all together into a single, machine readable definition, Messente's pricing API stood out for me. Alongside their SMS API, and their number lookup API, they have a pricing API. As I take a moment to look at the simplicity of the endpoint, I am also thinking about the potential, and the details of their API docs really stand out for me. In addition to a pricing API being a valuable utility for any API consumer, I can't help but think the process of constructing a pricing API would force API providers to think another layer deeper in their API plan(s). Similar to how you have to think through the details of any resource you make available via an API, considering how it will be put to use, crafting a pricing API would force you to do the same for one of the most valuable, and overlooked resources you offer, that is core to all of your API operations...

The 70 Platforms With Job Postings For A Developer Evangelist Or Advocate Currently

07 March 2016
I try to spend time each week evaluating what types of companies are looking for API / developer evangelist / advocates, to help keep my awareness in sync with what mainstream companies are needing (or not), when it comes to API outreach. In a little under an hour last night, I found almost 70 companies who had job postings for an evangelist or advocate for their platform. Google, Brightcove, Pubnub, Atlassian, Yahoo, Uber, Esri, Indix, Couchbase, edX, Amazon, Verifone, IBM Strongloop, Facebook, Microsoft, Intel, Impinj, Twilio, Cybersource, Shopify, Jibo Inc., Vidyo, UrtheCast, Talend, Stormpath, Square, Mailjet, Cylance In., Bandwidth, MediaMath, Nuxeo, Clarifai, NodePrime, Visa, UrtheCast, Stream...

My One Piece Of Advice To Next Generation of API Evangelists Is To Take Care Of Yourself

07 March 2016
As I finish writing a piece on the 70 platforms who are looking for an API evangelist or developer advocate currently, sharing the wisdom of leading evangelist I follow in the space, I am also working to gather up my own wisdom so that I can share. While i am not an evangelist for a single API, I was at one point in my career, and I also practice many of the same techniques in my own work, evangelizing for all APis. Out of my lists of advice for existing, and new API evangelists, one stands out: take care of yourself. Make sure and find balance in what you do, or you will burn out. You can ask anyone who has been in the scene for a while, and they'll tell you the same thing. However my message is ringing my ears right now, because I hit a wall last year with evangelism, and part of it was due to a fairly scary health concern...

It Would Be Nice To Have Some Simpler Interactive API Documentation In Addition To What We Have Now

07 March 2016
I had an exchange with Abhinav Asthana (@a85), the Co-founder and CEO of Postman on Twitter today. He was tweeting about API documentation, and I chimed in with my support, about how we need to keep evolving our approach to delivering API documentation so that they speak to a diverse audience. An API description created by experts is probably not the right way for building docs meant for beginners. — Abhinav Asthana (@a85) March 7, 2016 While I think we have come along ways with the introduction of Swagger UI, making learning about APIs much more interactive, and hands on, I think its time to look at how we can further refine how we deploy API documentation for our users. There is a lot going on with an API sometimes, and listing out all your endpoints, parameters, example requests, responses, and other elements can be overwhelming for new users who are just looking to learn the basics of an API, or possibly just get at s single resource, completing a specific action...

Numerous Challenges When It Comes To Comparing Even Similar API Plans

06 March 2016
I was pushing forward my API plan research this weekend, building on some of the tooling I developed during the last round, and the machine readable API plan format I hammered out late last year to help me define API plans. This time I'm applying it to nine of the SMS API providers I'm currently profiling, trying to get a new view of the plans of SMS APIs like Twilio and Plivo, but also working  to continue polishing my 100K view on the SMS API industry.  Documenting The API Plans Of Nine SMS APIsThis last friday I got to work profiling the pricing, plans, rate limits, and access tiers for nine of the leading SMS API providers that I keep an eye on. From their pricing pages I gathered the common metrics, limitations, geographic considerations, pricing, and other element offered by each provider, putting them into separate buckets, standardizing how I record these valuable aspects of each API providers resource...

Are 1000lb Gorillas Buying Startups To Look Pretty, Or Just So That Nobody Else Buys Them First?

04 March 2016
As I'm thinking about the bigger picture of how startup acquisitions are impacting the world of APIs, I am also having several conversations with folks about their brand spank'n new API focused startup, I can't help but feel that things are never as they seem, when it comes to the 1000 lb gorillas acquisitions within each wave of API driven startups. Of course there are many reasons why big companies gobble up the little startups, one that has a wide range of positive, and negative impacts on the overall health of the API economy, but from my vantage point rarely do the public stories ever size up with the real motivations behind the acquisitions.  Why do big companies buy well performing API startups? Leading technology? User adoption? Integrations? Talent acquisition? Revenue? Relevance? Look cool? I'm sure it "could" be a mix of any of those elements, but after seeing many acquisition's get shut down, users flee, and talent jump ship from these soon to be irrelevant, investment saturated startups--I'm always looking for the other motivations beyond why these corporate giants are trying to look alll pretty in their startup jewelry...

Scraping Static Docs Is Often Better Than Proxy For Generating Machine Readable API Definitions

04 March 2016
I was looking to create an APIs.json plus OpenAPI Spec(s) for the WordPress.org API, and the Instructure Canvas Learning Management System (LMS) API. I am pulling together a toolkit to support a workshop at Davidson College in North Carolina this month, and I wanted a handful of APIs that would be relevant to students, and faculty on campus.  In my experience, when it comes to documenting large APIs using OpenAPI Spec, you don't want to be hand rolling things, making auto generation essential. There are two options for accomplishing this, 1) I can use a proxy like Charles or Stoplight.io, or 2) I can write a script to scrape the publicly available HTML documentation for each API. While I do enjoy playing with mapping out APIs in Stoplight...

A More Distilled Version of An API Getting Started Page On The Home Page Of A Developer Portal

03 March 2016
As I look through API portals, profiling the building blocks of successful API platform, I'm always looking for bite-size stories for my readers. I was working to complete my Instagram API definition, as part of my photo API research, and their getting started graphic caught my attention. This three step getting started visual for Instagram is prominently available on the home page, providing a very distilled down version of what I recommend API providers usually accomplish with a dedicated getting started page. The featured getting started area provides you with the link to register your application, and overview on authentication and authorization, and a link to all the endpoints, so you can start making requests...

My API Is Not The Business Driver I Hoped It Would Be

01 March 2016
I have had several conversations with API providers lately who are somewhat frustrated with the way their API operations are going. While their APIs have brought in many new conversations, and supported some interesting integration, they haven't been the business driver that they had hoped when they kicked off their API efforts.  There are many reasons why API efforts may not live up to the hype, mostly its because I think we raise the bar too high in Silicon Valley. We raise up the Amazon's and Twilio's up in our mind as models we want follow, and talk about API success in terms of number of users, and in billions of API calls--as just a couple of examples. I will be the first to admit that many of us pundits have over hyped, and is something I've been working to filter out of my storytelling over the last couple of years...

Making API Terms Of Service And Privacy Policy Easy To Read And Understand

01 March 2016
The NextWeb had a great story today that Google has redesigned its developer policies with clearer language and visual examples, and normally I don't jsut parrot what the tech blogosphere publishes, but it's an important enough API message, I think it warrants repeating. In my experience, API providers just emulate what they hear in the space, and stories like this need amplifcation. What Google did isn't rocket surgery, they just simplified the legalize around what they expect of developers. What better way to actually help ensure these best practices around the platform actual happen, then by actually providing simple titles, summary description, images, and other relevant links, on a developer policy page...

A Small Business API Strategy

29 February 2016
I've been moving forward with my efforts to better on-board folks with the sometimes overwhelming amounts of research available via API Evangelist. I have several groups looking for guidance on where to start with their strategy, as well as develop some lower level tactical approaches to propelling themselves forward in their API journey. I recently posted a master list of my essential building blocks across, 20+ areas of my research, and now I'm distilling these into a single project to help me move forward as one potential operational API strategy for a small businesses. First i took the almost 1000 building blocks I've organized across my areas of API research, and added a question for each, which simply asks where things are with each of these potential considerations along the API life cycle...

A Simple Needs Assessment To Kick Off An API Integration And Automation Journey

29 February 2016
I need some help with APIs! Ok, where can I help you? Well, I have multiple systems, that we use to operate our business on a daily basis, and when we do things in one system, we need the other system to know about it, and when certain events occur we need to trigger pushes or pulls between all systems--this is how many conversations begin as the API Evangelist. While many people think they are looking for an API solution, they are really looking for an API journey, with a little assistance from me along the way. Sure they want an API to make their world more integrated, inter-operable, automated, and real time, but in reality, they are needing to get to work unwinding a mess of legacy technical, business, and political business decisions that have been over years--this takes a journey...

Extracting As Much Value From Your API Developers As You Can, Then Screwing Them Over in The End

26 February 2016
I often push back against API consumers when they complain about the deprecation of API platform, focusing on the fact that we cannot depend on APIs to be around forever. I also push back against API providers when they express concern around having to support developers forever, for fear of revolt in the community. I think the rational folks in the space understand that a balance is needed in these situations, but alas, there are always new incidents that make us go WTF?? I was reading about Venmo halting new developer access to its API from Techcrunch today, which left me shaking my head, saying damn, damn, damn. I know a lot of you are invested in the startup game, and in all honesty, I am too...

What Is APIs.json? And What Is Next For the API Discovery Format?

25 February 2016
As part of a renewed focus on the API discovery definition format APIs.json, I wanted to revisit the propsed machine readable API discovery specification, and see what is going on. First, what is APIs.json? It is a machine readable JSON specification, that anyone can use to define their API operations. APIs.json does not describe your APIs like OpenAPI Spec and API Blueprint do, it describes your surrounding API operations, with entries that can reference your Open API Spec, API Blueprint, or any other format that you desire. APIs.json Is An Index For API OperationsAPIs.json provides a machine readable approach that API providers can put work in describing their API operations, similar to how web site providers describe their websites using sitemap...

Adopta.Agency ClinicalTrials.gov Data And API

24 February 2016
In the last six months I was fortunate enough to be able to push forward one of my side projects, with the help of a prototype grant from the Knight Foundation. The mission of the project, is to help move forward existing open federal government data projects, by adopting them, and helping clean up the data, publish simple APIs, generate more meta data, while also telling stories around the project. Something I originally called Federal Agency Dataset Adoption, but then shortened to simply Adopta.Agency. When I was doing my final presentation in Pittsburgh last month, for the Knight Foundation, someone from the University of Miami was present, and when they got home, contacted me about helping move forward the database available at ClinicalTrials...

Exploring My thoughts Around API Injection Into Messaging, Voice, And Other Online Experiences

23 February 2016
As I listen to my hangout with Wade Foster of Zapier, I'm considering the overlap between my API reciprocity, bots, virtualization, containerization, webhooks, and even voice research. At the same time I'm thinking about how APIs are being used to inject valuable data, content, and other valuable API driven resources to the stream of existing applications we use every day.  Some of this thinking is derived from my bot research, where they impersonate Twitter users, or respond to specific key words, phrases, or keyboard shortcuts in Slack. Some of this thinking comes from learning more about the ability to inject "code steps" into multi-step workflows with Zapier. Then as I continue doing my curation of news I read about Uber allowing developers to create trip experiences, opening up another window for potential API driven injection into the Uber "experience"...

My Hangout With Wade Foster Of Zapier: Its About The Process

23 February 2016
I had the pleasure of hanging out with Wade Foster (@wadefoster), co-founder and CEO of Zapier (How do you pronounce Zapier? It rhymes with happier :-) recently. As I travel less, I'm looking at doing more of these Google Hangouts, to fill my need for hanging out with super smart people, doing really cool things with APIs. I am a big fan of what Wade, and the Zapier team are up to. His perspective on helping us define "the process", is extremely empowering for EVERYONE and ANYONE, especially non-developers. What Zapier enables, is very much aligned with how I would like the API economy end up operating. Where system to system, website, mobile, and device based API integration is important, but platform interoperability for the masses I feel is much more critical...

The API Transparency Discussion Is Not Exclusively About Being Public Or Private

17 February 2016
When I talk about companies using APIs to be more transparent, one of the immediate comments I receive from folks is that "not everyone can be public by default". I agree with this situation, but I always counter with an introduction to the concept that transparency can be applied in strictly internal or partner situations as well--public is not the only type of transparency out there. I am a big proponent of the public version of API driven transparency, but I also feel it can be applied within the firewall, as well as on the open web. Simple developer portals, with a quality selection of valuable APIs, up to date interactive documentation, and other resources, available at a known, yet secured location, can go a long way to stimulate integration--both human (team) and system...

Concern Around Mapping And Discussing Shadow Mobile APIs Shows Signs Of An Imbalance

16 February 2016
After I've talked about my mapping of the public, and mobile APIs with various folks over the last couple of months, I can usually put folks into one of three camps 1) they do not understand what the hell I am talking about and could care less, wishing the geek dude would shut up 2) thinks its a really interesting idea and worth exploring and discussing, or 3) they express concern, and liken it to scraping, and even hacking. I can understand folks not caring because they don't grasp it technically, but I do not fully yet grasp why people express concern, and think its wrong that I am mapping out, and wanting to discuss this layer of our digital world(s). As I was working with the new features in Stoplight...

As An API Service Provider, Should I Craft My Own API Definition Format, Or Just Reuse What Is Already Available

16 February 2016
I have had multiple conversations with folks in the space who are building services and tooling for the API sector lately, where I was asked whether or not they should only be using existing API definition formats, or create their own API definition format that better represents what they are delivering. The reasoning is usually that they feel their own format would offer a more comprehensive approach than any single, existing API definition could--yet they fully understand the potential for adoption when they use existing formats like OpenAPI Spec and API Blueprint. My answer to them, is you deliver d) All The Above. I fully get that you will have your own unique view of the API space, and of what your tools and services will deliver, so you should be defining your own schema, but that you also can't ignore what is happening with OpenAPI Spec annd API Blueprint either...

I Wish Everyone Broke Their API Pricing Page Down Like SendGrid Does

16 February 2016
I was going through the SendGrid API and profiling their available plans and pricing, using my new API plan tracking format, and I just have to stop and say--I wish everyone would present their pricing pages as simply as SendGrid does. I cannot speak to whether their pricing is good, fair, or otherwise, but the layout, and the way they explain it, is very simple straightforward and easy to make sense of. In addition to having the pricing for their email API broke down into six coherent plan tiers, they also have a compare plan details table which shows all six plans, side by side, with each core feature, and other elements of API access available to browse. As an API analyst, it make the data entry for my API tracking much easier, but as an API consumer it make it much easier for me to budget for the API driven resources I will need as part of my API operations...

Some Of The Micro API Evangelist Tasks That I Get Asked To Help With Regularly

16 February 2016
I have been working for a month or so on what some of the common tasks that developer advocates and evangelists would like to see occur around their API operations. These are small little tasks that evangelists should be doing themselves, but if they can encourage their own API community, or the wider developer and tech community to help out, they might achieve a greater reach. Getting your community to help out with tasks on your platform is nothing new. This is a core premise of modern web API operations, something that can work well in some ecosystems, but has historically been abused by other ecosystems. Some API providers enjoy vibrant communities where developers are more than happy to step up and build things for free, generate a buzz, and show up to events...

Automagically Defining Your API Infrastructure As You Work Using Stoplight.io

16 February 2016
I stayed up way too late playing with some of the new features in Stoplight.io. If you aren't familiar with what the Stoplight team has been cooking up--they have been hard at work crafting a pretty slick set of API modeling tools. I feel the platform provides me with a new way to look at the API life cycle--a perspective that spans multiple dimensions, including design, definition, virtualization, documentation, testing, discovery, orchestration, and client.  Stoplight.io gives me a pretty powerful platform for managing, interfacing, sharing, collaborating, publishing, understanding, and evolving my API designs and definitions. You can begin modeling your APIs by importing an existing OpenAPI Spec, RAML, or Postman collection, or get to work modeling a new or existing API via the Stoplight client interface, which is just one tool in the Stoplight modeling toolbox...

Generating OpenAPI Specs For The Mobile Apps You Depend On Just By Using Them

16 February 2016
Stoplight.io is a very cool new API modeling and proxy tool. I just wrote a post about the overall features of the platform, but I wanted to zoom in on a specific benefit that Stoplight.io brings to the table--the auto generation of OpenAPI Specs, for the mobile apps you depend on, as you use them. To understand the process in detail, I recommend watching the how was this created video on the Peach API documentation generated by Stoplight.io. When you download the Stoplight API designer for Mac (available on the account dashboard), you get the Prism API Proxy, which allows you to easily route all the traffic from your Macbook, as well as iPhone and IPad, through the platform. Once you create a new API, add the base URL for the API you are profiling, StoplLight does the rest, automatically generating an OpenAPI Spec, and attractive API documentation in the application, in real time as you watch--it is pretty cool to watch once you have turned on...

I Am Liking The Modular Services That Are Delivering In Specific Areas Of API Life Cycle Like API-Docs.io

16 February 2016
I like my API service providers like I like my APIs, doing one thing and doing it well. Sure services can work together (using APIs), and companies can launch multiple services, but I prefer selecting the services that I use as part of my API operations, as small, modular pieces of API infrastructure. In my opinion, API service providers are just another class of API provider, they just happen to be selling services to businesses that are operating APIs. You can see this in action with API Docs, part of the StopLight.io platform. API Docs does one thing well--API documentation! Although for me, it touches on two important areas of the API lifecycle, both documentation and definitions, but also illustrates the maturation of these stops along the API life cycle, since Tony first launched Swagger UI...

The Essential Building Blocks For Integration, Automation, and Reciprocity

15 February 2016
I'm spending some time going through v2 docs for the Zapier API, following the release of multi steps work flows, and code steps for calculating, converting, and manipulating data and content, last week. While IFTTT gets a significant amount of the attention of the API reciprocity platforms I track on, I feel like Zapier is the most successful, and reflects most of what I'd lie to see in an API driven integration, and automation platform--specifically, the fact they have an API. Along with keeping track of what Zapier is up to, I'm spending more time thinking about the increasing number of API driven bot platforms I'm seeing emerge, and API enabled voice platforms like Alexa Voice Service. As I was reading Zapier's platform documentation, I couldn't help but see what I'd consider to be the essential building blocks for any integration, automation, and reciprocity platform emerge: Authentication - Providing the mechanisms for the most common approaches to API authentication, including basic auth, digest auth, session based, oAuth...

The Bit Size Resources We will Need For The Bot And Voice Evolution In The API Space

15 February 2016
I just finished looking through the documentation for the Zapier API, and for the Alex Voice Service, trying to understand the approach these platforms are taking to incorporate API driven resources into their services. How do you translate a single API call into a Zapier trigger or action? How do you build a rich index of resources for Alexa to search via voice commands? Learning how APIs are being consumed, or can be consume, is an infinitely fascinating journey for me, and something I enjoy researching.  All of my research into reciprocity, bots, and voice enablement via APIs, makes me think more about experience based API design, trumping much of the resource based dogma that has domnated much of the conversation...

All This Information Is Great, But Where Do I Start With My API Strategy?

15 February 2016
I shared a list of just the essential building blocks from across only 21 areas of my API areas of the API life cycle with a company I'm helping craft an API strategy for, and I got some very common feedback--all this information is great, but where do I start with my API strategy? This is excellent feedback, as that particular overview is void of any specific 101, or on-boarding elements for each of the areas of the API life cycle that I cover.  This is on purpose for this particular document, providing me with a generic outline that I can use in many different scenarios, but the feedback rings loud in my ears, and is something I get constantly. I receive a constant barrage of emails, tweets, and voice mails asking me where they should get started with their API strategy, spanning both the provider, and consumer side of the API coin...

My Tooling And API For Gathering And Organizing The Details Of The Plans And Pricing For APIs

13 February 2016
A couple of weeks ago I started playing with a machine readable way to describe the pricing, and plans available for an API. I spent a couple of days looking through over 50 APIs, and how they handled the pricing, and their API access plans, and gathered the details in a master list, which I am using for my master definition. I picked up this work, and moved it forward over the last two days, further solidifying the schema, as well as launching an API, and set of admin tools for me to use. While my primary objective is to help me establish a machine readable definition that I can use to describe the plans of the APIs I provide, as well as the ones that I monitor as part of my regular work in the space--I needed an easier way to help me track the details of each API's plan...

Considering The Obvious And Subtle Differences Between Similar API Providers

12 February 2016
Evaluating exactly what is the "right" API can be very difficult. This is what I do full time, and its hard for me to understand the differences--I cannot image what it is like for people who have real jobs. I've used both the Crunchbase API, and the AngelList API for some time now, to help me better profile the companies that I am paying attention to as part of my research. I use both the website, and API for both of these business data platforms on a regular basis.  As I read about the recent investment in Crunchbase, and their changes in pricing, I'm reminded of my half finished work, incorporating the OpenCorporates API, and taking another look at all of my business data sources. I won't be able to afford Crunchbase after the changes, which will suck, but honestly I'm not a big fan of their overall operations, and approach, and happy to see the data source leave the stack of APis that I depend on...

API Evangelist, Assistant, and Broker

10 February 2016
I was in Philadelphia last week, hanging out with educational technology practitioners, and at one of the dinners I found myself talking to a young lady who was a digital learning assistant at a university. She spent her days, helping administrators, and faculty, when it came to understanding what digital resources and tooling were available, and assisting them to better understand how they can put them to use in their daily work.  This conversation left me thinking about the role I play in the API space. I long ago elevated myself above evangelizing any single APIs, a position I enjoy because of my partners 3Scale, Cloud Element, Restlet, and WSO2. I elevated myself into this role because I saw nobody else doing it across the space, and saw an opportunity to make a wider impact, beyond just peddling a single product or service...

Looking For Partners At Every Turn When Planning Your API Evangelism

10 February 2016
One reason for having a well thought out, comprehensive API strategy, is that you are thinking about all the moving parts, and at ever turn you can weave things together, and potentially amplify the forward motion of your API operations. With every new release you should be considering all other areas of your API strategy, how you can include your API consumers, your partners, and where all of the opportunities lie when it comes to evangelism, and storytelling. This approach was present in the latest release from Postman, with the release of their Run in Postman, embeddable button. As part of the release of the new embeddable button for their API client tooling, Postman also made a call for partners...

Importance Of Thinking Externally When Writing The Description For Your API

08 February 2016
I look at a lot of APIs, and one characteristic I judge them by, is their ability to simply explain what their API does. The most import aspect to any individual or company when doing APIs, is the process can potentially bring you out of your bubble, and make you think a little bit more externally.  One of the most common things I see from API providers, is they think it terms of, and present their API in the context of the language they program in. It is a ".NET Web API", or a Python API. When in reality it is a web API, and if it employs enough HTTP, it should be able to be consumed in any language. Another regular mistake made by API providers, is they describe their API in terms of their own platform, and never actually tell you what it does...

It Is All About No Limitations With The Enterprise API Plans

07 February 2016
I am continuing to push forward my API plans research, where I look closely at the common building blocks of the service composition, pricing, and plans available for some of the leading API providers out there. I have no less than ten separate stories derived from Algolia, the search API provider's, pricing page--I will be using Algolia as a reference for how to plan your API, along with elder API pioneers like Amazon, and Twilio, for some time now. On area of Algolia's approach I think is worth noting, is the enterprise level of their operations. They provide the most detail regarding what you get as part of the enterprise tier, being very public about their operations, in a way you just do not see with many API providers...

An Embeddable Run In Postman Button For Your API

06 February 2016
The popular API client tool Postman just launched an embeddable "run in Postman" button, that you can use to fast track integration with your API(s). Shortly after I wrote a post about the importance of API definition driven embeddable tools for API service providers, Postman contacted me and said, "hey! we are already working on that!" ;-) With the latest update, when you use your Postman Client, you can generate some embeddable JavaScript, which you can then post alongside your API documentation, throughout your developer portal, or possibly anywhere on the open web. Something that could trim minutes, or even hours off the time it takes for new developers to go from discovery to integration...

Different API Rate Limits For Verified And Unverified Free Tiers Of Access

05 February 2016
One of the approaches to API plans I was studying recently is from the data provider Factual, who provides access to places, products, and other valuable data-sets. I felt Factual had a pretty straightforward approach to the free tier of access for their platform, that was worthy of sharing. When you visit the page for the Factual data services, they offer two distinct levels of free access to data resources: Free (unverified) - Up to 100 read requests per day. No access to resolve or write APIs. Free (verified) - Up to 10,000 requests per day for most tables. When I look at the plans for many APIs, they almost always have free tiers of access, but normally there is just one dimension to it...

Automated Mapping Of The API Universe With Charles Proxy, Dropbox, OpenAPI Spec, And Some Custom APIs

05 February 2016
I have been working hard for about a year now trying to craft machine readable API definitions for the leading APIs out there. I've written before about my use of Charles Proxy to generate OpenAPI Spec files, something I'm evolving over the last couple days, making it more automated, and hopefully making my mapping of the API universe much more efficient. Hand crafting even the base API definition for any API is time consuming, which is something that swells quickly to being hours when you consider the finish work that required, so I was desperately looking how I could automate this aspect of my operations more. I have two modes when looking at an API, review mode where I'm documenting the API and its surrounding operations, with the second being about actually using the API...

Offering A Monthly To Annual Toggle For Your API Pricing Page

04 February 2016
I am continuing to work through notes from a recent push forward of my API monetization, and API plan research. Something that yielded a number of valuable nuggets  that I think API providers should be considering when crafting their own strategy. One of the pricing pages I was looking at as part of my research, was from authentication provider Auth0, which provided a nice way for allowing their customers to toggle between monthly or annual pricing. I organize small elements like this, into my lists of common API building blocks, which help API providers, and API service providers, with a list of things they can consider applying in their own strategies. I like the approach from Auth0 especially, because the toggle actually changes the plan pricing on the page, reflecting the shorter, or longer term costs associated with their authentication services...

If You Are Proud Of Your API Patents Publish Your Portfolio And Showcase Them

30 January 2016
I'm going to keep beating the patent API drumbeat, until I bring more awareness to the topic, and shine a light on what is going on. While I will still be my usual self and call out the worst behavior in the space, I am also going to try and be a little more friendlier around my views, and try and help bring more options to the table. This is a serious problem, nobody is talking about, and one that has many dimensions and nuances--if you want my raw stance on API patents, you can read it here.  One area I wanted to try and cover, in response to my friends trying to convince me their aren't bad people, in having patents. I know you aren't, and it isn't my goal to make you look bad in this, it is only to shine light on the entire process, how broken it is, and call out the worst offenders...

Breaking Out API Support Into A Separate Research Area

29 January 2016
Supporting your community is not unique to the API space, but supporting API operations does have some unique needs, and approaches that are proven by leading platforms. Like other areas of my research, I'm pulling out API support into its own area, so I can start shining a light on successful patterns I find in the area of API support. Two things pushed me to spin out this research area. One, I was tagging more blog posts, and other resources as support, and without a dedicated research area, this information would rarely float to the surface for me. Two, my partners over at Cloud Elements have an API hub dedicated to "Help Desk". While their aggregate API solution is targeting beyond the API community, it is API driven, and can also be applied to providing an aggregate support solution for API communities...

Parse Shutting Down: Maybe We Should Lower Our Expectations Of Tech Just A Little Bit

29 January 2016
The mobile backend as a service (MBaaS) platform Parse is shutting down. I started tracking on Parse as part of my BaaS research a couple years back, something that resulted in having all of the BaaS providers, including Ilya Sukhar (@) of Parse, on stage at @APIStrat NYC in early 2013--this conversation was just a couple months before Parse was acquired by Facebook.  Parse was widely consider to be the top BaaS platform, which resulted in wide adoption, something that I'm sure grew expoentitally after the purchase by Facebook. Parse is giving everyone a year to migrate, providing a database migration tool, as well as open sourcing a version of the platform. Which I think is a pretty fair deprecation strategy for customers, even with the unexpected news...

My Vision For One Possible Future Of The API Life Cycle Present In A Real-Time Subway Map For Helsinki

29 January 2016
If you caught my keynotes at @Defrag and @APIStrat last year, you know I'm working on using the subway map as a method for visualizing, understand, and eventually exploration of the API life cycle. I feel like the subway map concept, has helped us find a globally universal way of understanding the transport of humans, via some very complex transportation systems, in cities around the globe--something I feel can be applied to world of APIs. I was giving a version of my API life cycle talk to a group in Finland the other evening (their morning), and someone in the audience sent me a link to the real-time subway map for Helsinki. If you watch it closely, it updates based upon where the trains are, sharing times and locations...

Embedding Your Language SDK(s) In Your Apiary Documentation Using APIMATIC

27 January 2016
I'm seeing a resurgence in my embeddable API research lately, based upon signals I'm seeing across the space, and conversations I'm having with folks. The interesting part for me is that this wave isn't about API providers like Twitter and Faceobok using JavaScript to create buttons, badges, and widgets. This latest round is about API service providers making their services more accessible to both API providers, and API consumers, using embeddable tooling, and most importantly, API definitions. API driven embeddable tools comes in many shapes and sizes, but is something I work hard to understand, and track on in the space. I have several new embeddable stories to talk about this week, but today's is from my friends over at APIMATIC, as well as Apiary...

My Stance On APIs And Patents

27 January 2016
My post the other day on the hypermedia API focused patents from ElasticPath, has resulted in some very interesting conversations, with folks trying to understand this world, to those who are patent believers, and those who are just doing what they have to--in a world they do not control. This is why I write these stories, and frankly, it is why I am looking to push the patent conversation to new levels, to bring all y'all out of the woodwork. In a collective response to these conversations, I wanted to share my stance on patents, when it comes to the world of APIs. Let's start closer to the median, and talk about patents, and the world that "exists today", and explore the common responses when you look to discuss API patents in the current climate...

API Definitions Are The Contract For Doing Business With APIs

27 January 2016
I held a hangout with API Evangelist this morning, with Steve Willmot (@njyx) of @3scale, & Jakub Nesetril (@jakubnesetril) of @apiaryio today, where we discussed API definitions. Both Steve and Jakub are CEOs of leading tech companies, who are taking frontline positions when it comes to the whole API definition conversation. My role in this hangout, was just bringing together these two API leaders, to discuss the most important topic facing us in the world of APIs. API definitions are touching on every aspect of the API life cycle, and as Steve and Jakub discuss, playing a central role in their businesses, and their customer's businesses. We published the hour and half conversation on Youtube, so you can join in, even if you couldn't make the hangout...

A New Open Source Interactive API Documentation From Folks Over At Lucybot

25 January 2016
I am happy to be showcasing a new open source, OpenAPI Spec driven, interactive API documentation, from the LucyBot team. The API definition driven documentation solution is one of the best implementations I've seen to date, and reflects the future of where API documentation should be going in my opinion. While the Swagger UI has significantly moved the API documentation conversation forward, it has never been the most attractive solution, pushing some API providers to use a more attractive, less interactive, open source solution from Slate. The LucyBot API Console is both! It is API definition driven, using the OpenAPI Spec as its engine, but also provides a conversion tool for RAML, WADL, or API Blueprint...

Join @3Scale, @Apiary, And I For A Hangout On API Definitions This Wednesday

25 January 2016
Join me, Steve Willmott(@njyx) of 3Scale, and Jakub Nesetril(@jakubnesetril) of Apiary, for a hangout on API definitions this week. I wanted to explore  doing more hangouts under the APIStrat, as well as API Evangelist brand(s)--for this one I wanted to bring together some experts to talk about the fast moving world of API definitions, as a Hangout with API Evangelist. This Wednesday, January 27th, at 11:00 AM PST, the three of us will jump on a Google Hangout, and you are welcome to join in the conversation. We will be doing the gathering as a Hangout on Air, so that you can ask questions if you want, joining in the live conversation, or you can wait until after we are done, I will make sure and publish the video to Youtube...

Moving Towards A Meaningful Set Of Icons For The API Community

25 January 2016
There are many inconsistencies I struggle with in the API space, and the lack of meaningful icons to express myself is one of them. I was meeting with my friend Jerome Louvel of Restlet this last week, and he also articulated (again), the lack of imagery that represents APIs. To understand what we are talking about simple icons, like what RSS has, but to represent an API, instead of an XML feed. When I need an image to represent an API, I always borrow the simple icon from the API Commons. Like my API Evangelist logo, it is a pretty simple, black and white, minimum viable representation of "API". The folks over at Restlet also have their own, image, that they use across the platform, and suggested it as one potential design that could be used...

Reverse Engineering APIs From The Common APIs Models We Know

25 January 2016
As I work to complete more API definitions, with all API endpoints defined as an OpenAPI Spec, API Blueprint, and Postman Collection, with everything wrapped in a complete APIs.json index--I can't help but consider the importance of these definitions in helping others reverse engineer these APIs, to help apply in their own API design, development, and management processes. Whether or not you are learning about an API for consumption purposes, or learning about it from a providers perspective, there is a lot to learn from APIs that are defined using OpenAPI Spec, API Blueprint, and Postman Collection, and is something I'm working to push APIs.json to deliver on more. Right now I'm struggling to just get the basics of each API, its individual methods, parameters, and underlying schemas...

The New API Definition Abstraction Layer Over At Apiary

23 January 2016
I was on the road last week, so I didn't maintain my usual barrage of API analysis. As I go through my monitoring for the week, I'd say the biggest news of the week was Apiary's support of the OpenAPI Spec. I got a test drive of the support for the API definition format over the holidays, and was impressed with how smoothly Apiary integrated the OpenAPI Spec into their API design, virtualization, and management platform.  Another very interesting dimension of the Apiary release for me, was how they seamlessly integrated the new API definition into their road map. This wasn't a switch to the OpenAPI Spec from API Blueprint, it was about opening up, embracing, and abstracting away of multiple API definition formats across their platform operations...

Taking A Snapshot Of Just The Essential API Building Blocks Across My Research

18 January 2016
My API industry research is constantly moving forward, shifting, and being added to--much like the space itself. As I work to update each of my research areas each week, my process involves adding any news I've curated, and changes to the companies who are doing things in the space, as well as add or remove any common building blocks I've identified. These building blocks are the common patterns I've identified by studying how API providers are operating, and what features API service providers are bringing to the table, for API providers to put to work. This last fall, in preparation for my keynotes at Defrag and APIStrat, I pushed forward much of my research, flushing out more of the building blocks across 20+ of my research areas...

The Four Categories Of Dwolla API Consumers

13 January 2016
I just finished spending an hour talking with Brent Baker (@norcaljhawk), head of product for Dwolla, and Jordan Lampe (@JsLampe), about the vision behind the developer experience for their new developer portal. I will be able to craft many stories from the notes I generated during our conversation, but there was one aspect of how they view consumers of their ACH transfer API, I wanted to quickly share. This portion part of our conversation came up when they mentioned how they broke up their API users, as they were rethinking the overall developer experience. They put API consumers into four distinct categories: seeker - individual looking for a solution implementer - individual implementing solution maintainer - individual maintaining solution hacker - individual playing with their solution I think this is a great way to look at your API consumers...

The API Feedback Loop: Your Feedback Powers Everything We Do

13 January 2016
One of the benefits of doing an API, is so that you can take advantage of the potential for a community feedback loop, driven by internal groups, external partners, and even in some cases the pubic. Under my API management research, you can find a number of building blocks I recommend for helping power your feedback loop, but sometimes I like to just showcase examples of this in the wild, to show how it all can work. I was reading the Letter from our co-founder: 2016 Product vision, from Electronic Health Record (EHR) provider Practice Fusion, and I thought the heart of the blog post, represented a well functioning feedback loop. As Practice Fusion looked back over 2015, they noted the following activity: 798 product ideas submitted with over 3,000 comments...

Just The Best Parts Of The API Documentation Please

13 January 2016
I was just talking API documentation with Brent Baker (@norcaljhawk), and Jordan Lampe (@JsLampe) from Dwolla. As we were going through their API documentation, they mentioned how they were using Slate for the version 1.0 of their API documentation, but for this round they took what they felt were just the best parts of Slate, and were looking to craft a new experience.  Interestingly I had written about their use of Slate for API docs back in 2014, so it makes sense for me to keep tracking on, but more importantly I think the move reflects the wider evolution of API documentation. If you aren't familiar with Slate, it is a very attractive way to document your APIs, that many API providers and consumers have latched on to...

How Do I Provide A List Of Certified Applications To My API Ecosystem Partners

12 January 2016
I was emailed by someone working in government, asking some pretty interesting questions around using an application showcase, to make trusted applications available to an ecosystem of partners. I'm not going to talk specifically about the agency, as I have not gotten approval to talk publicly, but I think the question is an interesting mix of several areas I am researching, that I wanted to explore a little further, in an anonymous fashion.   This is a a heavily edited, summarized version of what was asked, but it essentially went like this: There are 400 apps that want to get data from an organization but only some portion of them meet or exceed the governance criteria to be deemed “trustworthy”...

I Just Cannot Get Behind API Patents, Especially When They Apply To HTTP And Hypermedia

12 January 2016
I got an email in my inbox, about a new API modeling language from Elastic Path earlier today. The product is called Helix, and is sold as being "the first enterprise-class API modeling language designed specifically for REST Level 3".   The Elastic Path team is where I first learned about the concept of hypermedia, I believe back in 2011--honestly, I had heard the concept before, but never fully grasped what it was, and the potential until 2011 (I know I am slow). However it has been an awareness that has grown rapidly, the more I learn about hypermedia, study how people are practicing hypermedia, and even dabble in it myself with my curation, and building block APIs. Elastic Path is an expert in the area of hypermedia, so it makes sense they would step up with some hypermedia focused API tooling, and even a modeling language...

API Aggregation, Reciprocity, and Orchestration

12 January 2016
I struggle a lot with how I separate out my research areas--there are a lot of reasons why I will break off, or group information in a certain way. Really it all comes down to some layer of separation in my head, or possibly what I perceive will be in my readers head. For example, I broke off hypermedia into its own research project, but now I'm considering just weaving it into my API design research.  This is one of the reasons I conduct my research the way I do, is that it lets me spin out research, if I feel necessary, but I can easily combine projects, when I want as well. As I move API aggregation and reciprocity out of my "trends" category, and into my primary bucket of research, I'm consideration an addition of a 3rd area dedicated to just orchestration...

Helping The Average Business User With More Information On How To Put APIs To Work

12 January 2016
API Evangelist has long been dedicated to helping the average business user understand all that is API. I saw early on in 2010, the potential of APIs, when used to empower the IT, or even shadow IT of the average business user. I think I've done well in this mission, except for one thing, the API Evangelist network is heavily focused on providing APIs, and much more lighter on topics and information around consuming APIs--something I will be working hard to shift over the next five years. To help me tackle this, is my new partner Cloud Elements. I do not partner with organizations, unless they help fuel my research, and Cloud Elements is helping me pushing forward several areas including API aggregation, API reciprocity, as well as pushing me to profile 50 of the top business sectors...

API Stack, APIs.io, And APIs.Guru Need You To Create And Share Your API Definitions

09 January 2016
I feel pretty strongly that for the next wave of growth in the API sector, we need the majority of public APIs in use today, to have well crafted, as complete as possible, API definitions in either OpenAPI Spec or API Blueprint. Yes I know, we actually need all of these APIs to be crafted using hypermedia approaches, but until then we need them all to possess machine readable API definitions, making them discoverable, learnable, and consumable. It is easy to get hung up on this being about API discovery, but API definitions are enabling almost every step along the 35 areas of the API life cycle I am mapping out. Historically API definitions have bee used for interactive API documentation, but more recently are additionally being used to light up other aspects of API integration, such as setting up your API monitoring, loading into the API client of your choosing, or lighting up a mock server for use in development...

Public GETs, In Concert With Private POST, PUT, And DELETE For Your APIs

08 January 2016
Another story I wanted to tell from my work to expose an API yesterday, so I could get help with it, was focused around the service composition that I used. I feel like this is a powerful story, that should be told, and retold among API evangelists, across conversations with folks who are new to the API space, and the concept of putting APIs to work in their daily business worlds. The largest concern I hear from people who don't fully understand API, is the perceived loss of control, from putting things up on the open Internet. When you don't understand modern API management infrastructure, and the nuance of API service composition, what an API does can seem pretty scary. The first lesson around me exposing of an API, from the @APIStrat speaker database, was about soliciting help from Nicolas Grenié (@picsoung), and the second lesson is centered around how I used a combination of public / private endpoints to make this work...

Are We Stepping Back And Considering The Potential For Abuse With Our APIs?

08 January 2016
I see a lot of APIs, and honestly I'm not excited about all of them. Some are public. Some are private. I am feeling that I could put the APIs I see into 3 different buckets: valuable, some value, and no value. Obviously there is going to be much more nuance to it that that, but this post is about the APIs that generate no value. First, let me clarify--I am speaking value to everyone involved. This is my own personal measurement. Examples of APIs that offer no value, are usually about the exploitation of developers and/or end-users, while giving the lion share of value to the platform. I put a lot of Internet of Things APIs into this bucket, and other leading APIs from companies like Snapchat or LinkedIn...

Using APIs To Address Regulatory Uncertainty Involved In Cross-Border Data Flows

07 January 2016
I pulled the title for this post directly from understanding the impact of cross-border routing of data during an era of emerging geographic restrictions, from Dyn. I'm writing about this to add it to my list of numerous concerns for API providers, when it comes to internationalizing their APIs, for the global API economy--such as establishing successful patterns for multi-lingual APIs and documentation, or providing API access that is replicated into multiple regions around the globe. Dyn's perspective comes from a more regulatory level, which I think coming from a DNS provider is something that makes the story even more compelling. At any rate, I feel with the big data / surveillance culture that is thriving right now, regulatory concerns, when it comes to data and privacy will continue to be a natural response, and will increase, and continue to be more heavy handed...

I Loaded That CSV Into A Database, Now Let Me Expose An API So I Can Get Some Help

07 January 2016
I have been working to clean up the the web presence for the API Strategy & Practice conference. We concluded the 6th edition of @APIStrat in Austin this last november (check out the videos), and in addition to this events website, I have five other sites to maintain, and make sure remain accessible. The first three sites have a custom database back-end, the next two had a WordPress + MySQL back-end, and the last edition uses Jekyll + YAML as its back-end(?).  As part of this round of housecleaning I aggregated the schedule of speakers from all six events into a single spreadsheet, which ended up on my desktop as a CSV file. As I was talking this morning with the rest of the @APIStrat team about the 2016 schedule, I shared the CSV in Slack, as I also uploaded to a MySQL database (yeah I'm new / old school like that)...

We Need An API For The Chronology of Data Breaches Database

06 January 2016
I came across the Privacy Rights Clearinghouse, while conducting a search that turned up the chronology of data breaches, which provides details on 4,725 data breaches that have been made public since 2005. The website allows you to search for data breaches by type of breach, type of organization, and the year in which it occurred--some very valuable information. In 2016, as breaches continue to be common place across almost all industries, we are going to need to take the chronology of data breaches up a notch. I would like to see an API be made available for the valuable database. As I do, I write stories about what I'd like to see in the space, and forward the link to key actors, and tell the story to the public at large, in hopes of inciting something to happen...

Your API Access Replicated Into Multiple Regions Around The Globe For Additional Charge

05 January 2016
I am finding all sorts of interesting examples as I push forward my API plans research, where I study the API planning approaches employed by over 50 of the leading APIs. One of the items, on my API plan story list, comes from Algolia, the search API, who I think has one of the more sophisticated API plans of all of the APIs I looked at this round.  One of the cool aspects I found was a "world-wide replicator" option on the pricing page for Algolia. The feature is interesting to me because of the UX / UI approach employed, as well as the concept of offering API replication to different regions as a dimension of API plans. You have to admit the separate section, as part of API pricing, is pretty forward leaning, and not something you see often...

AWS Has A Blog That Is Dedicated To The Command Line

05 January 2016
Amazon has a new blog dedicated to just their Command Line Interface (CLI). I use AWS as anchor for many of my API stories, but I also acknowledge that many API providers will never be at the scale of AWS, but nonetheless I am drawn to the regular streams of lessons available via the cloud platform, if you look in the cracks. The new AWS CLI blog is one of these. I do not think all API providers should run out and start a separate blog for their CLI, but the existence of a dedicated CLI blog at AWS shows the significance of CLI to the API world. If you are looking to court the enterprise, and many other developer groups, a CLI should be a very relevant tool in your toolbox. If a platform interface is not also available via a CLI, you might be missing an entire segment of the developer community...

All Companies Who Have An Online Product Catalog Should Look At What Octopart Does With Their API

05 January 2016
Octopart is a search engine for electronic parts. They have been on my API monitoring radar for some time now, because they have a very well done API. Octopart was one of the first API providers I wrote about, who were making their data available via their API, available in spreadsheets for business users, via a plugin.  The reasons I am writing about Octopart this time, is much more mundane. They are just doing it right, and I wish all product websites, had an API presence like Octopart does. As soon as you land on the home page of the site, where you can search for electronics products, all you have to do is scroll down, and you immediately see a link for the API. There is also a prominent set of links in the footer, labeled products, that focus on the API, as well as the Excel and Google spreadsheet connectors built on top of it...

Security Will Increasingly Be Used AS Component Of Tiered API Planning

05 January 2016
As I look through the business models of leading API providers I am profiling, I'm increasingly seeing security as a selling point. When API providers break down their pricing into tiers, they are usually very good at breakdown down the elements of what goes into each plan--this is what I have been studying for last couple weeks.  When I come across security leveraged as part of API plans, it is rarely a part of the free or entry levels, and is something you usually see in the higher level paid plans, and enterprise tiers. Here is an example of this, in a screen shot from the Box pricing page. These plans are part of the SaaS side of the Box operations, but Box are pretty unique in that they have separate pricing tiers for the SaaS side of their operations, and a related, but addition set of pricing for the API side of their platforms...

Providing A Dedicated Test User API As Part Of Your API Virtualization Strategy

05 January 2016
I was profiling the Facebook API as part of my API Stack work. While I only use a handful of the endpoints available to me via the Facebook API, as the API Evangelist, I feel like I should have an awareness of the popular social API. Additionally, the number of great stories I find dramatically increase with the number of API profiles that I complete. One story I extracted from my Facebook API research is about providing a dedicated test user API. Using the test user API you can add, manage and delete test users, which you can use throughout the developing and testing of your API integration. Facebook is user- centric, but it seems like the concept applies equally to any other valuable resource made available via APIs today...

Diff And Merging Of API Definition Formats

04 January 2016
As the number of API definitions increases out there, I'm coming across many duplicates of APIs I already have in my collection(s). In 2016, I will increasingly need to be able to execute a diff on two OpenAPI Spec or API Blueprint files, and get back a programmatic, as well as a visual reference, which allows me to quickly understand the differences between each spec in detail. In support of this API definition diff tooling, I can also see the potential for some sort of merging tooling, that would allow me to easily say yes or no, and merge various elements of either API definitions. I recently got sucked into using Ancestry.com, and they provide a nice way to merge discovered documents into your family tree, accepting or rejecting what you want--I would like to see this exist for API definitions...

Look Across My API Monitoring API Methods By Grouping Them Using Tag

04 January 2016
Last week I was playing with defining API monitoring APIs so I can map to each stop along the API life cycle. I took three of the API monitoring services I use (APIMetrics, API Science, and Runscope), and like I do for other areas along the API life cycle, and for common API stacks, I profiled their APIs using the OpenAPI Spec. This is standard operating procedure for any of my research areas, in that part of profiling each company's operations, I profile the API surface area in detail. For each of my research projects, I will include this listing of each API endpoint available as part of the work. As I was adding one for my API monitoring research, I had a thought--I wanted to reorganize the endpoints, across the three API monitoring service providers, and group them by tag...

The OpenAPI Specification (fka The Swagger Specification)

04 January 2016
It is a new year, and we have a lot of work to do when it comes to defining APIs in the new year. One of the results of 2015, was that the specification known as Swagger was spun off into the Linux Foundation, where for the remaining of the year we were simply calling it the Open API Definition Format (OADF)--quite a mouthful. In 2016, a name as been given to the specification--OpenAPI Spec. If you know me, you know how I feel on all of this, but in 2016, I am focusing on whats next, not what just happened, so I am just happy there is a name, not some intermediary WTF. Soooo, head over to the new Github repo home for OpenAPI Spec, and get involved. If you are planning on doing anything cool with the OpenAPI Spec, please reach out and let me know...

API Blueprint Has Been Evolving In Two Critical Areas Where OpenAPI Spec (aka Swagger) Falls Significantly Short

04 January 2016
Z (@zdne) over at Apiary published a pretty interesting blog post before christmas which highlights two important elements of profiling APIs using popular API definition formats. Z is key to the vision behind API Blueprint, one of the top 3 API definition formats, that are fueling API design in 2016.  Giving The Body Some LoveOne common complaint I've seen on forums, issue threads, and other places API developers hang out, is that OpenAPI Spec does not allow for properly describing the request body payload. I definitely agree with this, but is something that doesn't often impact me, as the type of APIs I am currently deploying, rarely employ a very complex body payload. However I do know some APIs that I've documented, where if you can't properly define the body, the API appears to have no value whatsoever, when described using an OpenAPI Spec...

API Definition Origin, Validation, And Attribution

04 January 2016
I have done a lot of work hand crafting, and often scrape crafting, machine readable OpenAPI Spec, as part of the work on the API Stack. Creating a usable API definition is a lot of work, making it is a pretty valuable commodity, in contrast to my strong opinion that they should be readily available for EVERY API today. While there is still a HUGE AMOUNT of work to be done, I feel like the ball is beginning to move forward, when it comes to the number of publicly available API definitions.  For the API economy to work at the scale we all have pictured in our head, the surface area of ALL APIs, and its supporting operations needs to be defined, and available to consumers and service providers...

Microsoft Increases The Visibility Of Their API Driven Platform With A New Road Map

04 January 2016
A road map for your API, is one of those essential building blocks that can go a long way in building trust with your API consumers. Sharing your plans, helps developers prepare for the future, and better plan for their own road maps, keeping everything potentially in sync.  From my vantage point, a simple, up to date, easily found road map is a building block that benefits both API provider and consumer. Road maps help provider organize their plans, and figure out how they are going to communicate it with the ecosystem, then setting the overall tone for how API consumers will engaging with a platform--both good and bad. During my regular monitoring of the space, I saw that Microsoft released a pretty slick "Cloud Platform Roadmap", which is yet another sign for me on how Microsoft is stepping up their cloud (API) game...

Thinking About The Monetization Layer For Public Data

03 January 2016
This is my walk-through of the concepts involved with the monetization of public data using APIs. In this work I am not advocating that companies should be mindlessly profiting from publicly available data, my intent is to provide a framework for organizations to think through the process of generating revenue from commercial access to public data, acknowledging that it costs money to aggregate, serve up, and keep data up to date and usable for the greater public good--if public data is not accessible, accurate, and up to date it is of no use to anyone. I have long argued that companies and even government agencies should be able to charge for commercial access to public data and be able to generate revenue to cover operational costs, and even produce much-needed funds that can be applied to the road map...

2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 | 2019 | Archive