The API Evangelist Blog - 2015

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


Do You Have What It Takes To Be On The API Academy Team?

30 December 2015
When it comes to keeping an eye on what others are doing across the API space, and occasionally pushing forward a few crazy ideas, API Evangelist is your source. However if you really want to learn about API design and architecture, that you can put to work at your company, organization, institution, and government agency--the API Academy is where you go. There is not another team API team that so focused on API literacy, with as much expertise, as the API Academy team. If you have been to any of the leading API events like APIStrat, APIDays, API Craft, and RESTFEst, you've seen their team in action, and known what they are bringing to the table. Mike Amundsen (@mamund) is making sure we are all on the correct path...

Here Are The Top API Stacks I Will Be Working To Define in 2016

30 December 2015
My new partner in API crime Cloud Elements is helping motivate me to spend more cycles in 2016 on defining specific stacks of APIs, as part of my ongoing API industry research. I am taking the approach I've honed over the last five years in my core research, and continuing to push forward on specific areas of the API industry. Cloud Elements calls their aggregated APIs -- Hubs, because they are working to aggregate them into actual usable APIs. My approach is meant to organize common API definitions, into specific groups. I do not go as far as aggregating APIs into a single API, and providing a platform, and tooling for you to actually work with the APIs.  Cloud Elements currently has 11 business API hubs defined, where I'm looking to push the space forward by defining 50 stacks: social messaging users storage compute documents commerce payments photos videos music audio voice search content language news travel geo mapping places businesses links events weather movies advertising accounting shipping government (city) government (state) government (fed) home auto transportation wearables energy space healthcare environment education libraries university (faculty) university (student) sharing economy banking 3d printing internet of things drones machine learning I am not in the business of pushing the overall number of APIs forward in the API space--this number means nothing to me in 2016...

The Hard Work When It Comes To Defining APIs

29 December 2015
I am stopping and collecting some of my thoughts, as I work through my API stack. I'm thinking about the more difficult aspects of defining APIs, this time it is for the APIs I depend on to operate my own company. I am working to define the APIs I depend on from over 30 companies, partly to help me better understand the APIs I use, but also partly as theater here for API Evangelist. To profile APIs, I use OADF and APIs.json as my machine readable definition formats. Not all APIs are created equal, so it takes different approaches to crafting their OADF, from doing it by hand for the easier ones, to scrape scripts that take consistent (static) documentation, and generate an OADF version. As I do this work, here is where the hard work is (will be) in all of this...

A Roundup Of API Meetup Groups In North America

28 December 2015
The existence, membership, and activity around local API Meetup groups is one of the overall health indicators in the API space. I've long been a proponent of local API meetups, helping jumpstart the early API Craft gatherings, as well as helping new Meetup groups get off the ground. As we move into 2016, it is a good time to take another look at what API Meetup groups exist, and here is what I found: San Francisco, CA with 884 members San Francisco (API Craft) with 662 members Washington, DC with 1306 members Austin, TX with 717 members Seattle, WA with 463 members Chicago, IL with 394 members New York, NY (API Craft) with 343 members Los Angeles, CA with 191 members Houston, TX with 141 members Detroit, MI (API Craft) with 246 members Boston (API Craft) with 426 members Dallas, TX with 107 members Denver, CO with 895 members Nashville, TN with 185 members Baltimore, MD with 76 members Montreal, Quebec with 229 members  Toronto, Ontario with 201 members  Minnesota with 169 members  Raleigh, NC with 196 members At @APIStrat, we use these numbers to help us decide where to put API conferences on, as on the ground support is crucial to making the event a success...

Thinking About My API Usage At Scale Across Almost 35 External APIs

28 December 2015
As I conclude the first phase of profiling the APIs that I depend on, I am thinking about my API usage at scale, and some new questions are arising, that I wasn't thinking about before. I find my API consumption, and API integration thinking historically has been on an individual API basis, which something that I hope to evolve upon in 2016. Here are a handful of questions that have arose in my notebook, as I worked to profile these APIs: Where do I login / register for a service? What are the security definitions? Where do I get support? Where do I get updates? How do I manage my keys / tokens? What are the details of applications I have created? What are my rate limits? Plan levels available to me?  Where am I at with my rate limits? Overall consumption? What am I spending across my API usage? Do I have plan B for any of these? Even possible? What SDKs do I depend on for integration? What are my code, content, and data licensing concerns? Am I adhering to branding requirements appropriately? Can I increase my API usage? Are there new fetaures I am not using? These are just a few of the questions that I wrote down, as I profiled the surface area of each of my APIs...

My API Evangelist Strategy for 2016

28 December 2015
As I approach 2016, I'm stepping back, and looking at the big picture of what it is that do, and using what I learn to help guide what I will accomplish in 2016. I tend to not subscribe to the concept of predictions, and instead focus on what change I personally would like make within the API space, and this strategy is key to me achieving this vision. First, let's start with what do I do? I track on the world of APIs, with eye towards how we can better execute on the tech, business, and politics of APIs, based upon a better understanding of approaches established by existing API providers, and the features being offered by service providers who target the space. In 2010, I started tracking on API management, and in 2015 this has expanded to almost 35 areas: Aggregation Branding Client Containers Definitions Deployment Design Discovery DNS Embeddable Evangelism Hypermedia  IDE Licensing Management Monetization Monitoring Partners Patents Performance Plans Privacy Ratings Real Time Reciprocity Regulation SDK Security Spreadsheets Terms of Service Virtualization Voice Webhooks Originally I saw these research projects as just various lines along the API life cycle or journey, but increasingly I'm also seeing these as just the "first" stack of API resources that I study...

A Little Hack To Help Me Better Define Method Based APIs Using OADF

23 December 2015
A handful of the most iconic APIs out there, which I also happen to depend on for my own operations, are some of the more frustratingly designed APIs I know. There are many API design offenses we all commit, but one of the most frustrating for me is when you use a single URL, and depend on a single parameter, for accessing everything an API has to offer. A couple of my favorite APIs, Flickr and Amazon EC2 both employ this approach. A single URL, and a single parameter for working with a wealth of API driven resources. This is a classic mistake of the technologist, delivering what you need, but making it difficult to actually learn about an API. This approach to API design delivers upon the functionality desired, but makes very difficult to document using common approaches available to us like OADF, and API Blueprint...

Variable Rates On Your API GET Requests Depending On How Many POST or PUT Requests You Make

21 December 2015
I'm down in the detail of how we craft our API plans, looking at the approaches of almost 100 different providers, and working to establish a common schema for cataloging the plans of these popular APIs. I have already talked about dialing in your API pricing down to the endpoint and level, but was something I wanted to take a little bit further. In my previous story, I talked about how mature API providers charge different rates for POST, and PUT requests, than they did for GET requests. Using this scenario, what if we wanted to incentivize and reward behavior through variable rate pricing at the HTTP verb level, to give developers more ownership over an API, including better access and pricing structures the more they contribute...

Button To Run This API In The HTTP API Client of My Choice

19 December 2015
There are more HTTP client tools out there than I can shake a stick at (I've reached that point, I'm shaking sticks at things), and in 2016 I predict there will be even more entrants into the space. I'd say Postman was a pioneering force in the evolution of the HTTP client when it comes for web API space, but is something that it is beginning to collide with API design tooling from Apiary, as well as being morphed by new players like Stoplight.io. Maybe I am playing with more of these environments than the average API consumer is, because of what I do for a living, but I have to say, I am getting tired of "importing" my API definitions. Don't me wrong. I am stoked that all tools support the importing of machine readable API definitions like OADF, and API Blueprint, but I cannot help always looking to what should be next, and I want to be able to just run each API, in my HTTP client of my choice...

Adding Journeys To Each Of My API Research Areas

18 December 2015
I am continuing to build on the subway map exploration work, that I talked about at @Defrag and @APIStrat last month, and have a more static version of my API life cycle explorer ready, which I'm simply calling the API journey. I have only rolled this out for my API plans research, but so far I'm happy with the results, something that shouldn't be too difficult to light up for the other 30+ areas I'm researching. There is quite of bit of research that goes into the work that I publish, and the subway analogy is allowing me to share more it, making more parts of it more accessible, in ways I was never able to before. Currently you can take the journey through each of the stops along the API plans portion of my research, and learn about in details about some of the common patterns I'm seeing across the space...

Defining API Monitoring APIs So I Can Map To Each Stop Along The API Life Cycle

16 December 2015
I am going through each of the 35+ areas of the APi space that I monitor, working to bring alive the over 900 stops along the API life cycle, that I have identified through my research. I'm still working through prototypes for my life cycle explorer, but the current version has organizations, tools, links, and questions, along with the title and description of each stop of the life cycle journey I am trying to bring into focus. Part of my approach in identifying the different lines, areas, and stops along this life cycle involves taking a look at the approach of leading API providers, as well as service being offered by companies selling their solutions to these API providers--giving me two sides of the API life cycle coin...

How Tight Is The Coupling Between The SaaS Business Model And The API?

15 December 2015
As part of evaluating 50+ companies, and their business approach to delivering APIs, I came across the Box platform. As I am looking through this diverse slice of API companies, I am looking to better understand the motivations behind providing APIs, and how sophisticated the monetization or overall planning are for their operations.  For most APIs, there is either no evident monetization strategy, the strategy is directly coupled with API access, or indirectly part of larger monetization strategy around existing devices, products, advertising, software as a service, or any other type of service. When it came to Box, they have a clear SaaS pricing model, as well as one specifically for their API ecosystem--of course they are both intertwined, but the fact there are separate dimensions I felt made it worth highlighting...

Easier To Offer Ops APIs To Your Devs If Your API Service Provider Has APIs

15 December 2015
I'm looking at the pricing APIs offered by some of the API providers that are further along in their API journey. This is just one example of how API providers are offering more operational level APIs to their developers, giving them control over their own integration, allowing programmatic control over account settings, billing, rate limits, and pricing. I've talked about the need to allow for more automation of the modern API life cycle, allowing API consumers to better manage their consumption across the many APIs they are depending on. This is why I'm spending a greater amount of time focusing on API service providers in the space practicing what they preach, and making simple, easy to use APIs available for the services they offer...

Why I Labeled My Research API Plans Instead Of API Pricing

15 December 2015
How to monetize APIs is on of the top questions I get from companies, right after concerns around security and control. I have separated my research into two main buckets, the first is focused on the questions I should be asking around API monetization as I'm planning my strategy, with the second focused on the actual plans for the operations of leading API providers. There is a lot of overlap between the two, but I guess API monetization is more strategy, and API plans is more about operations. When I started my API monetization research, it was very focused on how do you make money from your APIs, resulting in the poorly crafted title. I'm not making the same mistake with my API plans research, which is meant to help define a wide range of motivations for providing APIs...

Customizable Terms of Service As Part Of Your API Plans

15 December 2015
I am spending a significant amount of time looking through the pricing pages for leading API providers, working to get a sense for some of the common approaches to API monetization in use across the space. Along the way I am also finding some simple and unique approaches from API providers that I wanted to share as bit-size API planning stories here on the blog. As I was working to understand the coupling between the Box SaaS business model, and the one applied to their API, I noticed an interesting element, that was part of their enterprise API plan--custom terms of service. At first glance it doesn't seem like much, but making elements of your TOS dynamic, allowing them up to be used as a metric within your API plans, opens up a whole world of possibilities...

Solution Discovery Instead of API Discovery Via API Aggregation and Reciprocity Providers

15 December 2015
During my API discovery session talk at @APIStrat Austin this last November, I talked about what I see as an added dimension to the concept of API discovery, one that will become increasingly important when it comes to actually moving things forward --- discovering solutions that are API driven vs. API discovery, where a developer is looking for an API.  It might not seem that significant to developers, but SaaS services like Zapier, DataFire, and API hubs like Cloud Elements, bring this critical new dimension to how people actually will find your APIs. As nice as ProgrammableWeb has been for the last 10 years, we have to get more sophisticated about how we get our APIs in front of would-be consumers...

Dialing In Your API Pricing Down To The Endpoint And Verb Level

15 December 2015
I am spending a significant amount of time looking through the pricing pages for leading API providers, working to get a sense for some of the common approaches to API monetization in use across the space. Along the way I am also finding some simple and unique approaches from API providers that I wanted to share as bit-size API planning stories here on the blog. As the API service composition of leading providers evolve in the space you see platforms getting more granular in not just how they control access to their API resources, but also how they incentivize consumption. When I say granular, I am talking about API pricing for APIs available down to the endpoint, or even HTTP verb level. Here is a description, straight from Amazon S3: PUT, COPY, POST, or LIST Requests = $0...

Where Is The API Reciprocity Platform Designed Just For Managing API Operations

14 December 2015
I am seeing more operations focused API tooling emerge lately, like Stoplight.io, and as I'm adding API reciprocity platform DataFire to my list of integration, automation, and interoperability providers, I'm asking myself -- where is the API reciprocity platform designed specifically for managing API operations? I am talking about the Zapier, but just for API providers and consumers. With Datafire, I see things have a little more business and operations edge, than I've seen from more consumer offerings like Zapier. What I am hoping for, is someone to build a platform that lets you automate, integrate, and orchestrate all of your API focused operational needs across the cloud. This new platform will automatically setup monitoring using API Science or Runscope, when a new containerized microservice fires up...

Making Sure The Latest API Pricing Update Is Available In A Developer Portal Messaging Area

14 December 2015
I am spending a significant amount of time looking through the pricing pages for leading API providers, working to get a sense for some of the common approaches to API monetization in use across the space. Along the way I am finding some simple approaches from API providers that I wanted to share as bit-size API planning stories here on the blog. After recently landing on the pricing page for identity service provider Auth0, I saw that they included a simple message and link to the latest blog post about API pricing changes. It is a simple, subtle, yet very prominent approach to making sure your API consumers are aware of pricing changes that may impact their integration. I recently wrote about providing a messaging area to reach developers upon platform login, but this approach from Auth0 is about providing relevant messaging no matter where you are at in the developer portal--not just at login...

APIs In The Most Mature Sectors Have Pricing APIs

12 December 2015
A lot can be learned from the pioneers of the API space. Companies like Amazon and Twilio have been used as a model by many providers, and are something I reference often across my research and storytelling. These providers have been playing the API game for a while, so they have a wealth of experience to bring to the table, but they also are working with well defined, and highly valuable API driven resources which we can learn from. I'm neck deep in evaluating the pricing of modern APIs, and Amazon and Twilio both provide a wealth of things to consider when it comes to API monetization. One of the common patterns that has emerged for me, is the presence of pricing APIs: AWS Price List API - In order to meet the needs of these customers and to foster the development of even more tools that focus on cost management, budgeting, and the like, we are launching the AWS Price List API...

A Process To Aggregate RSS Feeds As APIs For Non-Developers

10 December 2015
A blog RSS feed is still my number one way to monitor what is happening across the API space. I also use RSS from Google Alerts and TalkWalker to monitor a variety of leading API industry keywords. RSS is an important information gathering format, and I wanted to help some of my non-developer followers, understand how they can aggregate RSS feeds across a variety of topics, clean up, and publish a centralized API for all feeds. To take advantage of this advice, you will need to have three separate accounts: Zapier - API reciprocity provider, helping you move your bits and bytes around online. Google - Online spreadsheet solution, which can be used to deploy APIs. Restlet - API deployment and management as a service provider...

Minimum Viable API Service Provider Blueprint

07 December 2015
There are some pretty good examples (in my opinion), of well defined API service providers across the API landscape right now-- companies, who are selling services specifically to API providers. You know how you can tell a good provider? They do one thing, or just a handful of things well, it is well presented, and they also have an API -- who woulda thought that? Companies selling services to API providers should also do so via an API! I am most definitely biased in showcase these companies, but a couple examples of this in action can be found with APIMATIC, Runscope, 3Scale, SecureDB, and API Scrience. These are all companies that I support, but I support them because they offer valuable services to companies who are operating APIs, and they do it in a simple, well thought out way, complete with an API...

75% Of Your API Efforts In The Enterprise Will Be Cultural And Political, Not Technical

07 December 2015
I started API Evangelist, because I saw a huge deficiency in the overall API conversation--nobody was talking about the business of all of this, and how you actually make money doing this emerging web API thing. Over time, I also discovered that very few people were also studying, and discussing the politics of APIs. Sure, when something flares up around terms of service violations, or there is an acquisition that the community dislikes, we discuss it, but we have to talk about the political issues in real-time, not at polarize-time. From my vantage point, the business and politics of API operations, internal as well as external influences, continue to be the number one things that negatively impact API operations, over anything technical...

Going Beyond Just JSON Data And Considering The Relationships That Exist, And The Actions That Can Be Taken

07 December 2015
I spent the weekend adding a Siren media type to my API building blocks API, in support of my API life cycle map work. Every time I dive into using Siren, and begin applying hypermedia constraints to my API design, I'm pleasantly surprised by what I learn. I am not a hypermedia evangelist, I am just trying to share what I learn, as I go evolve, and hopefully add to some of the existing knowledge that is floating around out there.  This work on my building blocks API is still very much a work in progress, when it comes to my own understanding of hypermedia, but also how I can use it to craft a more meaningful story around API(s). The first major benefit I realized, was instead of just have a basic JSON representation of my API building blocks, I was immediately forced to consider some very important dimensions around the JSON data I was serving up...

A Fun Way To Explore HTTP Status Codes With A Subway Map From Restlet

07 December 2015
If you were at @defrag or @apistrat in November, you know that I am working to better understand the often complex world of APIs using the Subway map concept. My goal is to better understand the overall API life cycle, as well as the life cycle of individual APIs, and how I can articulate, strategize, and execute on it all, using a subway experience.  It made me happy to see the folks over at Restlet playing with the same concept (we didn't coordinate on it honestly), to help articulate HTTP status codes, which is a very important topic for the space, and we need more education tools, and stories around it. Using the subway map analogy, Restlet provides a representation of the five areas of status codes, providing a simple way to explore them, and find a description of each individual status code...

API Client, Tool, Garage, Hub, Playground, Studio, Workbench, And Builders

04 December 2015
I am spending some time taking another look at my "client research", which started out as just about Postman and PAW, but now contains ten separate services I'm and bundling into this area of research. As with all my research areas, these project repos shift, evolve, split and marge with time, as the API space changes, and my awareness of it grows.  I  completely understand the term "client" doesn't provide an adequate label for this bucket of research, but for now, it will have to do. As I add a couple of new services to the bucket, and made my way through some of the existing ones I had, I wanted to step back and look at what they were offering, but more importantly the message that went around quantify what tehse companies were offering...

Automating API Key Management Using API Service Provider APIs, And Other Open Source Solutions

03 December 2015
I'm working my way through some of the low hanging fruit in my API notebook, when it comes to stories, and found a story thread I was working on regarding automating API key management. I'm personally storing my keys, across the private master branch for my API reps, because I don't have any super-sensitive data, and it helps me manage across hundreds of APIs, in a central way.  I've talked about the need to automate API key management in the past--with the number of APIs we are using, to reach the level of security we will need, the lower level of keys will need a global refresh and management process. This level of keys most likely won't ever result in large scale security breaches, but will cause plenty headaches for both API providers and consumers...

What Is API Service Composition?

03 December 2015
This is another one of those topics I talk a lot about, but only found few examples of me talking about on the blog--API service composition. If you aren't familiar with the concept, it is the art of taking digital resources (aka APIs), and mix and match them in different ways, until you find the right approach to delivering APIs, that provides value for both provider and consumer. API service composition is about taking the basic building blocks of any web API, the URL, path, and VERBS (ability to get, add, update, and delete), and put them into as many different configurations as you think makes sense. Limiting who can access, how much they use, restrict by time frame, and crafting different pricing for different users or groups, require trial periods, setup costs, and even restricting to specific countries...

API Economy Tooling For The Business Masses

02 December 2015
Most of the tooling and services I come across in the API space, are designed for developers. As I play with more services, and put tools to work, trying understand their role in the API space, some take a lot of work to figure out, while others are pretty clear--it will be these tools and services that the masses of business users adopt, as part of the API evolution that is occurring online currently. There are just a handful of services out there right now, that I think are mainstream ready, and are something that the average business user of the web, should be playing with right now--here are three of them: Restlet - Deploy API from a Google Spreadsheet. Blockspring - Use APIs in a Google Spreadsheet...

Using The Wikimedia Objective Revision Evaluation Service And Move Beyond Just GET With Your API

02 December 2015
I stumbled across Objective Revision Evaluation Service (ORES) last night, a web service running in Wikimedia Labs that provides machine learning as a service across Wikimedia Projects, and is designed to help automate vandalism detection and removal for content, being developed as part of the R:Revision scoring as a service project. As I came across, I was also considering different access plans across my APIs, with some of the plans allowing for updating existing content in the system--the topic of abuse of API access was on my mind. I'm curious if ORES could be applied to any sort of content or data post via a PUT / PATCH API request? Even if it didn't 100% out of the repo, maybe it could it be evolved to help manage the PUT / PATCH layer of API operations, allowing platforms to open up a little bit more, and open up more of their HTTP verbs, to a wider audience...

Realizing I Need Hypermedia To Bring My API Lifecycle Vision To Life

02 December 2015
I have been learning about hypermedia over the last three years now, and only earlier this year, I began playing with Siren to help me craft a better experience around my API industry news and link curation API. My motivations in going down this hypermedia road was never about easing my client side pain, or helping me with future versions of my API--I am just not that sophisticated of an operation. I started playing with hypermedia to help evolve the experience around the API news I was curating each week, making it so you could browse week by week, month by month, but also by topic, company, author, etc. I'm still trying to figure it out all out, and honestly the project is currently in the ditch after hitting the wall this fall, and not really giving a shit about the flow of API news...

What Licensing Should I Be Considering When I Take Open Source Software And Offer Up As An API?

02 December 2015
I've done this a couple of times now. I took PhantomJS, and created my Screenshot API, and used ImageMagick to create my Image Manipulation API. These are two openly licensed software solutions, which I took, and am using as an API.  What are my licensing considerations? If I keep my server side code licensed according to the specifications, am I fine? PhantomJS is licensed under BSD, and ImageMagick is Apache 2.0. Does the licensing extend itself to the commercial services I would potentially offer via an API interface? There are lots of questions to satisfy, before I move forward--I guess I am looking for a precedent. I am evaluating at a number of openly licensed software solutions right now to deliver a variety of stops along the API life-cycle, ranging from design, to deployment, virtualization, and much more...

The Growing Need For API Virtualization Solutions

01 December 2015
This conversation has come up over 10 times this month, at Defrag, APIStrat, and online conversations via Skype and GHangouts. The concept of API virtualization solutions. I am not talking about virtualization in the cloud computing and Docker sense, although that will play a fundamental role in the solutions I am trying to articulate. What I am focusing on is about providing sandbox, QA environments, and other specialized virtualization solutions for API providers, that make API consumers worlds much easier.  I've touched on examples of this in the wild, with my earlier post on API sandbox and simulator from Carvoyant, which is an example of the need for virtualization solutions that are tailored for the connected automobile solution...

Freemium Access For Your API Is Not Bad, It Is Just One Tool In Your Providers Toolbox

01 December 2015
I get regular links sent to me, and foiks telling me that freemium API access is a bad idea. That it doesn't help your API sales funnel, and was something that was just a thing, for a brief moment in time. The folks who always bring me these stories, are not API consumers, they are business folks.  I agree, there are some really bad examples of freemium in play across the API space, and with the bad behavior we see from API consumers, I fully understand why stories make their rounds--leaving a bad taste in the mouths of API providers for freemium access. The disconnect that allows this to happen in my opinion, is folks not thinking through their monetization, plans, and pricing in an API centric way...

Evolving My API Stack To Be A Public Repo For Sharing API Discovery, Monitoring, And Rating Information

01 December 2015
My API Stack began as a news site, and evolved into a directory of the APIs that I monitor in the space. I published APIs.json indexes for the almost 1000 companies I am trackig on, with almost 400 OADF files for some of the APIs I've profiled in more detail. My mission around the project so far, has been to create an open source, machine readable repo for the API space. I have  had two recent occurrences that are pushing me to expand on my API Stack work. First, I have other entities who want to contribute monitoring data and other elements I would like to see collected, but haven't had time. The other is I that I have started spidering the URLs of the API portals I track on, and need a central place to store the indexes, so that others can access...

Deploying An API From Your Critical Twitter Data Without Being A Programmer

01 December 2015
I am continuing my series on helping non-developers realize they can publish, and put APIs to work, without having an API expert in their pocket, using Zapier, Google Sheets, and Restlet. Its no secret that Restlet is an API Evangelist partner, and they are my partner because they are the easiest way to deploy a web API--something I am trying to help the "normals" understand the untapped potential of. As I finish up my @APIStrat conference again, for the sixth time, I'm reminded that I need to harvest the essential Twitter exhaust from the conference, otherwise if I wait too long, I won't be able to get it. You see, Twitter limits what you can grab from the Twitter API by either time, or number of Tweets, so I can only gather X amount of Tweets, and if I wait too long, I'm often out of luck...

Each Of My APIs Has Its Own Github Repo With Two Branches, One Private And One Public

01 December 2015

When Intelligent Programmers Realize They Do Not Understand HTTP And The Web That They Use Daily

30 November 2015
I've seen something at an ever increasing pace lately, situations where very intelligent software engineers hit a wall, and realize they do not understand the fundamental building blocks of HTTP, and the web that we are all using daily. It makes my heart ache, because I remember when I found myself in the same place, and still suffer from the deprivation I experienced. Whether it was my time programming in Microsoft-land, Drupal, WordPress, or any other Web 2.0-land, I eventually realized how much was hidden from me behind the curtain. When you bundled this with the fact I'm a fairly privileged white male software engineer who can be fairly clueless about what is around me, I missed a lot. Something I still find myself recovering from in 2015, even after five years of exclusively studying web APIs--you know, the ones that use HTTP for transport?  I'm not stupid, but with my lazerfocus ™, I often miss a lot...

Bridging How We Currently Document Our APIs Now With How We Should Be Experiencing APIs Via Hypermedia

30 November 2015
I am still catching up on my feeds, and open browser tabs, and one tab that has been open for a couple of weeks is Why Your Colleagues Still Don’t Understand Hypermedia APIs, by Luke Stokes (@lukestokes) of FoxyCart. The post is very thought provoking for me, and represents what I feel is the very pragmatic front of the hypermedia movement, from someone who has helped move the concept of a hypermedia API from academic discussion to reality, with the FoxyCart API. His challenges at the end of his post really set the stage for me: So how do we find a balance between idealism about what Hypermedia API documentation systems “should” be and what they practically are? How can we move the whole ecosystem forward by encouraging client developers to code to link relationships instead of hard-coded URLs? How do we help pave the way for the future but not look like unsophisticated outsiders in the process? What pragmatic steps should we take to be like the other cool kids using standard documentation presentations while at the same time saying, “Um, yeah, don’t do that...

I Like Being Able To Verify A Developer Is Real Before Giving Them Access to My APIs

30 November 2015
As I think about the bad behavior that occurs on the API consumption side of API operations, I'm considering ways that I can help API providers address these problems when they arise within their ecosystems. What can you do when bad actors have access to your APIs? Also more critically for some providers, what can you do to prevent bad actors from on-boarding with your API program at all? I strongly believe that companies should be as public with their API efforts as possible, but when it comes to which developers you let in, and which ones you don't, I'm finding I'm becoming more conservative in my thoughts--as long as you are transparent about the process. I'm still forming all of my thoughts around this (hence the blog post), and I'm sure is something that will keep evolving as I continue to push forward my awareness of the API space...

APIs Dedicated To Elections At the City, County, State, Or Federal Level

30 November 2015
I'm neck deep in government open data again, and as we are gearing up for the presidential election, you really begin to see the potential for accurate, real-time election data via APIs. There are a number of leading election-related APIs at the federal level like we have from the Sunlight Foundation, and you see the emergence of high value APIs out of government like the Federal Election Commision (FEC) API from the 18F, but with the amount of money in politics, and scope of what is at stake, I can't help but feel there is a huge opportunity out there for more election APIs. Seems to me that there is an opportunity for some API savvy activistpreneur to step up at the city, county, state, and even the federal level...

How Do I Price My API Resources?

30 November 2015
I am continuing to push my research around API monetization, plans, and partners forward, whilep preparing for my API lifecycle keynote at @Defrag and @APIStrat. Along the way, I am also exercising some of my API pricing and planning strategies with my partner in crime at APIware, as we think through some new products that we are developing. How I approach pricing for API products, is on a resource by resource basis, considering all of the API monetization tools in my toolbox. For example, when i launch two new API endpoints for exploding API definitions, and telling me how big my APIs are, I quickly run down my list of monetization building blocks to see which areas will apply to these new resources...

Making Sure Everything You Offer As An API Service Provider Is Portable

30 November 2015
Runscope added the ability to import and export your API tests as JSON, helping make API monitoring a much more flexible and portable thing. You can import and export using the Runscope UI, as well as import via their API, help you automate the setup of your API tests.  I judge API service providers based upon whether they have an API, and I am increasingly encouraging my readers to do the same. I will also be studying the portability of services that are being sold to API providers, and pushing for more import / export features like Runscope offers. I will be tracking on the API definitions used by service providers like Runscope, across the 26+ areas I monitor, and trying to better understand the JSON schemas they are using to encourage the portability of their services...

Keeping A Window Open Into How Power Flows Within Algorithms Using APIs

29 November 2015
I just read The Pill versus the Bomb: What Digital Technologists Need to Know About Power, by Tom Steinberg (@steiny), and I'm reminded of the important role APIs will (hopefully) continue to play in helping provide a transparent window into some of the power structures being coded into the algorithms we are increasingly relying on in this digital world we are crafting. In this century, we are seeing a huge shift in how power flows, and despite the rhetoric of some of the Silicon Valley believers, this power isn't always being democratized along the way. Much of the older power structures is just being re-inscribed into the algorithms that drive network switches, decide pricing when purchasing online, via our online banking, and virtually ever other aspect of our personal and business worlds...

The Bad Actors On Both Sides Of The API Fence

29 November 2015
I've always been a strong advocate for the API consumer, which is one of the primary motivations for me working to define best practices that API providers can follow across their operations. The majority of my negative experiences, when it comes to APIs, has been as an API consumer, not as an API provider. As I do this API Evangelist thing longer, and longer, the bad behavior by API consumers becomes more clear to me, and I'd say rivaling much of the bad behavior by API providers that I have seen, and in some cases helping actually drive it. I do not have any bad actors in my API community, but through conversations I have had with leading API providers, I'm hearing some pretty crazy stories...

The API Lifecycle (My Talk From @Defrag and @APIStrat)

29 November 2015
I recently told the story of how I view the API life-cycle, based upon my research across the space, at the Defrag Conference in Broomfield, CO, and at my API Strategy & Practice conference in Austin, TX. I spent two weeks pushing my research forward in preparation for these talks, and wanted to take a moment to gather my thoughts, and share the narrative of my talk. When I first gave this title and abstract for both the Defrag and APIStrat keynotes, I called it "the 17 stops along a modern API lifecycle". After pushing my research forward, to support these talks, it became 26 stops, then those became what I am calling "lines", resulting in me just call the talk "the API life-cycle". I use my public speaking as a vehicle for my API research, helping me polish my work, and ultimately pushing me to craft better narratives around my work, but most importantly, make it more coherent, and make sense to the average individual...

Providing API.json As A Discovery Media Type Every One Of My API Endpoints

25 November 2015
It can be easy to stumble across the base URL for one of my APIs out on the open Internet. I design my APIs to be easily distributed, shared, and as accessible as possible--based upon what I feel the needs for the resource might be. You can find most of my APIs, as part of my master stack, but there are other APIs like my screen capture API, or maybe my image manipulation API, that are often orphaned, which I know some people could use some help identifying more of the resources that are behind API operations. To help support discovery across my network of APIs, I'm going to be supporting requests for Content-Type: application/apis+json for each endpoint, as well as an apis.json file in the root of the API, and supporting portal...

I Am Thankful For Another Amazing APIStrat

24 November 2015
I am back home in Los Angeles, after another great edition of API Strategy & Practice--this time in Austin, TX. I have had a few day to decompress, and took a day to reboot my brain by crafting 235K+ API definitions for the English language, resulting in some time to reflect on what happened last week in Austin. First of all I want to thank 3Scale. Without the API infrastructure provider, APIStrat would not happen. Second I want to thank all the sponsor s who get involved, without your support the conversation wouldn't happen. Third, I want to thank the speakers and attendees for making it such a meaningful conversation. I tend to use that word, "conversation" a lot when describing APIStrat, but I feel pretty strongly that it is the conversation that occurs at APIStrat that helps move the entire API community in a very meaningful way...

Sharing 235K API Definitions With The English Language API Recipe Book

23 November 2015
I needed a side project to reboot my mind after @APIStrat this last weekend, so I opened up my notebook and picked a project that I've been meaning to give some attention to, one that would help me clean my slate, and let me get back to my regular work levels. The project I picked is one that I came up with a little over a year ago, but recently had flushed out my vision further, as I hung out at my favorite watering whole drinking an IPA. It took me several iterations before I landed on a name for this project, but my working title is the English Language API Recipe Book. I find myself in an awkward position these days, when it comes to the concept of API copyright, which is something I have taken a firm stance on with my work around the Oracle v Google ava API copyright case, and the release of the API licensing format API Commons, but is something, in the end, I just do not believe in...

The APIStrat Austin Schedule Has Reached That Level Of Amazing For Me Again

13 November 2015
This is the 6th edition of API Strategy & Practice, happening in Austin, TX next week. As one of the organizers, I can say that pulling together the perfect lineup of speakers and topics is always a daunting challenge, but then at some point before the event happens, the schedule always seems to take on a life of its own. The APIStrat Austin schedule has reached that point again. We have enough killer speakers and companies present, it has attracted other killer speakers and companies, resulting in a mindblowing 3 days of workshops, keynotes, panels, and sessions--if you haven't taken a look at the schedule lately, take a few moments. I was going through, looking for problems, missing photos, etc, and the scope of the people and companies present just struck me how amazing it has become, and I had to share...

Thinking Through The Licensing For An API Stack

07 November 2015
I've spent a lot of time thinking through the licensing we apply to APIs, as part of my work on the Oracle v Google API copyright case. The licensing around APIs is still in flux, with the current precedent being that APIs are copyrightable. Even though I do not believe this stance, I encourage API designers to make sure and apply one of the more liberal Creative Commons licenses to your API definitions, taking a pre-emptive stance in the conversation. In my experience most API providers, let alone consumers and the public at large, do not understand the separation between an APIs definition, and the code that runs the API, and often even the code that consumes an API. To help us visualize the separation, as well as think through the licensing implications of each layer, I have setup a specific research project that addresses API licensing, in hopes of spending time regularly researching the topic, as well as telling stories that help people navigate how to license their APIs...

The Swagger Spec Is Reborn As Open API Definition Format (OADF) After Being Put Into Open API Initiative (OAI)

05 November 2015
We reached another significant milestone in the API space today, after being acquired by SmartBear this spring, the Swagger specification is being moved into a Linux Foundation grouped called the Open API Initiative (OAI). SmartBear has been working with the core group of vendors including 3Scale, Apigee, Capital One, Google, IBM, Intuit, Microsoft, PayPal, and Restlet over the summer to hammer out the details of the organization, and the charter that drives the group forward. Its no secret, I am a pretty big support of the specification, and happy to see it be reborn, within the community driven group, as a community driven open spec. I’m looking forward to continuing my development of interesting things on top of the OADF specification, and telling stories about what the community is building as well...

Contemplating Hypermedia When My Focus Is On Experience

05 November 2015
I wish I had more time to spend on designing, and deploying APIs the way I desired. Without any real funding of individual APIs, I can only go so far with them, which usually doesn't go beyond the minimal viable API. However, even with this reality, I have two APIs I would love to see done right, and keep nagging at me. One API is my curated news API, which I currently have a pretty bare bones JSON definition to represent each news article I curate from the API space (date, title, author, body, url). As I have time, I've been trying to craft a Siren representation of this same resource. The opportunities for exploration of my archive of curated API news going back to 2011 is pretty huge (in my opinion)...

Adding An OAuth Scope Page As One Of My API Management Building Blocks

04 November 2015
I've had a handful of suggested building blocks when it comes to authentication, as part of my API management research, but after taking a look at the OAuth Scopes page for the Slack API, I'm going to add another building block just for listing out OAuth scopes. For platforms who provide OAuth, scopes are how access to users content and data is being broken down, and negotiated. When it comes to industry levels, OAuth scopes are how power and influence is being brokered, so I'm going to start tracking on how leading providers are defining their scopes--I am sure there are some healthy patterns that we all can follow here. I have had the pleasure of sitting in on OAuth negotiations between major utility providers, as part of my work with the White House and Department of Energy in the past...

@SlashDB Created The Ranking Digital Rights Corporate Accountability Index API I Was Asking For

04 November 2015
I read a lot of blog posts, and press releases about open data these days, and when I find a dataset I think offers a lot of value, or is just interesting enough to help push forward, I either try to incorporate into my Adopta open data work, or I just put it out to my followers to see if anyone can help. As I was monitoring the space yesterday I came across the Ranking Digital Rights 2015 Corporate Accountability Index, which "evaluates 16 of the world’s most powerful Internet and telecommunications companies on their disclosed commitments, policies, and practices that affect users’ freedom of expression and privacy."--I saw there was an excel and CSV versions of the report, but I didn't see an API, so I tweeted out: Done @kinlane https://t...

The 30 Areas I Am Working To Define In The API Space

04 November 2015
When I started API Evangelist in 2010, I tracked on one area--API management. Over the years this expanding to be about API deploy, and design, and most recently monitoring and discovery. As I approach the end of 2015, I've expanding this to be 30 separate areas of research. I have almost 200 projects I'm pushing forward in one way or another, but these 30 years reflect the API space I am working so hard to make sense of in 2015. While all of my research is a work in progress, I have these core projects as part of my regular monitoring, and I will be updating as much as possible. Design Hypermedia Definitions DNS Deployment Virtualization Containers Management Monitoring Testing Performance Security Terms of Service Privacy Branding Discovery Client SDK IDE Embeddable Webhooks Aggregation Reciprocity Real-Time Voice Spreadsheets Monetization Plans Partners Evangelism While this may seem like a lot of areas to keep track of, I'm finding it easier and easier to do, as it all continues to come into focus for me...

A Social API Performance Report From @APIMetrics

04 November 2015
APImetrics just released their second API Performance Report for Social Networks, aggregated from data they have been gathering from monitoring social networks since 2014. APImetrics is publishing the report to "..understand the impact these APIs were having on social media based on geographic location and specific cloud service provider." I'll let you read the report yourself, I just wanted to highlight the importance of this type of API monitoring from 3rd party services like APImetrics. The other providers I watch closely like Runscope and API Science also monitor 3rd party APIs like this, but I think publishing formal reports on a regular basis like APImetrics is doing, is healthy for the space...

Educating API Developers With Each Login Over At @CloudElements

04 November 2015
I am a big advocate for making sure the on-boarding process for developers is as friction-less as possible. Developers should be able to signup, and login without anything getting in their way. This is why normally I wouldn't suggest adding anything unnecessary to to signup and login process, but I saw something over at Cloud Elements that I thought was interesting. First, let me know that Cloud Elements gets bonus points because they emphasize signing in with your Github or Google account. I am a big fan of keeping all my API accounts linked to my Github profile--it just makes sense to me. I'd love it if API providers allowed me to store keys, SDKs, and other resources within my private Github repository, that I use across all the APIs I depend on...

To Incentivize API Performance, Load, And Security Testing, Providers Should Reduce Bandwidth And Compute Costs Asscociated

03 November 2015
I love that AWS is baking monitoring testing by default in the new Amazon API Gateway. I am also seeing new service from AWS, and Google providing security and testing services for your APIs, and other infrastructure. It just makes sense for cloud platforms to incentivize security of their platforms, but also ensure wider success through the performance and load testing of APIs as well. As I'm reading through recent releases, and posts, I'm thinking about the growth in monitoring, testing, and performance services targeting APIs, and the convergence with a growth in the number of approaches to API virtualization, and what containers are doing to the API space. I feel like Amazon baking in monitoring and testing into API deployment and management because it is in their best interest, but is also something I think providers could go even further when it comes to investment in this area...

API Consumption Moves To The Main Stage At @APIStrat Austin This Month

03 November 2015
When planning the API Strategy & Practice Conference, the team works very hard to make the speaker and session line up reflect what we see across the API space. The conference is meant to be an open, non-vendor and non-product focus, discussion about what individuals and companies are facing when it comes to being API providers, as well as API consumers. When we closed the call for papers for APIStrat this year, it was clear that API consumption would be one of the sessions, but  as we progressed in the process of locking down talks it was clear that API consumption should be something that we should move to the main stage. To help highlight the importance of this discussion, I wanted to ask Mark Boyd (@mgboydcom), the conference chair for APIStrat his thoughts on why we did this: This year has seen two major API consumption challenges: For API providers looking to continue their growth, 2015 has often been about putting their API in front of non-dev users and making their API accessible to a wider audience...

Even Non-Developers Can Create An API Using Popular Form Services, Zapier, and Restlet

02 November 2015
I have a notebook of story ideas I can do from any moment, but I find that I foten need some sort of inspiration to kick them off properly. I got that this afternoon in a Tweet from Leah Bannon, reminding me how important it is for me to have stories for non-developers. Tools that make it easier for non-devs to do stuff with APIs are the most under appreciated and awesome things in tech right now imho — Leah Bannon (@leahbannon) November 3, 2015 There are many tools available right now that let's anyone publish an API, you just have to know the right tools, and right process to get the results you need. Thanks to Zapier, you can connect to the API driven services of a wide variety of cloud tools, and using Google Spreadsheets and Zapier, you can easily store data and content, to be used in a simple API--all without writing any code...

Expanding My API Partner Research Into Its Own Project

02 November 2015
As I explore through API portals, looking for the successful approaches to APIs, I'm increasingly seeing formal partner programs, resulting in me expanding the topic as its own research area. My objective is to keep track of how the APIs I track on operate their partner programs, resulting in the list of organizations I reference in my research. I also want to try and identify what some of the common building blocks of API partner programs are, in addition to the news stories that I have curated about partnerships--which is the fuel of my research. I have recorded 31 separate partner programs, which I found through the course of my API monitoring and research.  Amazon Web Services AssureSign CallFire Cloudflare Constant Contact Dandelion Developer Media Disqus DocuSign Dyn eBay Eventbrite API Facebook Gigya Google IBM Watson InfusionSoft LinkedIn Mailjet Moz MYOB API Pinterest Salesforce SendGrid Shopify SurveyMonkey The Guardian Twilio Twitter VerticalResponse Xero These are all companies who have formal partner efforts that provide a higher level of access to their API...

Please Tell Your API Stories

02 November 2015
Many of you that have attended any of my talks, have heard me tell the audience about the importance of sharing your API stories. As an API provider it is the most important tool in your toolbox, above and beyond any technical or business advantage you have. I'm spending more time lately, gathering up the things I say over and over in my talks, and other in-person conversations, and craft simple stories that echo these little nuggets of wisdom on the blog. If you do not tell the story of what your API is doing, nobody will know--it really is that simple. The drumbeat from your blog, should echo the activity that is going on via your API. Your day might be filled with a hectic stack of activity from your view, but your API consumers, analysts, and storytellers like me, we do not see any of this activity, and we all need to hear about your day on your blog, amplified by your active Twitter account...

After Combining My API Plans, Pricing, And Rating Research I See Hints Of An API Industry Economic Engine

31 October 2015
After writing I Have A Bunch Of API Resources, Now I Need A Plan, Or Potentially Several Plans, and How Are We Going To Create The Standard And Poors And Moodys For The API Economy, I wanted to combine what I had learned while crafting these stories, and try to look at how these two areas could work together. The API plan and pricing research is derived from existing approaches to API service composition introduced by providers like 3Scale, however the rating portion is fresh territory for me, with very few precedents to follow. What I see when I start wading through a structured approach for API providers to craft meaningful API plans to serve up their API resources through, and how developers will be paying for API usage, via the apps they build, I begin to see the potential of a structured approach to API plans, and pricing...

I Have A Bunch Of API Resources, Now I Need A Plan, Or Potentially Several Plans

31 October 2015
I have some really amazing resources exposed as APIs. Everyone is doing it these days, and I have some good ones, now I just need a plan. You know, actually, I need several plans, that will help me expose these resources to the right people, while remain as much control as I need, and also generate revenue from these resources, tailored to whoever I am offering them to. Starting With The Essential API Building BlocksI want to allow anyone to access my valuable APIs, however I want to control exactly how much they can access, and even limit it to a free trial, and a small amount of calls upon the API. I am going to call this Plan A, also known as my freemium layer, meant to just wet the appetite of any potential API consumer...

How Are We Going To Create The Standard And Poors And Moodys For The API Economy?

31 October 2015
API rating is a conversation I have several times a year, with different groups, and is a conversation that seems to occurring with a little more frequency in recent months. How do we know which APIs are the good ones? What constitutes a good API? How do we measure whether a contract (the API) is being adhered to, by both API provider, and potentially the consumer as well. How will we establish the Standard & Poors or Moodys for the API economy? These are the API rating conversations I am having with folks. These are all great questions, and something many companies have approached me looking help in solving, with nobody moving forward with this in a meaningful, and sustainable way. So to help apply some CPR to the subject, I am going to explore API rating some more, from my own point of view, in hopes of guiding some existing conversation I'm already having on the subject, and also hopefully generate some new ones...

API Visualization Exploration Using API Definitions

29 October 2015
There are number of areas across the API life-cycle that are being expanded upon in the current space, thanks to the evolution of API definition formats like Swagger, API Blueprint, and RAML. One area I haven't seen as much growth as I'd like, is in the area of visualizations driven by API definitions.  There are two distinct pools of API definition driven visualization: 1) Letting you visualize the surface area of an API 2) Letting you visualize the resource made available via an API. One area my friend the @APIHandyman has been exploring is around the surface area of API. @APIHandyman has a nice prototype created that he is calling "Swagger Specification Visual Documentation". The API Definition driven visualization uses A D3...

An API Idea: HTTP Status Code Clinic

29 October 2015
This is one of my ideas for an API service provider, that I will never get time to do, but would love to see exist in the space, so I am happy to put out there for someone else to do. I'm calling this one an HTTP Status Code Clinic, which would be an API definition driven API service provider (why would you do it any other way in 2015), that would help API providers tailor more useful, and meaningful HTTP status codes. HTTP Status Code Clinic would be a simple software as a service, complete with its own API (why would you do it any other way in 2015), and CLI for operating as well. You would pass it a Swagger, API Blueprint, RAML, or any other API definition format, and it would return a bunch of feedback on HTTP status codes returned (or not)...

Adding A New Research Area To API Evangelist I Am Calling #APIDesignFiction

28 October 2015
I have been writing some fictional stories on a project site I have called Alternate Kin Lane for some time now. Writing fictional stories in the tech space has provided a sort of pressure release valve for me, giving me a quick creative outlet throughout the week. Honestly, there are more stories in my notebook, than there are on the actual blog, but this is a sign for me that I need to spend more time working in this area. I am making several shifts in my work lately, in response to kind of hitting the wall recently, a process that includes rethinking how I work on projects, and partner with folks in the API space, as well as an increased focus on the fictional side of my writing. I do not just want to write fiction that is derived from the tech space...

Hand Crafted Or Generated SDKs For Your API?

28 October 2015
One of the discussions we are having behind the scenes at APIWare.io, is whether we should be hand-crafting, or auto-generating SDKs for the clients we are working with on the design, deployment, and management of their APIs.  The answer is easy--we do both!  There are many situations where I would push for the API SDKs to be hand-crafted, and designed for a specific API, as well as specific language or platform. However, with the increase in the number of APIs, and simplicity of some of the APIs I work with, crafting an API definition, and auto-generating your SDKs using a service like APIMATIC, makes sense. I've cracked open the APIMATIC SDKs, and only being fluent in JavaScript, PHP, Python, Ruby, and C#, I can only speak to these realms of operation, but I'm happy with what the APIMATIC team is producing...

The Ability To Deploy Your API Heroku Is A Gateway Drug To The Wholesale, Containerized API Economy That Is Coming

27 October 2015
I was talking through the features, and roadmap for SecureDB with their team the other day, and one of the conversations that came up was around on-premise opporutnities for deploying encrypted user, data, and file APIs. In my opinion, on-premise is something that has morphed from meaning "in our data center", to where wherever we store data and run our compute power--which could be spread across multiple cloud vendors. SecureDB offers an extremely valuable API commodity in 2015, encrypted user, data, and file stores--something EVERY website and mobile application should have as part of their back-end. When you have something this valuable, and potentnially ubiquitous, it needs to run wherever it is needed...

API Monitoring Should Be Baked Into Your API Strategy By Default

27 October 2015
As I've written several posts on the recent Amazon API Gateway release, one of the side things I noted about the API solution from AWS, was that API monitoring is baked in by default. As stated on the AWS API Gateway page: After your API is deployed, Amazon API Gateway provides you with a dashboard to visually monitor calls to your services using Amazon CloudWatch, so you see performance metrics and information on API calls, data latency, and error rates. This may seem like common sense to many people who have been in the API space for a while now, but for many API designers, architects, developers, and business folk who are just getting going, API monitoring may not be default for all implementations...

Which API Service Providers Across The 20 Areas I Track On Have APIs?

27 October 2015
As I go through each of the 20 core areas of the API sector that I am keeping an eye on, in preparation for my keynotes at @DefragCon and @APIStrat, I'm taking a fresh look at which of them have APIs. When you think about it, if a company is selling a product or service to API providers, encouraging an API focus--they should probably have APIs. :-) As I was updating some of the news, companies, and reviewing the common building blocks I have aggregated across the 20 areas of research, I just poked my head around to see if I could find an API for each service provider. There are many things that look like a language specific API, but I am looking for a clear developer / API area, with a coherent web API available, as we'd expect from API providers in 2015...

Learning About APIs From @darrel_miller And @gblock With In The Mood For HTTP

27 October 2015
As you probably know, I'm always up for learning about APIs, so when @Darrel_Miller and @GBlock started doing their In the Mood for HTTP podcast, I was all in. Both Darrel and Glenn are API experts, and respected leaders in the space, but more importantly both of them are super nice guys, and reflect a tone I love to experience and support across the API space. The format for In The Mood For HTTP is simple. The audience asks questions, and Darrel and Glenn discuss. They are both very graceful in how they answer questions, extremely knowledgeable on the subjects at hand, but they are also very opinionated, and they don't always agree--the exchange between them is educational, and very benefitial to the wider API community...

Where Do I Start With The Storytelling Drumbeat For Our API?

26 October 2015
It can be difficult to know where to start when it comes storytelling around an API. Many of us who have been in the space, have followed the lead of Twitter, Twilio, Amazon, and others, but when you are new to the space, knowing where to start can often be paralyzing. This is something I am regularly helping clients and partners think through, and while I'm thinking through the topic with SecureDB, I figured I'd share the details with you my readers. If you are unfamiliar with how the API Evangelist network operates, I have common building blocks available for almost 20 core stops along the API lifecycle. However, when many of my partners and clients are just getting going, they are often overwhelmed by the volume of data I provide, so I regularly find myself tailoring, and distilling down a specific strategy for each conversation I engage in...

The Emerging Need For API Key Management Solutions

24 October 2015
An API key management service targeting Drupal developers came across my radar this week. The service is very focused, in that it is a Drupal module, and is focused on helping Drupal developers manage the keys they use across a single app or installation, but I think it represents a potentially larger trend. I think this particular solutions is just a symptom of a growing problem for developers of any type--how do you manage the number of keys you are depending on for you application(s). API consumers are in need of a plug and play way of to store, access, and manage the increasing number of API keys they put in use, otherwise we will be looking at a pretty serious security problem, adding to the existing security issues API providers and consumers face...

Successful Patterns For Multi-Lingual APIs and Documentation

24 October 2015
I had a follower tweet out an interesting question about successful patterns for multi-linguarl APIs, which I thought was interesting enough to share as a story, adding to my research, and helping me tune into the topic better.  As the API economy unfolds, and APIs make their way into more countries around the globe, the need to standardize how we internationalize different layers of our API operations is only going to increase--making these types of conversation starters very important. Here is the Twitter thread: @phillipadsmith @kinlane The Accept-Language header is a good start. https://t.co/Gt6TuUUSB2 — pete gamache (@gamache) October 21, 2015 @gamache @kinlane Root of my Q is headers vs...

Voice as the Next Generation API Client

23 October 2015
Shortly after the Zypr voice API came on to the scene in 2011, I launched my research into voice APIs. Like many other areas of the API universe, voice has come in and out of focus for me, something I think will take much longer to unfold, than any of us could have ever imagined. Zypr quickly ran out of steam, and other similar solutions have come and gone over the last couple years as well, leaving my research pretty scattered across many different concepts of how voice and APIs are colliding--lacking any real coherency. I took a moment last week to take a fresh look at my voice API research, because of a comment by Steven Willmott (@njyx), the CEO of 3Scale. Its not an exact quote, but Steve spoke about how voice is the future of API consumption, after he had attended the AWS:Reinvent in Las Vegas...

Reconciling My API Orchestration Research With the Evolution of IDE, SDK, and HTTP Clients

23 October 2015
I've been tagging companies that I come across in my research, and stories that I find with the term "orchestration" for some time now. Some of this overlaps with what we know as cloud-centric orchestration using Puppet or Chef, but I am specifically looking for how we orchestrate across the API lifecycle which I feel overlaps with cloud orchestration, but pushes into some new realms. As I'm carving off my orchestration research, I am also spending time reviewing a newer breed of what I'm calling API hubs, workspaces, or garages. Over the last year, I've broken out IDE research from my overall API Discovery research, and SDK from my API Management research, and client from my API Integration research...

API PLUG, A New Containerized API Design, Deployment, and Documentation Solution

23 October 2015
I started playing with the possibilities when it comes to API deployment using virtual containers like Docker early this year, exploring the constraints this approach to API deployment introduced, on my own infrastructure. The process got my gears turning, when it comes to deploying very simple data, content, and algorithmic APIs into any environment that runs Docker.  As 2015 has progressed, I'm seeing containers emerge as part of more stops along the API life-cycle, specifically in deployment and virtualization. A new one that just came across my radar is API PLUG. I haven't played with the containerized API deployment solution yet, but after watching video, and looking through site it seems in line with what I'd expect to see from a next generation, containerized, API deployment solution...

I Am Pumped for Two Upcoming Keynotes at DefragCon and APIStrat in November

23 October 2015
I am keynoting APIStrat in Austin next month, and it is a big deal for me. Ok, its my event, and I probably shouldn't be that excited, but it is the first time I've ever keynoted it. ;-) It is the sixth edition of APIStrat, and Steve asked if I wanted to keynote, which I dismissed because it seemed too ego, but when he pushed back, I realized that I would be stoked to keynote. I'm excited about the preparation for the talk, and trying to think about how I can incorporate my research, and working API operations into it. I'm also keynoting Defrag the week before, so both my keynotes will march in lockstep. They won't be the same keynote, but they will reflect what I'm seeing across the API space right now, allowing me to use both venues as vehhicle to move my research forward...

Adding a Suggested API Definition for API Portals to My API Management Spec Collection

22 October 2015
One layer I am working to add to my API research, are machine readable API definitions that I find, or generate from the APIs of the API service providers I keep an eye on. Within this new layer I'm aggregating these API the specs of the companies who are offering services within the emerging areas of the API sector. The first area I've started aggregating is within API management. 3Scale was very forward leaning with their willingness to open up their API definitions for their own API management infrastructure APIs. These are API specs that describe all of the features of the 3Scale API management platform, and represent one possible blueprint that API management service providers could emulate...

The Marketing in the API Space Session at @APIStrat Austin Next Month

22 October 2015
Marketing your products and services in the API sector can often look very different than marketing of products and services in other sectors. Developers are a very different target audience, and to make things even more complicated, not all developers are created equal! Open developer are not like the enterprise developer, and healthcare developers won't have much in common with device-based, Internet of Things developers.  How to market your API has been a session at every APIStrat since we did the first conference in New York City back in February of 2013, and we just announced the latest edition of marketing for APIs at @APIStrat in Austin in November. Here is the lineup we have for this round: Thursday Bram (@thursdayb) Urgency Inc...

How To Build An API Brand Through Consistent Storytelling

22 October 2015
I just had a call with one of my newer API partners, working with them on crafting version 1.0 of their API evangelism strategy, and the subject of what content to generate, and which channels to use, when building up their brand arose. In my work, about 90% of the approaches I see implemented by API providers is a traditional PR strategy, where you create content, and push to popular channels to do the work of syndicating the message. While this approach works, and is something I recommend you do, I have a different way of building up my brand, and the partner or community brands that I invest in. All of this begins with something that truly brings value to the table for everyone involved, without this, my approach will not work...

If Twitter Can Deliver Transparency Around API Access and Business Model, They Might Be Able To Find Their Way Again

22 October 2015
It has been a year or two since I've given any deep thought to the Twitter ecosystem. There has been such little meaningful action to come out of the social platform over the last couple years, I had all but given up on it being a platform with any sort of future for developers. When Jack Dorsey apologized and solicited feedback from the community this week, I honestly felt I didn't have much to offer when it comes to advice--I just wasn't prepared. Twitter does almost everything right when it comes to their developer ecosystem...well on the surface, where they do fail, is within the most critical areas of API operations: Communication - Twitter communicates about the usual mundane API platform stuff, but really lacks a tone and substance that really cuts through the BS for developers...

An API For Finding Government Websites That Do Not End In .gov

16 October 2015
I have used the Federal Agency Directory API for quite some time to lookup federal government agencies. USA.gov has some highly valuable, and simple APIs including the Social Media Registry API, which I find extremely useful. They recently added a new one for searching government websites that do not end in .gov. The Non-.gov URLs APIs allows you to search for all websites that end in .com, .org, .edu, or other top-level domains, including: Federal, state, local, tribal, commonwealth, and territorial government agency websites Federal reserve banks and branches Federal home loan banks Libraries, archives, and museums, including Presidential libraries Department of Defense websites for recruiting and service academies Travel and tourism websites for states and U...

An API For Encrypted Storage Of All Your Accounts, Data, Files, And Setting

16 October 2015
I've been working on expand upon my API security research, but it can be difficult to find API focused security solutions. Exactly what is security when it comes to APIs can vary. Are you looking to secure your APIs? Are you looking to secure your data or content using an API? This is why I started a research projects so that I can turn on my keyword monitoring, and begin scouring the landscape in real-time--the more I conduct research in an area, the better I get at it. The best part of my research is that sometimes when I write about things, companies just come to me. This happened the other week, with an encrypted database API provider called SecureDB. What this brand new API driven platform provides is default security for your accounts, data, files, and settings--exactly what we need in this cyber-insecure world we have created for ourselves...

You Can See Evidence Of The Expanding API Lifecycle In The New AWS API Gateway

15 October 2015
It is up to API providers to establish a coherent approach regarding how they rollout and manage their APIs, something that historically has just involved deploying and managing, but in the last couple of years we have seen more formal approaches emerge, something we are all calling the API lifecycle.  In 2012, after we started standardizing our API development and management thinking using API definitions, the expansion of the API lifecycle was set into motion with the introduction of an API design-first way of thinking from the Apiary team. API definitions allowed us to get our development and management house in order, but also begin collaborating, mocking, and having a conversation around our API designs, way before we began the costly process of writing code...

Establishing A Common API Definition That API Management Providers Can Use

15 October 2015
I mentioned the concept of what I call API building blocks coming to life by API service providers yesterday. These are the features provided from API service providers that are made accessible via APIs. Mind blowing right? API service providers having APIs? Which then allows API providers to programmatically manage the operations of their own APIs? Who would have ever thought!! Actually it is a pretty clear example of API service providers who are kind of full of it, when they do not offer their own APIs--meaning they are telling you about the importance of APIs, but not actually practicing what they preach. It is kind of like API providers who do not use their own APIs in their applications (dogfooding)...

NASA Is Rocking It With Their Very Inspirational And Simple APIs

14 October 2015
NASA just launched two new APIs, as part of their open data efforts. I find the APIs they offer to be simple, and very inspirational examples of what an API can be. Maybe I just love space, but seeing these well designed, very fun APIs out of our countries space agency is just cool. They added a Near Earth Asteroids API, and a Mars Rover Photos API, and they also understand the value of telling the story of the release on their blog. Remember API providers, if you launch an API in the woods and don't blog about, nobody will know about it--storytelling is one of the most important tools in your toolbox. Also, your APIs don't have to be complicated, and overthought. Just providing GET access to interesting images and other content like NASA is doing can really go a long ways in generating attention (it got me to write a blog post)...

Your API Strategy Provide A Glimpse Into Your Company Culture

14 October 2015
Maybe I've looked at too many APIs, but I feel that APIs are very telling of the overall culture of a company. APIs that are trusting, tend to open up a full stack of APIs, including POST, PUT (or PATCH), and DELETE functionality, giving developers access to all, or nearly all functionality available via a platform. I do not feel that platforms are required to open up everything, but the amount of what they open up, does tells a lot about how a company is thinking. While I find many companies are not fully up to speed on the benefits a modern API management strategy, and the control it gives you over resources and API consumers, I think many just do not trust anyone outside the firewall, and think they know best when it comes to everything...

Another API Definition Conversion In The Works From The LucyBot Team

14 October 2015
I wrote about the ability to convert between multiple API definition formats using API Transformer the other day, a solution being developed by the APIMATIC team, and shortly after posting, the LucyBot team pointed out they are working on a similar tool. This is one of the reason I try to write these posts, it always brings folks out of the woodwork. It is good to see multiple efforts out there. Converting of API definition formats is a fast growing need for both API providers and consumers, something that is only going to grow with the adoption of popular API definition formats. I feel it is a healthy sign that standard tooling for converting common API has emerged, and an even better sign that there will be a diverse selection in this tooling...

Bringing API Building Blocks To Life As The APIs Of Service Providers

13 October 2015
If you have followed my work since 2010, you know I pull out what I call the common building blocks of originally just API management, but over the last five years this has grown to 17 areas of the API life-cycle. My goal is to better understand the common features offered by API service providers, but only the ones that will also matter to API consumers at the same time. In the last couple months I started tracking on how these API building blocks match to actual APIs offered by the API service providers I monitor. What do I mean? Well, when you consider the common building blocks offered offered by API management providers, these building blocks come to life when you look at the API offered by 3Scale...

3Scale Sets Example By Augmenting The Amazon API Gateway With Their Own API Infrastructure

10 October 2015
One of the things that really bothers me in the API space is when API service providers are too competitive, establish silos, don't use APIs themselves, and refuse to provide interoperability with other service providers. It is the API space y'all, this shit needs to work together, if we expect anyone to buy into what we are selling--if you aren't confident of the product you are selling, you probably shouldn't be in business. This is why it makes me happy to see the work 3Scale has done in integrating their own API infrastructure with AWS API infrastructure. You can find the details of the integration opportunity over at 3Scale, but I want to focus on the subject of API service providers working together, even if it is externally augmented like 3Scale did, as opposed to formal partnership...

Some Thoughts For The Coming Wave Of API Hubs, Garages, and Workbenches

06 October 2015
I've been getting demos of some pretty interesting new work spaces meant for API architects, and designers. Examples of this are API Garage, RepreZen API Studio, and the recent SwaggerHub. These are just some of the API life-cycle solutions I'm seeing emerge recently, where companies are trying to provide API design, development, and deployment solutions in a single, tidy, work space. Now that the API life-cycle has expanded beyond just API management, deployment, and design, into testing, monitoring, security, and beyond, I predict these types of API work-spaces that span multiple stops along the API life-cycle will become common place. To help prime the pump, and ensure there will be more viable products launched, I wanted to share a few thoughts on what these solution providers should consider as part of their offerings...

Thinking Through Some Of My Defensive API Management Tactics

06 October 2015
As I add each API to my stack, I consider security along the way. I require an API key to access all of my APIs using my 3Scale API management infrastructure, and I also have different tiers of access, and while defining this management layer my first impulse is always put POST, PUT, and DELETE methods into the most trusted tiers. The service composition layer in API management is where I feel the heart of API is--the thing that makes it different than SOA, and other approaches. This is where you can loosen things up, trust your 3rd party developers, and allow serendipity to occur. If you always default to locking things down, and only allowing the updating of resources by internal, or just trusted external sources, you are limiting the possibilities...

Playing With The New SwaggerHub

02 October 2015
I received a personal demo of the new SwaggerHub from Mr. Swagger himself -- Tony Tam, this last week. SwaggerHub is a new API life-cycle hub, centered around the API definition format, developed by the SmartBear Swagger team. The new hub brings together all of the Swagger tooling into a single, collaborative web application, that allows you to manage API definitions through varioius stages of the API life-cycle. SwaggerHub lets you import and export your JSON or YAML Swagger definitions, giving you an environment for storing, searching, versioning, and collaborating around the definitions. Using the platform, you can edit Swagger definitions using Swagger Editor, generate server and client side code with Swagger CodeGen, and play with the API using Swagger UI--all wrapped in this new versioned and collaborative API design environment...

A Minimum Viable Existence For Four Of My New APIs

26 September 2015
I have a whole bunch of APIs I want to deploy. There is a queue of APIs that I will never get to, but I can't help myself, and when I am tired of watching what everyone else is doing, and want to get busy actually building things, I crack open my queue of ideas. This weekend I launched four new APIs, that will be in the service of some very different objectives that I have. Low Hanging Fruit - Identifying the potential CSV, XLS, XML, and table resources that exist in any domain, and publish them to Github as a list for deploying as APIs - aka the low hanging fruit. TSA.Report - A simple form for submitting your thoughts as you are going through the airport line. APIs.How - The URL shoretner for the API Evangelist and Kin Lane network--getting off Bitly...

How Open Source API Proxies, And Other API Services And Tooling Can Strategically Partner

24 September 2015
I was gathering my thoughts today around API management solutions can better work together, in response to an industry discussion going on between several creators of open source tooling. The Github thread is focused on proxies, and how they can work more closely together to facilitate interoperability in this potentially federated layer of the API economy, but as I do, I wanted to step back and look at bigger picture before I responded.  As I was gathering my thoughts, I also had an interesting conversation with the creator of API Garage, in which one of the topics was around how we encourage API service providers to want to work closer, but this time from the perspective of a API client workspace...

Converting Between The Popular API Definition Formats Using API Transformer

22 September 2015
My own API management system allows me to import Postman collections, HAR files, Charles Proxy XML files, and Swagger version 1.2, but when it comes to output, it only speaks Swagger 2.0. I've been wanting to create a tool for outputting my definitions as API Blueprint for some time now, but just haven't had the time to do the work. I have been secretly hoping someone would build a good quality, so I wouldn't have to do this work myself. Now I have API Transformer, an API definition translation platform, developed by the APIMATIC team. Using API Transformer you can upload or pull API definitions in the following formats: API Blueprint Swagger 1.0 - 1.2 Swagger 2.0 JSON Swagger 2.0 YAML WADL - W3C 2009 Google Discovery RAML 0...

Adding A Page To My Research For Tracking On Swagger Extensions

22 September 2015
I have a research project dedicated to trying to understand al things Swagger. I try to add any new research, or tooling there when I can. The latest thing I added was a page to list out Swagger extensions that I find in the wild. I knew Apigee has extended Swagger in some interesting ways, but I was coming across other interesting examples, and want to try and aggregate into a single location, so that others can reference and build upon.  There is now an extensions page on my Swagger research. I have added APIMATIC's x-codegen-settings, a couple from Apigee to kick things off. If you know of any interesting examples of Swagger extension, please let me know via the project's Github issues, or feel free to fork the project and add to the extensions page using the _config...

Having The Resources You To Need To Scale Your Startup API Team For That Enterprise Project

21 September 2015
I just sat in on an APIWare call with a fast growing startup, developing a better understanding of how we can assist their team. They have a pretty solid development team behind their API, so providing core API development resources is not in the cards.  Where  this startup is needing the most help, is where the APIWare team shines: API Operations Review - Taking a look at how an API platform works from the inside out, preferably starting with an outside perspective, so we can bring that fresh perspective to the table, and immediately begin adding value to the road-map. Crafting API Strategy - With a better understanding of how an API works, inside and out, we can take a walk through our massive list of best practices, and see what we can apply when it comes to bringing together a strategy...

A Suggested, And Sponsored Link Relation Engine For Hypermedia APIs

21 September 2015
Sometimes I have ideas, that are sticky, meaning they won't leave my brain, but are not always concepts I personally enjoy exploring. This is just a little insight into the madness that is my brain, focus Kin...FOCUS! So, I found myself thinking last week about API monetization, while I was also updating my API design and hypermedia research--then, during this Reese's peanut butter cup moment, I came up with an idea for a suggested or sponsored link relation engine for hypermedia APIs. First, I'd prefer to start with what I'd consider to be a hypermedia suggestion engine, that could provide external suggestions for related links to any structured data that is being returned via an API. It is a suggestion engine that an API provider, who has followed hypermedia principles as part of their API design, could use to augment the resources they are serving up...

Adding A 3rd Dimension To My API Monetization Thinking

15 September 2015
When it comes to the API space, it always takes numerous conversations with API providers and practitioners, before something comes into focus for me. I've spent five years having API management conversations, an area that is very much in focus for me when it comes to my own infrastructure, as well as using as a metric for reviewing the other public and private APIs that I review regularly. While I have been paying attention to API monetization for a couple years now (thank you @johnmusser), in 2015 I find myself involved in 20+ conversations, forcing the topic to slowly come into focus for me, whether I like it or not. When talking to companies and organizations about how they can generate revenue from their APIs, I generally find the conversation going in one of two directions: Resource - We will be directly monetizing whatever resource we are making available via the API...

API Definitions Broker Critical Conversations Between Business And Developers Who Are Building NextGen Web, Mobile, and Device Apps

15 September 2015
If you are in an industry being impacted by technology, you have probably become very aware of the term Application Programming Interfaces, more widely known as APIs, and how they are driving web applications, mobile applications, and increasingly everyday objects in our homes, cars, businesses, and across the public landscape. If you are finding yourself part of this growing conversations, you have most likely have also heard talk of a new breed of API definition formats that are becoming ubiquitous like Swagger and API Blueprint. API definitions are a way to describe what an API does, providing a machine readable blueprint of how to put the digital resource to work. API definitions are not new, but this latest round of available formats are taking the API conversation out of just IT and developer groups, and enabling business units, and other key stakeholders to participate throughout the API life-cycle...

There Is A Big Opportunity Right Now When It Comes To API Design Tooling

14 September 2015
API design and definitions are the number one area when it comes to talks submitted for APIStrat 2015 in Austin, and when it comes to traffic across the API Evangelist network in 2015. After diving into the Amazon API Gateway a little more over the weekend, I was reminded of the opportunity out there when it comes to API design tooling. Amazon did a good job, providing a GUI interface for crafting the methods, resources, and underlying data models for APIs you are deploying using the gateway. However when you compare to some of the GUI API design editors I mentioned in my last post on this subject, from Restlet, APIMATIC, and Gelato, the Amazon interface clearly needs evolve a little more. AWS is just getting started with their solution, so I'm not knocking what they have done...

Are There Really Any Monetization Opportunities Around Open Data And APIs?

14 September 2015
One of my readers recently reached out to me, in response to some of my recent stories of monetization opportunities around government and scientific open data and APIs. I'm not going to publish his full email, but he brought up a couple of key, and very important realities of open data and APIs that I don't think get discussed enough, so I wanted to craft a story around them, to bring front and center in my work. Most open data published from government is crap, and requires extra work before you can do anything with it There currently are very few healthy models for developers to follow when it comes to building a business around open data Business people and developers have zero imagination when it comes to monetization -- aka ads, ads, ads, and more ads...

A Data Migration Tool To Help You Import, Export, and Sync Your Data In The Cloud

14 September 2015
The Element Loader from API service provider Cloud Elements came across my monitoring this week, providing a configurable JavaScript application that help simplify data migration, allowing you to move content and data between cloud platforms, by putting their APIs to work. The Element Loader is interesting to me as an evolution to the concept of what I’ve long called API reciprocity, where companies like Zapier allows you to migrate your bits and bytes between the platforms we are all increasingly finding ourselves dependent on. I think Cloud Elements is moving the needle forward just a bit, by formalizing a tool that is dedicated to real-time sync, between the platforms you depend on...

Working Hard To Generate API Value Within An Entrenched Legacy Industry Like Real Estate

12 September 2015
I preparing a talk this week in Portland, OR, at the IDX Developer Summit. IDX serves the real estate industry, providing real estate professionals access to hundreds of multiple listing services (MLS) groups, from around the United States. If you are a real estate broker or agent, and you need real estate listings on your site, IDX is how you do this--they are leading player in the space. If you aren't familiar with the world of real estate data, it has been long controlled by a network of MLS groups, totaling almost 2000 (I think), spread around the nation. These MLS organizations tightly control their data, deciding exactly who has access to it, and exactly how it can be used, and how it MUST be displayed in print and across the web...

Some Potentially Very Powerful API Orchestration With The Amazon API Gateway

11 September 2015
I sat down for a second, more in-depth look at the Amazon API Gateway. When it first released I took a stroll through the interface, and documentation, but this time, I got my hands dirty playing with the moving parts, and considering how the solution fits into the overall API deployment picture. API Design ToolsAs soon as you land on the Amazon API Gateway dashboard page, you can get to work adding APIs by defining endpoints, crafting specific methods (paths), the crafting the details of your HTTP resources (verbs), and round off your resources with parameters, headers, and underlying data models. You can even map the custom sub-domain of your choosing to your Amazon API Gateway generated API, giving it exactly the base URL you need...

When Are We Going To Get A Save As JSON In Our Spreadsheets?

08 September 2015
My last rant of the evening, I promise. Then I will shut up and move back to actual work instead of telling stories. I'm working on my Adopta.Agency project, processing a pretty robust spreadsheet of Department of Veterans Affairs expenditures by state. As I'm working to convert yet another spreadsheet to CSV, and then to JSON, and publish to Github, I can't help but think, "where is the save as JSON" in Microsoft or Google Spreadsheets? I can easily write scripts to help me do this, but I'm trying to keep the process as close to what the average person, who will be adopting a government agency data set, will experience. I could build a tool that they could also use, but I really want to keep the tools required for the work as minimal as possible...

Cultivating the Next Generation of API Design Skills

08 September 2015
There was a pretty interesting conversation around API design going on in one of my API slack channels over the last couple days, about what is API design, and what is needed to get developers, and even non-developers more aware of the best practices that exist. It is a private group, so I won't broadcast it as part of this post, but I did want to extract a narrative from it, and help me set a bar for other API design discussions I am having.  The Restafarian, hypermedia, and linked data folk have long been frustrated by the adoption of sensible API design practices across the sector, and the lack of basic HTTP literacy among developers, and non-developers is at dangerously high levels...

You Have 24 Hours Left To Submit Your Talk For APIStrat Austin

08 September 2015
There is a little more than 24 hours left for you to submit your talk for APIStrat in Austin, TX, this November 18th, 19th, and 20th. With this sixth edition of APIStrat, we are taking things back to our roots, and not choosing a theme, but making it a conversation about the most important topics in the space facing API providers and consumers in 2015.  From looking at the talks that have been submitted so far, API definitions, design, and Internet of Things seems to be leading the pack. We've also seen a couple session talk submissions that we think are probably more worthy of being keynotes, because they are just that good. The APIStrat team feels like 400 people is the sweet spot when it comes to having a productive API discussion, so we chose a venue that fits this vision, which will most definitely sell out...

Catching My Breath On My API Monetization Ramblings Before I Enter Into Some New Conversations

08 September 2015
I have two more conversations kicking off on the topic of API monetization, so I just needed to take a moment to gather up the last wave of posts on the subject, catch my breath, and refresh my overall thoughts in the area. What I really like about this latest wave, is that they are about providing much needed funding for some potentially very important API driven resources. Another thing is that they are pretty complicated, unproven approaches to monetizing APIs--breaking ground!! Over the last couple weeks, I have be engaged in four specific conversations that have shifted my gaze to the area of API monetization: Audiosear.ch - Talking with the PopupArchive team about making money around podcast search APIs...

State of Popular Database Platforms And Their Native API Publishing Features

08 September 2015
I had a reinder on my task list to check-in on where some of the common database platforms were when it came to APIs. I think it was a Postgres announcement from a while back that put the thought in my notebook, but as an old database guys I tend to check-in regularly on the platforms I have worked most with. The point of this check-in, is to see how far along each of the database platforms are when it comes to easy API deployment, directly from tables. The three relational database platforms I'm most familiar with are: SQL Server - The platform has APIs to manage, and you deploy an OData service, as well as put .NET to work, but nothing really straightward, that would allow any developer to quickly expose simple RESTful API...

Algorithmic Transparency With Containers and APIs

07 September 2015
I believe in the ability of APIs to pull back the curtain of the great OZ, that we call IT. The average business and individual technology consumer has long been asked to just believe in the magic behind the tech we use, putting the control into the hands of those who are in the know. This is something that has begun to thaw, with the introduction of the Internet, and the usage of web APIs to drive applications of all shapes and sizes.  It isn't just that we are poking little holes into the corporate and government firewall, to drive the next generation of applications, it is also that a handful of API pioneers like Amazon, Flickr, Twitter, Twilio, and others saw the potential of making these exposed resources available to any developers...

Expanding On My API Monetization Strategy And Research

05 September 2015
This is a full walk-through of me trying to distill down my approach to API monetization, in a way that can be applied across not just 30 APIs, but potentially 300, or 3000. There are several things converging for me right now, which includes the maturing of my own infrastructure, as well as conversations I'm having with startups, enterprise groups, federal government agencies, and my own partner(s). I need to keep hammering on this to help me operate my own infrastructure, but I am also partnering with APIWare to help me deliver on much of the API design, deployment, and management, so I need to have a good handle on my costs. As with all of my areas of research, within the area of API monetization I am just trying to get a handle on the common building blocks, and provide a checklist of considerations to be employed when I'm planning and operating my API infrastructure...

A Blockchain To Act As A Universal API Credit Layer That Can Be Used By Both API Provider And Consumer

05 September 2015
I have had this discussion several times now, in the dark corners of bars in San Francisco, Paris, Berlin, and Barcelona. It is something I just want to make sure is published on my site, as part of my latest expansion of my API monetization research. I'm rolling out a standardized credit system as part of my API operations, and using my API service composition layer to apply credit usage as part of each API call.  My objective is to make it easy as possible to buy and even sell credits via my platform, and easily apply those credits across any API I publish, in a variety of access tiers. As I think through this, I can't help but start thinking about how this can play out on a larger scale...

Learn From Google Maps API And Just Have Standard Approach To Free And Paid Tiers For Your API From The Beginning

03 September 2015
It has been almost 10 years since Google launched the Maps API. With as many APIs as Google have, you'd think they'd have a better handle on a standard approach to pricing across all of them. As we've seen with Google Translate, they have struggled with the right way of pricing APIs, as well as communicating this to their developer ecosystem. This week Google took further steps on the road to standardizing how you pay for Google Maps API, opening up pay as you go purchasing via the Google Developer Console. Here is how they put it: In this new purchasing structure, the Google Maps Geocoding, Directions, Distance Matrix, Roads, Geolocation, Elevation, and Time Zone APIs remain free of charge for the first 2,500 requests per day, and developers may now simply pay $0...

Dwolla Just Released A White Label Version Of Their API -- Are You Ready For The Wholesale API Economy?

03 September 2015
If you have heard any of my talks at API Days Sydney, in Barcelona, or at Gluecon in Colorado this year, you've heard me talk about wholesale APIs, and how I am using Docker to help make some of my APIs available for use as private or white label APIs. The concept of a white label, private label, or wholesale API is something I've been talking about for a while, and is something I am starting to see more of in the wild. The most recent sighting is from payment API provider Dwolla, with four new API endpoints that deliver a white label ACH payout API solution. According to the announcement from Dwolla, the white label API solution will: "..leverage Dwolla’s existing infrastructure—our fraud analysis, bank partnerships, real-time fraud analysis, communication protocols and more—while maintaining your brand’s look, feel, and name on end-user interactions...

The Two Platforms That Will Bring APIs To The Masses

02 September 2015
I'm always on the hunt for API driven solutions that will help the average business user be more exposed to the power of APIs. It is common for us technologists to kick up dust, and get all excited about what we build, when in reality, it doesn't mean anything to the average person in the real world--after 25 years in business, I still do this regularly.  This is why, having a constant reminder to look for solutions that bridge the technical world of APIs, to the average business users world, helps me break free from my own biased approach. When I lean back in my chair, and think about what solutions are currently available in the space, that have this potential, these are the two companies...

API Monitoring Is Often About The Little Details

01 September 2015
As I make my way across my research projects, I'm learning more about how companies like Metacert can deliver valuable security services to API providers. I'm also getting a better idea of the nuance that goes into monitoring APIs, from API Fortress.  API Fortress has very interesting API monitoring story, derived from the Etsy API. This isn't the API monitoring story you'd think, it isn't about the overall stability of the Etsy API, and whether its up or down, it is about the details of API payloads, and inconsistencies they found scanning the API. Through a payload toast of the Etsy API, the API Fortress team found an occurrence of NULL values in 3,600 out of 50,100 items scanned--which negatively affected what results that were actually accessible via the API vs the Etsy interface...

Breaking Down The Layers of API Security And Considering Link Integrity

01 September 2015
One of the reasons I setup individual research projects, is to provide me with a structure for better defining each aspect of the API world, something I am working hard to jump-start within my API security research. You will notice the project does not have any building blocks defined, which when you compare with one of my oldest research areas, you start to see what I mean. The blog posts, and other links I curate as part of my API security will help me find companies and tools that are providing value to the space. As I break down each company, and what they offer, I often have to read between the lines, in trying to understand how an API, service, or tool can be used by API providers, as well as potentially API consumers...

Please Do Not Hide Your API Definitions From Consumers

31 August 2015
I am always pleased to see API providers publishing Swagger definitions, and using them to drive their interactive documentation. Projects like the Global Change Information System API, are getting on the API definition bandwagon, and this is a good thing. I have been pushing API definition formats like Swagger and API Blueprint since 2012, but in 2015, while I want to keep on-boarding folks to the concept of using API definitions for interactive documentation, but I also want them to also understand that their APIs definition will be used in other areas of API operations as well. Most people think Swagger is the documentation, and have not been able able to separate the specification from the interactive documentation...

Are API Keys and Secrets Actually Very Secure?

31 August 2015
When it comes to API security, there are a number of things to consider, something I will be be working to define, and share as part of my ongoing research. However there are three building blocks that are front and center in most security conversations--SSL, API keys, and OAuth. SSL is a must-have, and OAuth is fast becoming a must-have when there is personal data involved, but I still encounter numerous misconceptions around the role API keys actually play in security. API key, and its accompanying secret are a common way to secure API access. You require developers to register for an account, create a new application, and they are then given an application key, plus a secret that is passed along with each API call...

A Quick Example Of An API Provider Putting Content Type Negotiation To Work

31 August 2015
While there are numerous examples of APIs that successfully offer more than one option when it comes to the content types their API returns, the concept is missing from the large portion of the APIs I review. When I see good examples of this in the wild, I try to make time to showcase, and share, to help with the HTTP literacy of my readership. One API which is rocking several fronts when it comes to API design for me, is the Global Change Information System, which interestingly is an alliance between government agencies, not something born out of Silicon Valley. When requesting resources from the GCIS API, the following HTTP accept headers are honored: application/json application/x-turtle text/turtle application/n-triples text/n3 text/rdf-n3 application/ld-json application/rdf+xml application/rdf+json When integrating with the GCIS API, it all begins with some basic JSON, but then look at all the other linked data goodness in there! JSON-LD, RDF, Turtle!! Discovering APIs that support robust content type negotiation like this can be hard to find, most APIs don't talk about it, so even if they do, there is no way to know about it...

Keeping an Eye on the Open Banking API Movement in the UK

29 August 2015
Late in 2014, the HM Treasury and Cabinet Office in the United Kingdom, published Data Sharing and Open Data for Banks, "to explore how competition and consumer outcomes in UK banking could be affected by banks, giving customers the ability to share their transaction data with third parties using external Application Programming Interfaces (APIs)." Very similar to the Obama open data mandate in May of 2012,  I saw a lot of discussion shortly after the release of the document from the HM Treasury, but not many details on how things are going so far. There was a response to the document published back in March, which holds some interesting perspective, but not much else from the government, or banks, that I can find...

An API Monetization Framework To Help Me Standardize Pricing For The APIs I Bring Online

29 August 2015
I'm almost to the point with my API stack, where I can start plugging in new APIs I have planned. Up until now, the APIs i have deployed, are of little use to a wider commercial audience. However some of the APIs I have planned for the next year, I'm looking to monetize their usage, and operate as part of a larger commercially viable API stack. (practice what I preach baby!) To run this stack, I need a plug and play way to define what an API is costing me, and potentially how much revenue I am generating from each API. With this in mind, here is my draft look at an API monetization framework, that I am employing across my API Stack.  Acquisition (One Time or Recurring) Discover - What did I spent to find this...

Influencing Important Work Like the UK Open Banking API Standard Is Why I Do This

29 August 2015
I enjoy what I do, but when I embarked on my API Evangelist journey in 2010, I set myself on a mission to educate people about the business of APIs, and highlight that it isn't just the technology that makes APIs a thing. I have worked hard to distill down what it takes to execute an effective API management strategy into usable advice that anyone can run with when crafting an API strategy. As I conduct my monitoring of the API space, It makes me feel accomplished, when I find my work cited, influencing important API related projects. This just occurred to me as I was taking a fresh look at the Data Sharing and Open Data for Banks, published by the HM Treasury and Cabinet Office in the United Kingdom...

The Benefits and Risks of an Open API Standard

29 August 2015
I'm immersing myself in the Data Sharing and Open Data for Banks, published by the HM Treasury and Cabinet Office in the United Kingdom, "to explore how competition and consumer outcomes in UK banking could be affected by banks, giving customers the ability to share their transaction data with third parties using external Application Programming Interfaces (APIs)." While I do not think an open API standard will ride into town like a white knight, saving England from all its banking problems, I do think there is a lot of good that will come from this effort. The banks have a lot of technical debt, corruption, and many other issues to deal with before APIs will even work, but I think there is enough pressure on them right now from consumers, and startups, that they will have to change at some point--or die...

The API Design Guide Is Just The Beginning Of The Journey - Better Get Started!

28 August 2015
I'm processing all of my thoughts from some travel to the big city of San Francisco. I was providing feedback on Microsoft's API design guide, as part of the OneAPI Technical Advisory Group. As I was thinking about the journey Microsoft is on, the role of the API design guide, and how many other companies like Paypal, and Cisco, are on the same journey.  In parallel to this, I am on my own journey with my own API stack, I've been looking at everything from a slightly different perspective than many other analysts and providers in the space. When I started in 2010, it was all about API management, then after folks kept asking me about options for deploying APIs I expanded my monitoring to API deployment...

We Need an Open Abstraction Layer to Help Us Better Define and Design Our APIs

28 August 2015
I walked around San Francisco with Jakub Nesetril (@jakubnesetril), the CEO of Apiary, Wednesday evening, talking about the API space. Eventually we sat down in Union Square, continuing our conversation, which is something I wanted to further process, and blend with some existing thoughts I'm working through. Much of our conversation centered around the need for an open abstraction layer for API design, which would reduce the focus on Swagger vs. API Blueprint vs. WADL vs. RAML vs. any other API definition, and make it just about defining and designing our APIs. Jakub is right, I'm sure he'd love everyone to use API Blueprint (which thousands are), but it is more important to him that people just use API definitions, and commit to a healthy API design strategy...

Thinking Beyond Just Language Specific Clients and Also Speaking the Formats Popular HTTP Clients Are Using

28 August 2015
I was given an introduction to the Microsoft Graph A concept being applied to Office 365 APIs, other Microsoft APIs, and potentially beyond, to map out segments of users and every day objects. As I learn more about this unifying, graph API effort, I will write more, but this particular story is about how we communicate around the first steps taken by developers when integrating with any API. As an API provider, how you talk about integration, and craft your on-boarding resources, can significantly impact how developers view your resources, something that I think still will always need some work across the space. After being introduced to the Microsoft Graph APIs, we were given a list of code resources, that we could use to hack against the API...

Crafting and Publishing API Design Guide Shows That You Are Further Along In Your API Journey

28 August 2015
I spent all day Wednesday, at Microsoft offices in San Francisco, providing feedback on the Microsoft API design guide, as part of the OneAPI Technical Advisory Group. The OneAPI team had already done most of the hard work in hammering out the API design guide, by working with the API leadership from groups across Microsoft--we were just brought in to provide outside perspectives. A group of about 20 of us, spent the entire day walk through the high levels of the Microsoft API Design philosophy. The Microsoft OneAPI design guide is a draft, so they aren't ready for us to share it publicly, something we'll see in the near future. However, document being ready or not, the process showed me that Microsoft is really working hard to get their API design strategy house in order...

Making Sure The APIs Being Served Up Via Your Enterprise Service Bus (ESB) Are Discoverable and Consumable Using APIs.json and Swagger

25 August 2015
Making sure APIs that are available via the enterprise service bus, affectionately known as an ESB, more discoverable, accessible, and consumable via the open Internet, is one of the many challenges organizations will face along their API journey. Striking a balance between internal APIs, and public APIs, even if they aren’t open to the wider public, and only partners, is proving to be a big challenge for many enterprise groups I am engaged in conversations with. When Steve Willmott (@njyx) and I developed APIs.json, an open API discovery format, we were focused on bringing solutions to the table that were focused on API discovery on the open Internet. We knew that the format could also assist in more controlled environments, like within the enterprise, but wanted to focus on the wider discussion first...

Further Defining the AngelList API as Part of My API Stack

25 August 2015
I am slowly making my way through defining of the APIs available in the API Stack, beginning with the APIs that I depend on to operate API Evangelist. The best way to understand any API in my opinion, is to create a Swagger definition for it, as well as an APIs.json file, indexing the overall API operations. Since my mission is all about understanding APIs, this is something I try to do on a regular basis. Creating an APIs.json file allows me to index each APIs operations from registration and documentation, to pricing and terms of service. Then I work to break down every possible unit of value represented by an API's endpoints, reducing it down to the minimum viable element possible--something that Swagger allows me to do nicely...

Setting a Precedent When Charging for High Volume Access to Government APIs

24 August 2015
I'm neck deep in discussions around API monetization lately, from building a business model in the fast growing podcast space with AudioSear.ch, funding scientific research through API driven revenue, and the latest being a continuing conversation around how to monetize high volume usage around the Recreational Information Database (RIDB).  I have been pulled into the conversation around the API for our National Park system information several times now. In October of 2014 I asked for Help To Make Sure The Dept. of Agriculture Leads With APIs In Their Parks and Recreation RFP, something I saw some Next Steps For The The Recreation Information Database (RIDB) API this January...

Easy Way to Inspect HTTP(S) API Traffic in a Multi-platform, Multi-device Environment

24 August 2015
This is a deep dive from one of my loyal readers, who doesn't just listen to what I write, he is pushing my own research in new directions, and reporting back to me. You have read his work before in API Police Report: Raw Thoughts From On-Boarding With Your API, and this time Bob Salita is building on my own proxy work with Charles Proxy. Guest posts isn't something I do on API Evangelist, but when you are pushing the conversation forward like Bob does, I can't help but share. I'm a multi-platform, multi-device developer. I wanted an easy way to inspect HTTP(S) API traffic (requests, responses) from one of my many development devices. Inspection can be achieved by using (reverse) proxy software such as Charles, Fiddler, squid, or mitmproxy...

What We Can Do To Make A Difference In The Wake Of Oracle v Google API Copyright Case

22 August 2015
While we wait for the next steps of the long drawn out Oracle v Google Java API copyright battle, I wanted to take some time and talk about what we can all be doing to actually make a difference. If you aren't familiar with the legal case, is a legal dispute related to Oracle's copyright and patent claims on Google's Android operating system. The court case started in California courts in 2012, with the rmost recent verdict coming in May, 2014, where the Federal Circuit partially reversed the district court ruling, ruling in Oracle's favor on the copyright-ability issue, and remanding the issue of fair use to the district court.  While we wait for appeals, endure the continued discussion, and read the trickle of FUD that comes out from the tech press, what can the tech community actually do to make a difference? First, we can reduce our anxiety about this being hellfire and brimstone for the current web API movement...

Building Everything You Need For A Global Nervous System Using The Twitter API

22 August 2015
This is one of several stories I am evolving as part of series I'm calling API fairy tales. With these tales I want to educate business leaders, technologists, and government about the importance of Application Programming Interfaces (API), and how they are being applied in almost every aspect of business occurring online today--providing simple examples that mainstream users can learn from, as well as retell in their circles. Just two months after launching there new messaging startup in 2006, Twitter introduced the Twitter API to the world. Twitter's API release was in response to the growing usage of Twitter by those scraping the site or creating rogue APIs, so Twitter exposed the Twitter API, returning machine readable JSON and XML that developers could put to use, building things beyond what Twitter could build...

Can We Keep Important Scientific Research Projects Alive Through Revenue Generated From API Access?

15 August 2015
I am spending an increasing amount of time thinking about how you monetize data, content, and other digital resources via APIs. A couple of very compelling layers to all of this work, is pushing forward my thoughts on how and when government should charge for access to public data, as well as the how and when private sector companies should charge for access to public data--lots to think about here. Another layer to this conversation that was introduced this week, centers around how we can keep data and content generated via publicly funded research, at publicly funded institutions, available, accessible, and moving forward, by applying the technology and business of the modern web API. I was contacted this week by a group at Caltech, that is proposing a research to database hyperlinking project, which would provide one-click access from published biomedical research papers to authoritative biological databases such as WormBase (WB; wormbase...

Modern API Service Providers Need To Speak Common API Definition Formats

14 August 2015
I play with a lot of services that target the API space each week, during my regular monitoring of the space. These are services from all along the API lifecycle that service this space, from design to integration, that target both API provider and API consumer. After I on-board with a service, there is one trend I see emerging that really puts service providers into two distinct buckets.  The API focused services that stand out the most, are the ones that employ common API definition formats like Swagger, and API Blueprint. After I've on-boarded with a service, if I can upload a machine readable definition of one or many of my own own, or public APIs I depend on, the quicker I will see a service in action--well on my way to understanding the value generated by a service provider, and becoming a customer...

A Common, Open Source API Design Editor Is Needed For API Service Providers

13 August 2015
I love the API design editors that have emerged from Restlet as part of their design studio, and from APIMATIC as part of their SDK management service, and if you haven't checked out Gelato.io, I highly recommend it. All of these solutions provide me with a well designed user interface for working with common API definitions, but even with these offerings, I feel like the overall API universe is very deficient in this area. It is good that these providers are using common API definitions like Swagger and API Blueprint, but the UI itself is a one-off, and for API definitions to take their place, front-and-center throughout the API lifecycle, we are going to need some common API design tooling...

One Approach To Consider When Crafting Your Pricing As An API Service Provider

13 August 2015
One of the areas I focus on in the API space, is the business of APIs, and how companies actually make the rubber meet the road when it comes to pricing the API resources they are serving up, as well as the price that API service providers offer up to their customers. After security, monetization is the top question I get from the folks i am talking to about their API strategy. I've been watching the SDK service provider APIMATIC move from a company in beta, to announcing pricing for the valuable API service this last week. I love watching any company break up their valuable resources and services, but feel APIMATICs pricing announcement is interesting enough to warrant a story, because it provides other API service providers with one possible blueprint they can use...

What API Means To Me

12 August 2015
I love the wide swinging perception people have of who I am, often based upon a 15 seconds of sizing me up, reading the title, first and ending paragraph of a blog post, and often seeing this photo. I'm also humbled by the people who tell me the stories of who they thought I was, before they got to know me, and how that dramatically shifted once they met me. People think I'm all sorts of crazy things, without ever actually having a conversation with me. To help clear the smoke, I figured I'd hlelp answer a few of the common perceptions people throw at me, that in my head I feel people should know, but regularly I am reminded that based upon my site name, branding, etc, people have no clue: APIs Are Good - No, no, sorry they aren't by default...

API Usability Course at Carnegie Mellon

11 August 2015
I am accumulating more references to API goodness from across Universities, as part of my APIs in higher education research. The more I monitor, the more I find, this is how the API monitoring game works. Unfortunately there is no silver bullet for finding APIs, and related resources, it takes going out and finding it--while also having an eye for what to look for. One thing I found recently was an API usability course from Carnegie Mellon. The material is a little bit dated, not reflecting API design used in modern efforts, but it is still good to see something like this as part of university curriculum. There are also some good references there, I will be borrowing from.  In addition to seeing more standardized blueprints emerge regarding how campus IT should approach their API efforts, I'd like to see more standardized curriculum emerge that teachers can use in the classroom...

HDScores: One Potential API Driven Business Model Aggregating Public Data

11 August 2015
I came across HDScores a couple of weeks agao, but their API wasn't quite ready, something they officially released this last week. HDScores is interesting to me for a couple of reasons. It is an API that aggregates open government data, but also has what I'd consider a potentially viable API business model as well.  The monetization of government data using APIs is something I've been discussing for a while, exploring whether our government should subsidize and profit from open data, and helping agencies develop a better understanding of their open data and API consumers before they charge for anything. HDScores takes this to the next level for me, presenting some possible models we can all follow when developing viable business on top of open data...

The Continuing Evolution of The API Gateway

11 August 2015
I'm feeling like the recent release of the AWS API Gateway isn't just an isolated product release, but more of a signpost in the overall evolution of the API space. It is quite possible that Amazon's moves, set much of this into motion, but I am seeing a number of new API gateway solutions, as well as engaging in more API gateway conversations as part of my regular monitoring and discussions. Amazons API Gateway release has left me pretty underwhelmed, but I still have a lot of exploration to do, which includes employing the gateway alongside Lambda--so I may be changing my tune. When I said AWS launched exactly the API deployment solution the enterprise wanted, not what they need, I'm not necessarily saying it was a stupid move for AWS, my criticism is more about just about making money off the enterprise over providing what they actually need to evolve...

Submit Your Ideas For Talks At APIStrat Austin This November

11 August 2015
We are picking up momentum on our way to the APIStrat conference this November 18-20th in Austin, TX. The call for papers is now open, and we are looking to hear your ideas for what the session discussions should be. APIStrat is all about discussing the most pressing topics in the space, while also revisiting some of the cornerstone's of API operations, for those just entering the space. If you aren't familiar with the tone of the conversation APIStrat, we are looking for a diverse range of speakers, from many different industries, to share their API stories, avoiding the usual product or company pitches. We want you to focus on the honest stories from your own API experience, in a way that the 400 attendees can take home to apply in their own operations...

Taking Another Look At Where We Are At With Data.json Files For Federal Agencies

05 August 2015
I am spending some time, refreshing my look at the open data work, specifically the results of OMB Memorandum M-13-13, which required federal government agencies to publish a data.json file, providing a machine readable inventory of an agencies public data resources. I recently received a Knight Foundation Grant to build a prototype, explore one possible "whats next", for open data in the federal government--allowing me to push this valuable work forward. To refresh my memory, I pulled from 87 federal agencies I am tracking on as part of my regular API monitoring--raising the bar from 22 federal agencies having published their data.json file, to 27 who have published their data.json file...

How Do We Handle That Trailing Slash In Our API Endpoints?

04 August 2015
I am participating in several API focused Slack channels these days, which opens up entirely new channels for conversations across the API community. I think the private channel(s) gives people a safe place to talk about the challenges they face, but there are also some very educational conversations that occur, that should also be shared publicly.  One of these conversations from yesterday was focused on how we handle the trailing slash in our endpoints, a conversation started by Nicolas Grenié (@picsoung), @3scale hacker in residence, who asked about: myapi.com/authors/ vs myapi.com/authors myapi.com/authors/1/ vs myapi.com/authors/1 Something which Guillaume Laforge (@glaforge) of @Restlet said, "technically speaking, they are different resources… but practically speaking I think an API should accept both to do the obvious thing"...

When Planning Your API Portal Do Not Hide APIs and Always Translate From IT To Something Humans Can Understand

03 August 2015
While updating my APIs in higher education research this last week I came across an API portal I think tells an important story about an evolution in how we develop and maintain software. The current wave of web APIs that I cover has been working well because it has exposed a number of valuable resources, that once upon a time were only available in the realm of IT, making these resources accessible to a wider audience of developers, or even business users.  This evolution has been slowly pulling back the curtain of IT, exposing more of it's inner workings, potentially simplifying, and decoupling valuable digital resources from legacy power structures. An important piece of this transformation is the translation of IT speak to language that the average human can understand, something that is playing out within API developer portals across companies, organizations, institutions, and government agencies...

API Service Providers Need To Decouple The Services They Offer To API Providers

03 August 2015
As I work with each generation of API service providers, I always notice a portion of them that are born out of a previous era of software development from the 1990s, and even sometimes the early 2000s, This reminder frequently brings up the point of how these companies need to follow the same advice they (we) offer to their own customers--decouple your resources, into small API driven services. I regularly stumble upon companies who asks me to review software services that are targeting API providers, that don't reflect an API-first approach. My advice to these companies is always to step back, take a deep breath, and consider how you can embark on the same journey that the companies you are targeting have already begun traveling...

API Rate Limits Are Making Me Think More About How I Design My APIs, and How I Consume Them

03 August 2015
As I migrate the version 1.0 of my internal systems to an API-first version 2.0, one of the challenges I face is the optimization of some of the features in my own system. I have numerous systems I crafted to solve a specific need, at a specific point in time, with very little consideration about the most efficient design.  About 50% of my version 1.0 systems employed APIs, many systems relied on directly connecting to my MySQL databases. One example of this is my main news curation screen on my dashboard. This was the replacement for Google Reader about 6 months before they killed it off. My reader system is very chatty, every action I take against a single post (archive, curate, tag, etc...

Adding A Credit Layer To My Existing API Service Composition

02 August 2015
I am revisiting the service composition for my own APIs on a regular basis lately, along with the ever increasing number of conversations I'm having with API providers about their own API monetization strategy. An example of this can be seen with the conversation I had  with the Popup Archive about their monetization strategy for their AudioSear.ch API, and how they are shifting from a resource based perspective to a more experience based monetization approach. One side effect of this conversation, is that it looped me back around to thinking about the next steps for my own system. I currently have 28 APIs, with almost 400 endpoints, most of which are content and data style APIs. This represents the core of the API Evangelist network, and now that I have it well defined as a single set of decoupled APIs, it is allowing me to move forward with a whole new generation of APIs...

API Evangelist and APIWare Partnering To Help You Do The Hard Work Of Developing and Managing Your API

31 July 2015
I am fortunate to be able to take part in numerous conversations around API strategy, with companies, organizations, and government agencies who are trying to understand, and maximize the role they play in the API economy. However, one side effect of this world, is that most of these conversations begin and end with strategy planning, and when it comes to deployment and management, I rarely stay on in discussions. I do have clients who do check in with me, at different stops along their journey, but for the most part my role ends once the strategy discussions end. I would like to change this with a new relationship I've established with APIWare, a new API-first agency that is dedicated to defining, developing, deploying, and managing APIs at all stages of the life-cycle...

The Potential When You Are Able To Spawn Virtualized Environments For Your API

30 July 2015
I was made aware of the Citi Mobile Challenge during a conversation last week with the Anypresence team about their new JustAPIs offering. The conversation with them has triggered several potential stories, but one that stood out for me, was the API virtualization opportunities that emerge when you use solutions like the JustAPIs gateway.  To support the Citi Mobile Challenge, the bank launched a set of virtual APIs to support the event. I think their descriptions tells a lot of the story: The APIs made available through Citi® Mobile Challenge power some of Citi's latest digital offerings around the globe. These APIs will give developers an opportunity to create solutions that could function with existing Citi technology...

Providing A Web Scraping Toolkit On Github To Jumpstart The API Conversation At The University of Toronto

30 July 2015
I found a pretty cool Github repository during my latest review of my university API research, with a mission "to provide a collection of RESTful web APIs that can allow developers to create applications or services that utilize public data from the University of Toronto." I am a big fan of jump-starting API efforts on campus in this way, something I did to help fuel the API discussion at University of Oklahoma. Which is a topic I will be talking more about in the near future as these conversations continue play out. In my opinion, many campuses are just not ready for APIs, and to get things rolling, it will may often take outside influences. This API project I found, that is dedicated to the University of Toronto is interesting because they identify three target APIs that are being worked on...

Is Your Monetization Rooted In The Resource Or Experience Side Of Your API Operations?

30 July 2015
I had another one of my regular check-ins with Anne and Bailey over at Popup Archive today, with a focus around the monetization strategy for their AudioSear.ch API. I thoroughly enjoy my conversations with the team, because they have worked really hard on their audio API solutions, and are extremely open to discussion, and sharing the stories of their API journey. During our talk, they tuned me into where they were at with their road-map, which includes now having a solid set of API resources that provide access to the episodes, people, and shows involved in podcasts across the Internet. They talked about how they have been iterating on these core API resources, with more experience focused endpoints including relatedness, trending, and tastes, to name a few...

Going Beyond Just Data APIs With Code Endpoints At Apitite

30 July 2015
in my time as API Evangelist I've seen a number of API deployment as a service providers come and go. It is something that is technically hard to do properly, and something that historically had been hard to monetize, but as a wider awareness around APIs grows in the mainstream, the demand landscape for API deployment is shifting. I got a demo of an API provider today called apitite, which provides API deployment and management services in the cloud. The core of the service is built around the common need to deploy APIs from datasources like MySQL, SQL Server, etc. However I wanted to highlight another feature of their platform which they call code endpoints. When I help folks understand what is possible with APIs, I break into four main groups: Data - APIs are about making data more accessible, and usable...

Updating My Research To Include 48 Universities With Publicly Available API Efforts

29 July 2015
I'm slowly working through all my research areas, updating the news items I've curated, adding and removing companies, continuing to identify some of the common building blocks, and the tools that are being put to work in the space--with the latest one in the area of higher education, with my university APIs research. With my latest look at APIs in universities, I increased the number of institutions I'm watching from 17 to 48, more than doubling the number of API efforts in higher education from 2014 to 2015. Not all the APIs I found are fully listed, but if I found a valid public API effort under a school domain, I have added the school, and will work to profile more in the future, as I have time...

Asking The Right Questions Of API Operations

29 July 2015
I ask a lot of questions about the API space. In m quest to make sense of the growing number of APIs in the space, I partnered with 3Scale to define the APIs.json format. In the year since we launched, I've used it to help me define almost 1000 companies that I keep an eye on in the space.  To be able to understand APIs at scale, I had to develop a way to ask questions about a companies API operations, while also asking them of my own APIs. This project was born out of some research into making API terms of service (TOS) machine readable, which led me to the project Terms of Service Didn't Read--a very important project you should know about. Long story short, I realized how much work it would be to make APIs TOS machine readable, and distilled things down to just be able to ask simple questions about APIs like: Is there self-service registration? Can I delete my account? Do I own my data? I then quickly realized the potential for my api-questions format, and that it could help me avoid getting tangle up in the legaleze of API TOS, and speed up making sense of how APIs work...

My New API For Asking Questions Of APIs - The APIs.json Edition

29 July 2015
I am currently trying to move forward the 917 companies, from 223 business areas, with a total 882 APIs catalogued, and 407 Swagger definitions created, while working on a distributed way to understand where the profiling for each company is, and how far in defining this in a machine readable way. I had kicked off another prototype APIs.json type a few months back I'm calling api-questions to handle just this, in a way that allows me to ask human readable questions about APis, while also storing in a distributed, machine readable format that can be indexed via each APIs.json file. I have long tracked on what public APIs are doing in a database. I keep links to Github and Twitter profiles, blogs to pricing, and terms of service...

Politics Of The API Economy

27 July 2015
I did a napkin doodle the other day at my favorite local hangout during lunch and beers. I was thinking about the finer points of the API economy that I dwell on, and feel are important not just for API success, but also developer, end-user, and industry level health. In this doodle, I'm trying to think about where I need to focus my energy when working to keep the API pipes as transparent and open as possible. For me, this isn't just an API story, this is a story about the evolution fo the web, and ultimately a story of the journey humans are on, when it comes to defining our virtual self, that participates in the online domains that capture our attention on a daily basis. I wanted to better understand how companies are moving digital assets online, generating new resources, which are often times user-generated resources, empowered by developers...

Augmenting Data Sources and APIs with POST, PUT, and DELETE Using Restlet APISpark

26 July 2015
Most of the APIs you find out there are read only, meaning they act like a website and just allow you to retrieve data, content, and other media types, but usually do not let you read or write any data to them. I wrote a while back about augmenting a read only API with an external POST, PUT, and DELETE as I came out of the government, but wanted to update the topic, based upon some open data work I'm doing with RESTlet API Spark. I am preparing for my Restlet Summer of APIs webinar tomorrow morning, so I am publishing some open data files (CSV, Excel, etc.) to the platform, generating data stores, and ultimately APIs. A simple example of this in action would be with farmers market data from the US Department of Agriculture...

Taking A Look At Whats Next For The Environmental Protection Agency (EPA) Envirofacts Data Service API

25 July 2015
I was asked by folks at the Environmental Protection Agency (EPA) to provide some feedback on the Envirofacts Data Service API, as they prepare to work on the next iteration. I took a quick glance at the landing page for their service, I saw a simple URL layout showing how to make API calls, and made an estimate that it would take me probably an hour or two (at the most) to profile the API. As I dug into the process of profiling the Envirofacts Data Service API one evening in May, I realized I was wrong about the scope of the API, and became unsure how long it would actually take me. Then this work got lost in the shuffle of my summer, and is something I only recently picked up. I'm not happy if I can't provide an agency with some direction on where to go next, and after about 12 hours of work, I think I have some valuable feedback that they can run with...

Pushing My API Gateway Thoughts Forward: API Gateway Anywhere With JustAPIs

23 July 2015
I open up my Thursdays to briefings, calls, demos and other phone, skype, and hangout related activities. This morning I received a walk-through of the JustAPIs platform from AnyPresence, taking my thoughts in a much different direction than in my conversation with Wavemaker, which was at the intersection of API design and API gateway in this new cloud-based, single page application design studio.  JustAPIs is a downloadable, installable, portable, little API design, deployment, and management engine, which you can install on Linux, Windows, Mac, and even your Raspberry Pi. This represent the functionality I have in mind, when I think about the future of what is an API gateway--a little node that can put ANYWHERE to serve up, proxy, and manage my APis...

Setting rel=api Into Motion With Latest APIs.json Release

23 July 2015
Bruno Pedro (@bpedro) who has been building APIs.json into his API Changelog service, made a pull request to the specification recently, pushing forward the link relation conversation for APIs.json. As listed in the specification, we have long intended to make APIs.json an official media type: 3.5.  Media Type It is intended that if there is sufficient traction, the media type "application/apis+json" will be   submitted to IANA as per RFC: http://tools.ietf.org/html/rfc4288 However when it came to expressing your APIs.json as a link relation, we didn't even really have a plan in our road-map, resulting in a very generic allocation of a link relation for APIs.json. 3.8. Link Relation  In order for an API to reference its own description, it is recommended that it include header or in-line references to the APIs...

The Window To The API Economy For Everybody Else

23 July 2015
API Evangelist has always been about helping on-board the masses with concepts involving APIs, something that takes a lot of work, because more often than not, an API is a very abstract concept, far removed from the everyday lives of normal people. When services like Zapier launched, I became very optimistic about how APIs can be put to work by the average individual, and today my optimism went up another notch, with the redesign of Blockspring. The Blockspring home page image says it all in my opinion--valuable API resources, neatly available in Google Sheets, and Excel on the desktop, and in the Cloud with Office 365: This is it! This is the window to the API economy that will be required to take things to the next level...

Pushing My API Gateway Thoughts Forward: API and Single Page App Development with Wavemaker

23 July 2015
I open up my Thursdays to briefings, calls, demos and other phone, skype, and hangout related activities. This morning I received a walk-through of the Wavemaker Online platform, and got a look at the intersection of API design and API gateway in this new cloud-based, single page application design studio.  I bitched a little the other day about the Amazon API Gateway released, talking about how I was underwhelmed, and I also blew some hot air about deploying APIs using a gateway solution vs. what I call farm to table API development, but ultimately I'm just pushing myself to think harder about how we not just deploy our APIs, but keep in alignment with our design, and management processes...

Thoughts On API Gateway Deployment Over Artisan Farm To Table API Design And Deployment

22 July 2015
I was wallowing in the exhaust of my previous story on Amazon API Gateway, and talking with an API development team about their preferred way to launch an API today. Leaving me thinking...what is the better way to design, and deploy an API? Gateway or hand-crafted?  Ok, cut to the chase, its a bullshit question, but for the sake of working through my own anxiety, I'm going to explore. For my audience, I'm going to oversimplify what an API gateway is by stating it is a hardware and / or software appliance you can you use to connect to any existing, internal system like a database, CRM, or other, and then quickly and efficiently design, deploy and manage APIs driven by these resources. Personally I am from the artisan, farm to table guild of API architects--I prefer to hand craft my APIs...

An Example Of Resource Based API Design Over At The Envirofacts Data Service API

22 July 2015
I told a contact of mine at the Environmental Protection Agency I would provide some feedback for the next iteration of the Envirofacts Data Service API, and as I prepare my formal response, there is a huge opportunity for me to carve off some other smaller stories. These stories are what make API Evangelist go around--pulling off these nuggets of learningz, as I'm working with API various providers.  A concept I work hard to help API designers and architect adopt is around experience-based API design over resource based API design. Something I learned from my friend Daniel Jacobson (@daniel_jacobson) at Netflix, but have been taking it in different directions to help designers and architects from smaller API groups, adopt this way of life--I feel like my work today on the Envirofacts Data Service API provide a great opportunity to move this conversation forward...

Using Existing Online Forums vs Developing Your Own To Support API Operations

21 July 2015
As I tune into the fallout around the Reddit community, I think it is a good time to pull a story out of my notebook, that I began writing a month or two ago. These thoughts are born out of my post Ask The Stack When You Need API Support, where my friend Jeremiah Lee (@JeremiahLee) commented, disagreeing with my recommendation that API providers use Stack Exchange as part of operations.  Jeremiah shares his story about how hostile Stack Overflow can be (I'll let you read his comment on your own), something that has been re-enforced many times along the way. While I still endorse Stack Overflow as a valuable building block for some APIs, I completely agree with Jeremiah about the overall community tone...

As The API Design Space Grows, More Companies Are Publishing Their API Design Guides to Github

21 July 2015
I recently went through my API design research, updating and evolving it, to help me better understand changes in the API design space, while also sharing as much of the information as I can with my readers. One of the resources I include under my tools section are the increasing number of API design guides being published.  Currently I'm showcasing the API design guides for 18F in the federal government, Heroku, and PayPal, then the other day my friend Holger Reinhardt (@hlgr360), formerly of CA Technologies, now the CTO at the Haufe Group in Germany, shared his teams API design guidie with me. The executive summary for the guide says it well: Purpose of this style guide is to gather a list of rules, best practices, resources and our way of creating REST APIs in Haufe Group...

Taking API Monetization To The Next Level By Monetizing The Exhaust Around API Consumption

21 July 2015
I have spent a lot of time thinking about API analytics. Understanding who is signing up to access API resources, and how they are putting those API resources to use, is one of the most valuable aspects of modern API management solutions in my opinion. The awareness derived from API operations that use analytics, can have the biggest impact on not just how you run your API, but how you craft your API products, tailor your monetization strategy, evolve your overall roadmap and company. API analytics was the topic of a webinar I conducted with WSO2, one of my partners, this morning. I've been invested in WSO2 since they first contacted me for feedback on their then upcoming release of their open source API management solution...

APIs Are Just The Next Step In The Evolution Of The Web

18 July 2015
My storytelling on API Evangelist has two sides, one is about refining my own understanding of the API space, and the other is about refining, evolving, and helping make the stories I tell make sense to the widest possible audience that I can. I spent the week around a number of folks who had no idea what an API was, they had heard about them, but admitted that they really did not get what they were. Coming out of this experience, I felt the need to take another crack at the most fundamental API question out there--what exactly is an API? APIs are just the next step in the evolution of the World Wide Web (aka WWW), which is virtual space where HTML documents are accessible via URLs on the Internet--which allows humans to browse, and consume (or create) information, data, and media (photos, videos, etc)...

I Depend On All Of You To Help Me Make Sure API Evangelist Is Complete

18 July 2015
All of my public web sites, research projects, API portals, and micro apps run on Github Pages, which means there is always a Github repository behind each website. I'd say 75% of my projects have a publicly available master repo, as well as a publicly available gh-pages repo. This approach to running public infrastructure, i feel does one important thing--it opens up all of my work for community contributions. Beyond just accepting outside contributions, there are many other secondary effects to this way of operation. The first is that anyone can submit blog posts, pages, and any other data or content they desire. The second is that anyone can fix or correct anything you find across my network of sites and apps...

Not Every Successful API Needs Venture Capital

17 July 2015
The story of Pinboard's sixth anniversary came up on my API monitoring this last week, and beside being funny as shit, it reminded me of how successful APIs can be, even when they do not follow traditional funding paths. Let me preface this with the fact I'm not against companies seeking funding, so that the usual suspects do not crawl up my ass. In my opinion, Pinboard is an important API economy story, and something I want make sure API entrpreneurs hear.  First, I am a pinboard API customer. I was one of his early buy-in customers, and it has been a critical aspect of API Evangelist operations ever since. If you read stories on my blog, or read my API.Report, you are seeing the value exhaust generated by Pinboard...

Opportunities For Non-Programmers To Put APIs To Work For Them Is Picking Up Speed This Year

17 July 2015
A core aspect of my mission as the API Evangelist is to help bring awareness amongst "the normals" of what an API is, as just how ubiquitous they are becoming. While I am excited about the potential of APIs in the hands of the developers, I am increasingly optimistic about the potential of APIs in the hands of non-developers. I think what developers have done with APIs is just the tip of the iceberg, when it comes to the API opportunity. What developers do with APIs is just one step forward in the evolution of software development and information technology, where APIs in the hands of the average citizen and business person has the potential to actually democratize digital resources--something you hear API developers and providers trumpet...

The Biggest Obstacle For Hypermedia Adoption Is The Cognitive Load Of The Average API Designer

16 July 2015
Those in the know with hypermedia, often express their frustration when it comes to the overall progress of hypermedia adoption, and the bespoke approaches of many API designers. while there are many hypermedia skeptics who just don't buy into the concept, I think there are many out there who would be willing to to apply common hypermedia patterns in their work, but face many challenges. I'd put myself in between those willing participants, and those in the know. I get the the concepts at play, but I wouldn't say I know what I'm doing. I am working to apply Siren, one of the leading formats, to my curation API. In my work, I do not struggle with a willingness to do it, I struggle with my high cognitive load...

A Universal Me API

12 July 2015
I am pretty demanding today, I just asked for sandbox environments to be default for all APIs, and now I'd like to see a universal /me API. I am profiling AngelList API, as part of my API Stack work, and while AngelList does not have it broke out as its own endpoint on the menu (it is just buried in the oAuth section), I thought it was worth breaking out all by itself. At AngeList, when I hit the api.angel.co/1/me endpoint, it gives me back everything about me on AngelList. To make it work, I have to pass along a valid oAuth token, which I generated from my AngelList account, which is how the API knows who I am. As I was playing with this API, and breaking out as its own Swagger file, as part of my AngelList API profiling, I can't help but want this feature everywhere...

I Wish All APIs Had Sandbox Environment By Default

11 July 2015
I am working through every endpoint of the AngelList API, making sure I make as many successful calls as I can, as I work to generate Swagger definitions for the API, using Charles Proxy. To support this effort I setup each endpoint in Postman, and populate enough detail about an API to make a successful call--which I record through Charles, and then import to generate a semi-complete Swagger spec. Some of the API endpoints requires adding and deleting of information. For example I will add a comment to my profile, then update in, and remove it, all in a series of API calls. Most of the time I can accomplish this without doing much damage to my live profile, but sometimes it requires sending messages to people, initiating processes that trigger other system aspects that I may not be able to undo...

AWS Is Selling The API Solution The Enterprise Will Buy, Not Necessarily The API Solution They Need

10 July 2015
I shared my view on the AWS API Gateway yesterday. I'm all about the AWS kool-aid (oh yeah!), but overall I was left underwhelmed. I feel the release of the API solutions represents a pretty significant milestone along the API highway, but overall I think we should be further on down the road. There is much to celebrate about what AWS is up to. It acknowledges the need to deploy APIs from the common resources we have move into the cloud, and provides us some pretty forward thinking ways of crafting resource-based API that uses Hypertext Application Language (HAL). #WINNING I'm sure AWS chose their wording very carefully when they named the project, but where the AWS API solution falls short for me, is with the concept of a gateway (that this moves us forward)...

The New AWS API (Gateway): Anyone Who Does Not Do This, Will Be Fired. Thank You. Have A Nice Day! - Jeff Bezos

09 July 2015
It has been almost 10 years since Amazon shifted the conversation on the Internetz, with their release of Amazon S3, and Amazon EC2 -- showing us that web APIs were more than just a hobby thing you do in this new social kids game, but that you could actually deploy any digital resource, including storage and compute, at a global scale. As I process the release information about AWS API Gateway today, I can hear the echoes of Jeff Bezos's now mythical mandate:  All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever...

My API Design Research Distilled Down As Single PDF Guide

08 July 2015
When API Evangelist began five years ago it was a single research into the business of APIs, which ultimately became a research project which I called API management. Over the last four years, I have spliced off other areas of research including the elements of my core research into API design, deployment, management, integration, evangelism, and monetization.  My goal with each research project, is to evolve my understanding of each area of the API space by identifying the key companies and organizations involved, the open tooling being developed and put to work, and some of the common building blocks that make up each area. For each of my research projects, you can visit its Github repository to get regular updates, but I find many people seem to prefer browsing a single, portable paper of my research...

Time To Remove Or Rotate Your API Access Keys

07 July 2015
I got an email from Amazon Web Services this morning, regarding a set of API keys I setup a while back, for a prototype I was building. The project was over a year ago, and the keys have not been evolved, and managed like I do with the rest of my regularly used AWS API keys.  Here is the email I received: We noticed that your account contains root access keys that are more than 1 year old. As a security best practice, AWS recommends removing your root access keys entirely and using AWS Identity and Access Management (IAM) instead. At a minimum we recommend rotating access keys regularly or removing access keys if they are no longer in use. To help you determine whether your access keys are safe to rotate or delete, AWS Identity and Access Management (IAM) now reports the time stamp when access keys for an IAM user or root account were last used, along with the region and the AWS service that was accessed...

Intuit Baked Their itDuzzit Acquisition Into Their Platform And Are Calling It Intuit AppConnect

07 July 2015
I wrote about Intuit's acquisition of API reciprocity provider itDuzzit last summer, and earlier this month they made the acquired technology available as a new platform extension, they are calling Intuit AppConnect Beta. I have been tracking on API reciprocity providers for some time now, something you see API providers adopting at an increasing rate, as a standard building block for their API ecosystems. API reciprocity tools and services like Intuit AppConnect, help connect APIs, in ways that even non-developers can take advantage of, making the overall API conversation, available to a much wider audience. Intuit describes their new offerings as: Intuit AppConnect is an iPaaS (integration Platform-as-a-Service) offering that runs wholly on Intuit’s AWS stack...

API Police Report: Raw Thoughts From On-Boarding With Your API

06 July 2015
I am working hard to generate detailed profiles, that include APIs.json indexes, and Swagger definitions, for each of the 1000 companies I have listed in the API Stack. I have encouraged anyone to step up and help me profile these companies, join the conversation via the Github issues where the API stack is hosted, resulting in some really nice folks jumping in to hellp me tackle the hard work. One of these brave souls who stepped up, and get their hands dirty is Bob Salita, who is also sharing his experience, via what he calls an "API Police Report", derived from his experience onboarding with APIs. I thought his condensed thoughts reflect what I see everyday as I onboard with new APIs, and was worth sharing...

A Complete (Enough) API Definition To Move On and Profile The Next API in The Stack

06 July 2015
I'm working to profile as many of the top, publicly available APIs out there, as part of the API Stack. While I've come to feel that no API definition will ever actually be complete, I'm working to at least establish a healthy baseline for the APIs I am profiling, while also automating as much of the process as I possibly can. To help focus my work, I'm targeting 30 companies that I depend on to run API Evangelist, and one of the first APIs I wanted to harden my process on was the AlchemyAPI. The API is fairly straightforward in design, and operation, so it made for an easy target--so far here is what I have: AlchemyAPI (swagger) (apis.json)   Alchemy Author Extraction API (edit)         Alchemy Authors Extraction API (edit)         Alchemy Combined Call API (edit)         Alchemy Concept Tagging API (edit)         Alchemy Entity Extraction API (edit)         Alchemy Face Detection API (edit)         Alchemy Feed Detection API (edit)         Alchemy Image Link Extraction API (edit)         Alchemy Keyword and Term Extraction API (edit)         Alchemy Language Detection API (edit)         Alchemy Microformats Parsing API (edit)         Alchemy News API (edit)         Alchemy Publication Date Extraction API (edit)         Alchemy Relation Extraction API (edit)         Alchemy Sentiment Analysis API (edit)         Alchemy Taxonomy API (edit)         Alchemy Text Extraction (RAW) API (edit)         Alchemy Text Extraction API (edit)         Alchemy Title Extraction API (edit)       My goal was to index the AlchemyAPI operations using an APIs...

A Simple Walkthrough Of How To Deploy A 4th of July Fireworks API Using A Google Spreadsheet And APISpark

06 July 2015
This is a guest post by Guillaume Laforge (@glaforge) of Restlet. He did a very cool API deployment project over the holiday weekend, as was good enough to share the details of his project as a story. I've been trying to make time to do more of these simple how-to API deployment guides like this, so I'm always happy to guest post these when they help users understand that they can deploy APIs--no developer necessary. For the 4th of July, to celebrate the United States’ Independence Day, Restlet built a fun little website and API to list all the fireworks in your area. You can see all the states where fireworks have been found, and lists of towns in those states where those fireworks were taking place...

Where Is The Containerized API Marketplace That Businesses Will Need For Success In The API Economy?

06 July 2015
Building on what Orlando (@orliesaurus) brings up in his story on the missing brick in the API Industry, we are missing a common place to discovery and share common API designs--something I've been working hard on with my API Stack. As I read this piece from Microsoft Azure on Container Apps now available in the Azure Marketplace, I'm reminded of how robust the app deployment, and management ecosystem has become with the containerization evolution, but when it comes to API deployment we are still way behind the times. There are numerous containerized marketplaces of apps available out there today, what I am looking for is the same thing, but for common API patterns. After over 10 years of solid design, deployment, and management of web API patterns, we should have a wealth of API design patterns to choose from...

Five Years Of API Evangelist

03 July 2015
In July of 2010, I started researching what would be the next step in my career. I was VP of Technology at WebEvents global, and was in charge of the technical side of running conferences for SAP and Google. I enjoyed the work I did, scaling the technology to support the events, using the Amazon Cloud and APIs, but I was not fully satisfied in the events industry.  I clearly remember spending my Fourth of July weekend researching some possible next steps. Building on my strengths at the time, I looked at what I could do in the cloud computing space. My early research is still even online, forever preserved as a Google Site. The last update to the research was mid half way through July, when after a couple weeks of careful evaluation and contemplating, I saw the core of cloud computing was really about APIs...

Building Micro Apps and Tooling On Top Of Your API To Demonstrate The Value Your API Delivers

01 July 2015
I was doing one of my regular checkins with my friend Anne Wootton (@annewootton) of Popup Archive today, something we try to do regularly, to share stories about what they are up to in the world of audio and podcast API, and what I am seeing across the voice, audio, video, and wider API landscape.  Anne was walking me through their latest rollout AudioSear.ch, a full text search & recommendation API for podcasts and radio, that is API driven. One of the endpoints for the AudioSear.ch API allows for searching of people who are involved with the podcasts and radio programs that they are indexing. As we talked, she articulated that in order to help people see the value the AudioSear...

The API Design Tooling I Have Included In My Research

30 June 2015
I am going through each of my research projects, and tightening things down, now that I have them all driven through my new, master stack of APIs. First up was API design, and the other day I spent time going through the organization I track on as part of my API design research, and today mission was to refine the tooling section. Previously my tooling page was just an alphabetical list of tools, and I wanted to at least group things in a more meaningful way, reflecting how I break them down in my own monitoring system. So I reworked the publishing to allow me to group the tools by tags, resulting in the following list: API Blueprint API Blueprint   API Blueprint is a documentation-oriented API description language...

Tightening Up The Organizations That Are Included In My API Design Research

30 June 2015
I try to go through each of my areas of research as often as I can and update the content, as well as my understanding. Ideally I update the news each week, take a look at the organizations involved once a month, and evaluate the building blocks and tools each quarter. Unfortunately it doesn't always happen as planned, but as a one man operation, I think I do pretty well.  I just went through my API design research, and adjusted my definition of what I felt needed be listed there. As I move API definitions to their own research area(s), I'm reconsidering what I want to keep an eye on when it comes to API design, and my current definition involves organizations who offer API design editors, either in the cloud or as download...

APIs Will Not Be Suffocated By Oracle and the Courts, It Will Be Done By Each Of You Not Sharing Your API Designs

29 June 2015
I just read on Re/Code, that the Supreme Court declined to hear Google's appeal on the Oracle v Google case--prepare for the waves of stories from tech blogs, that this will suffocate the API economy. During the last response to the case by the US Solicitor General, I wrote about how I can't even argue the concept anymore, and nothing has changed for me.  I just wanted to take the moment to remind everyone that this decision means nothing if we all share our API definitions, in open ways, using machine readable definitions like API Blueprint and Swagger. The disturbing move by Oracle to bring a lawsuit against Google, and the very unaware decision(s) made all the way up to federal level, will NOT bring down the API economy--your inaction will! If I've learned anything during my time defending APIs, as part of the Oracle v Google case, is that many of you are holding your API designs close to your chest, thinking maybe, just maybe, they are intellectual property we should protect, and can make money on, when we are the next unicorn start-up...

APIs.json Driven API Dictionaries For Use In Atom IDE Autocomplete Packages

27 June 2015
I have been using the Atom editor when I work on local files on my workstation for some time now. With the latest version 1.0 release I took a fresh look at the architecture, and under the hood at the packages that make the platform so powerful, and extensible. One of the packages I was reverse engineering this weekend, is the Atom API Autocomplete Package. The Atom API Autocomplete Package is one of several autocompete packages that gives Atom some of that IDE feel when you are editing files. I like the feel of Atom autocomplete, and I really dig that this functionality is extensible via Atom packages. This experience got me thinking again about the IDEs role in API design and development, and how I'd like to see more API definition driven dictionaries, defined using APIs...

The Responsive Swagger Driven Version of Slate API Documentation I Was Looking For

27 June 2015
I wrote that we should be generating Slate API documentation from Swagger so we maintain a machine readable core the other day--while I love the look of Slate, I want to make sure all API meta data is machine readable by default. Shortly after publishing my post, someone kindly pointed me to a version of Swagger that was developed by Jens-Ole Graulund, which was exactly the evolution that I was looking for. The more response, Swagger driven version of Slate API document is perfect! Giving API providers a more attractive, response version of Swagger UI (sorry Tony), while also keeping the core machine readable.--it is the best of both worlds! I plugged in one of my other complete Swagger definitions, and boom...

Looking At API Design, Deployment, And Management From A Form Point Of View

25 June 2015
The concept of a form, is one one of those skeuomorphs, that have taken on an entirely new life on the Internet. The concept of a form is baked into HTML, PDFs, and many other commons aspects of our digital lives, while also still dominating many of the information exchanges in our physical worlds. There are a handful of APIs out there that let you build forms, and their are APIs that let you build forms for platforms like Drupal, but I have yet to see a platform that uses the concept of a form, as carrot to design, deploy, and manage your API--until now.  I was introduced to Form.io at Gluecon this year, and was very please with the demo I was given (and my time playing with since). Form...

We Should Be Generating Slate From Swagger So We Maintain A Machine Readable Core

25 June 2015
I am a big fan of API documentation when done using Slate. It creates very beautiful, and easy to use documentation, that makes learning about an API much more pleasant. You can find some pretty good examples of Slate being used in the wild, with the Travis CI API, Dwolla API, and API Science API.  Slate goes a long way in standardizing the documentation for APIs, but I would like to see this go further. I am working to profile both Dwolla and API Science as part of defining the stack of APIs that I depend on to operate the API Evangelist network, and while I enjoy the attractive UX Slate brings to the table, I'm lamenting the lack of a machine readable API definitions along the way...

The Expanding API Economy From The 100K Foot View

25 June 2015
This is one of several stories I am evolving as part of series I'm calling API fairy tales. With these tales I want to educate business leaders, technologists, and government about the importance of Application Programming Interfaces (API), and how they are being applied in almost every aspect of business occurring online today--providing simple examples that mainstream users can learn from, as well as retell in their circles. The Internet is slowly changing almost every aspect of our society, and a major part of this evolution is rooted in how we develop software, something that has been slowly building over the last 15 years, in the form of what is known an Application Programming Interfaces, or simply called APIs...

Breaking Down Publication References With The Global Change Information System API

23 June 2015
I wrote about the Global Change Information System (GCIS) API earlier this year, and how they what they are doing with their API design represent how APIs are the next step in the evolution of the web. If you have the time, go look at what they have done, it is mind-blowing. I am on their email newsletter, and have had their latest update in my inbox for a few days, with some thoughts attached to it I wanted to blog about, before I archived the email. I love that they provide updates like this via email, but ultimately this story is about how they are iterating on their API design, making it much more useful, and powerful along the way—with some elements I’d like to see spread across other content and document based APIs...

Image If Everyone Automatically Knew That APIMATIC Had Added A New Endpoint?

23 June 2015
I wrote a story yesterday about APIMATIC releasing a new API validation API to compliment their existing API client code generation API. I received an email from the APIMATIC team is how I found out about the API, but as I'm processing that story, and thoughts around what I'd like to see for API Changelog (something Paul of @BlockSpring brought up), I'm lefting thinking about how antiquated our whole world of API discovery is. As soon as APIMATIC updated their API Blueprint file, all who use APIMATIC, and us API pundits (clowns) in the space should, should receive a push notification. This type of notification is exactly what API Changelog does, but it does it based upon a document diff, rather than finer grain, machine readable detail like what is available in a Swagger or API Blueprint definition...

Someone Should Do A Site Like CodeProject, But Just For APIs

23 June 2015
As part of my monitoring of the API space, I keep track of new posts on CodeProject, and occasionally I come across an API integration project. Some of the times it references it as an API project, while most of the time it will just reference the platform being used, like a Magento Commerce project, or a Youtube project. As I was reviewing a couple of interesting projects this week, I was thinking it would be nice to have a more modern, simpler version of CodeProject, but exclusively dedicated to APIs. The site could provide regular walk-through of API integration, aggregation, or reciprocity patterns. The site wouldn't have to do that many projects, just a couple a month would be fine to begin with, increasing the volume after things get going...

The Over 30 APIs I Depend On To Run API Evangelist

23 June 2015
I am working to craft complete Swagger definitions for the 1000 companies in my API Stack, and what better place to start than with the APIs that I actually use on a daily basis. I am working hard to make sure all the APIs for my own master API stack are as complete as possible, but taking inventory of the public APIs that I depend on also makes a lot of sense.  I've long kept a list of APIs that I use, for IT purposes, but I don't have a complete profile of all of these services. As with any vendo, I should have a complete profile of the APIs I depend on, with relevant support channels, documentation, code samples, monitors, and some of the other essentials I track on for other APIs in the space...

APIMATIC Adds New API Validation Endpoint To Their API Client Code Generation API Stack

22 June 2015
I am working hard to establish a complete set of APIs for my own API stack which includes establishing complete Swagger definitions for the 25 APIs that I personally operate. These Swagger definitions are then used to generate Postman Collections, APIMATIC SDKs, and API Science monitors. I am also working hard to establish complete Swagger definitions for the 1000 companies in my API Stack, something I am partnering with APIMATIC on.  As part of this work, both teams are working hard to evolve our tooling for working with, and validating API definitions. I mentioned a couple weeks back, when I shared client SDK research conducted by APIMATIC, that quality SDK generation is kind of the high water mark for measuring API definition completion--meaning if your API definition isn't complete enough to generate a functional SDK, you need to spend more time in your API design editor, until it is more complete...

Build Some APIs With Restlet And API Evangelist During The Summer of APIs

22 June 2015
I am partnering with the Restlet team to put on a Summer of APIs, a virtual API challenge. The goal with this summer program isn't to build apps on top of APIs, but build APIs that anyone can use, by crunching some valuable information resource, and make it easier to use in web and mobile, as well as potentially in embeddable tools, and even in spreadsheets--using APIs. I've gathered up some valuable sources of data, ranging from industry datasets from Data.gov in Washington DC to data sets that can help us with the water crisis out in California, which is included in detail about the program. I did a little homework for you, but dont' feel like you have to stop there, you can make any data, content, or other digital resource into an API during the Summer of APIs...

Making My API Projects Forkable, Sharable In An IDE, Using Codenvy And APIs.json

21 June 2015
I am playing around with making several stops along the API life cycle more accessible, and machine readable using APIs.json. To help me in my work, I am using my own API stack as a proving ground, resulting in the addition of Postman Collections, APIMATIC SDKs, and API Science monitors over the last couple weeks. As I'm working through the 25 APIs I have, and almost 350 endpoints, making sure the Swagger definitions are complete, the latest evolution of my API management service composition is applied, APIMATIC SDKs up to date, and API Science monitors are setup, I stumbled across another critical stop along the life cycle--the IDE. I use Codenvy for my IDE. It allows me to easily manage my numerous APIs, and applications that depend on my APIs, in a single cloud based development environment...

The Swagger Definitions Collection Is The Cherry On Top Of Each API That I Profile

21 June 2015
I create a lot of machine readable API definitions for the 1000 companies I monitor as part of my API Stack. I am using Swagger to define all of my APIs, providing me with a simple, yet powerful way to profile each of the APIs I'm working to understand better. If you aren't familiar with Swagger, it provides a handful of fields you can use to fill out the metadata profile for APIs, like title, description, etc., but where it really gets powerful is when you put the paths collection to work, outline the details of each endpoint. Most of the APIs I come across that are defined using Swagger, focuses on providing details on each path, including verbs, headers, parameters, and sometimes response status codes...

Parsing Charles Proxy Exports To Generate Swagger Definitions, While Also Linking Them To Each Path

21 June 2015
Making sure the Swagger files I craft possess a complete definition for its underlying data model, one that is linked to each API path, and parameters where it is put to use, is important to me, but damn it is a lot of work. As I mentioned in my last piece I'm looking at the Twitter Swagger file, and my head starts spinning thinking about how much work it will be to hand-define all of the data models that used across the almost 100 Twitter endpoints. I quickly got to work finding a better solution--I landed on Charles Proxy. I had downloaded and installed Charles Proxy to better understand how we could map out the dark layer of the API universe, that the popular mobile applications we use depend on...

Initial Thoughts Around Monetization For An API Deployment Service

19 June 2015
I am helping a client work through their monetization strategy for an API deployment service. To help me give me a starting point for the work, I wanted to take a look at a handful of existing service providers, that may not be a perfect match, but somewhat in the same realm--API deployment.  For this phase of the work, I looked at six API deployment providers, who in my opinion have a pretty straightforward, modern approach to crafting, publishing, and sharing their pricing. It always amazes me how hard it can be to just find a companies pricing, let alone make sense of it...but I digress, that is another story. Here are the API deployment providers I reviewed: API Spark, with 5 pricing tiers, broken down by concurrent connection (based upon IP address), number of APIs, the entity and file storage across APIs...

Going Beyond Just API Status And Providing An Official API Monitoring Service(s) With Your API

16 June 2015
I've long advocated that an API Status page should be a required building block for any API operation. As I work on monitoring for my own master API stack, and as I read stories like Pingometer Keeps Your Uptime In The 9’s With Twilio SMS, I'm thinking we need more that just a simple status report for our APIs. From an API provider standpoint, we should have a more nuanced view of our API availability, beyond just up or down--something popular API integration service providers like Runscope and API Science have been saying for a while. If our APIs are publicly available, I'm going to even suggest providers start actively sharing their API monitoring strategy, and resulting data with the ecosystem--something I'm going to also be advocating for inclusion in the APIs...

Add SDKs.io URL For Companies And APIs That I Track On Via The API Stack

16 June 2015
I am partnering with APIMATIC to help establish a common set of complete, and validated API definitions for the almost 1000 APIs I track on as part of my API Stack. I am using my Questions API to identify what work is needed to be done, by asking basic questions about companies, via their APIs.json definition, resulting in quick tasks I can accomplish that help us achieve our goals. A portion of this work, involves making sure that the APIs in my stack are also linked to their SDKs.io profile. If an API in my stack doesn't have an SDKs.io icon, I know that I either need to search and find it in SDKs.io, or I need to publish a copy of the Swagger definitions I have to APIMATIC, and publish it to SDKs...

The Gumroad Small Product Lab: Accelerating Simple Ideas

16 June 2015
I use Gumroad for publishing of my white papers, and I also keep an eye on what they are up to as part of my API monitoring--they have a pretty useful publishing API. During my weekly API.Report this last week I came across their Gumroad Small Product Lab, a cool idea that I'd like to see happen in more API ecosystems, or maybe even across them.  According to Gumroad the the Small Product Lab is a "mini course, community, launchpad, and contest to remove the unknowns and barriers to getting your work out in the world"--Ten days, ten actionable lessons: Day 1: Mark your calendars Day 2: What’s your product? Day 3: Plan it Day 4: Create a style guide Day 5: Ready, set, go! Day 6: Share your process and progress Day 7: Decoding the pricing puzzle Day 8: Package it up Day 9: Prep for launch Day 10: The launch and onward Gumroad is focusing on their customer base (media publishing), but the format is something I'd love to see occur in API ecosystems, helping developers and API consumers put API resources to work for them...

My Minimum Viable Definition For A Complete Swagger API Definition

15 June 2015
I have been working hard to establish some sort of minimum viable definition for a complete Swagger definition is, and I think I finally have got to a point where I have it--at least enough to work through the next 100 or so APIs I'm targeting for completion.  I originally identified almost 30 separate questions specifically targeting Swagger, but for my minimum viable definition I've isolated it to just 19. I automated asking of these questions, using my Questions API, and to test things out I applied it to my API API: API (APIs.json) Is there a Swagger definition? yes Is there a Swagger API title? yes Is there a Swagger API description? yes Is there a Swagger API host? yes Is there a Swagger API base path? yes How many Swagger API paths are there? 24 Do all Swagger API paths have tags? yes Do all Swagger API paths have summary? yes Do all Swagger API paths have description? yes Do all Swagger API paths have operation id? yes Do all Swagger API paths have parameters? yes Do all Swagger API paths have responses? yes Do all Swagger API response have references to definitions? yes Does Swagger APIs have security definitions? yes Do all Swagger API paths have security references? yes Is there Swagger API definitions? yes Do all Swagger API definitions have properties? yes Do all Swagger API definition properties have a description? yes Do all Swagger API definition properties have a type? yes   In theory, I can run this on any APIs...

DreamFactory Deploying APIs In Docker Containers Is How The API Economy Will Scale

14 June 2015
I have been talking about virtualized API stacks for a while now, slowly evolving my own view of whats next for the world of APIs, based upon what I'm seeing happen across the sector. I am working hard to convert my own master stack of APIs, in 25+ separate container driven APIs, which I can then orchestrate into other collections for my own use, as well as the needs of my partners, and wholesale API clients.  The post Running DreamFactory as a Docker Containers came across my monitors this weekend, which for me is a sign we are getting closer to a version of the API economy that I think will actually scale. The days where you launch one API platform, with one or many APIs, and you only sell that service via a single platform domain, have peaked...

Swagger Represents The API Value Possible, Postman Is Unit Readied As Transaction, And HAR Could Be Evidence Of Value Actually Having Occurred

13 June 2015
I am working through each of my 25 APIs right now, tackling a list of changes that include some adjustment for an evolution in my service composition, generating Postman collections, APIMATIC SDKs, and API Science monitors--for each API. I was talking through the process of setting up my API monitors, and how I will be generating status pages for each API portal, with John Musser (@johnmusser), and he reminded me of the HTTP Archive (HAR) format.  HAR is all about providing an archival format for HTTP transactions that can be used by a web browser to export detailed performance data about web pages it loads, which got me thinking about how we can use the existing format to record and quantify the exhaust from our increasing API activity...

You Gotta Keep Em Separated: Breaking Down APIs Into Smaller Swagger Files

13 June 2015
As I work to chase an elusive answer to the question, what is a complete API Swagger definition, I'm also faced with what I know John Musser (@johnmusser) would agree is the age old question, what exactly constitutes an API? Is it the Twitter API, or is it the Twitter account, status, friends, media, etc. APIs? While this has been a tough question, facing anyone who considers API discovery, I think it is a question that is evolving as part of the current microservices conversation.  One layer of the microservices onion is focused on breaking down services into their smallest possible unit of value (at least this is one of my takeaways). Doing this is an enabler all the other orchestration, devops, voodoo magic that represent the other architectural layers of the microservices onion...

Using API Definitions To Help API Providers With Their API Design Roadmap

10 June 2015
As I work to create Swagger API definitions for the almost 1000 companies in my API stack, I'm chasing an elusive definition of a complete Swagger definition for any API. Only a small portion of APIs I am defining using Swagger will reach an 80-90% completions status, in reality most will never be complete for reasons that are totally out of my control. When it comes to crafting API definitions for public APIs, I may be able to get the API definition complete in the sense that it has all the paths, parameters, responses, definitions, and security configurations, but if the API itself is missing pieces--the API definition will always be incomplete (in perpetuity). As I work to automate the questions I ask of Swagger definitions, helping me get to a more coherent definition of what is a complete Swagger definition, I can't help feel the need to offer API design tips to the API providers I am profiling...

New Approach At Google Assumes That The Internal Network Is As Dangerous As The Internet

10 June 2015
I was recently reading about Google moving its corporate applications to the Internet, and as my brain works, began applying this ine of thinking to the world APIs. I am big advocate for companies being more transparent, and acknowledging that more and more of our ever day business occurs on the open Internet, and we should start treating it like we are. I think one statement in the Google paper says it well: The new model — called the BeyondCorp initiative — assumes that the internal network is as dangerous as the Internet.  As the Internet penetrates more of our personal and business lives, the concept of a private, localized, and secure network, is fading. Even if a system is only accessible via a local area network, if any node on that network has Internet access, and delivers resources to web, mobile, and increasingly devices via DNS--it is operating on the open Internet...

API Integration, Aggregation, Organization, and Reciprocity with Cloud Elements

10 June 2015
I have had Cloud Elements under my API aggregation research for some time now, keeping an eye on what they are up to via their blog, Twitter, and Github accounts. Cloud Elements takes a handful of top API driven platforms, which they organize into their Elements Catalog, aggregating them into a single API driven platform. API aggregation is something I've been a big supporter of, and API reciprocity as with companies like Zapier, is something I feel compliments how we operate on the open Internet. Today, Cloud Elements made an interesting move forward with the ability to map new elements, via an API, which in my book moves them more into API reciprocity space, than it does aggregation--meaning you could in theory launch a specialized Zapier, using Cloud Elements...

Splitting My Blog API Into Two Separate APIs For News And Analysis

10 June 2015
When I started API Evangelist, I knew I didn't want to use WordPress or other common CMS, so I developed my own API, and page and blogging CMS. During the latest migration of my internal API infrastructure, I'm rebuilding everything as a single stack of APIs that I  can use to operate API Evangelist. Part of this process is breaking down legacy systems, into the small possible unit of value, something I consider deeply as I rebuild each API. It started with my link system, which I broke up into link, curation, keyword, and linkrot APIs. Now I'm eyeballing my legacy blog API, which historically I also use to publish news pieces to API.Report, and sections that I syndicate to white papers I have published...

My New API For Asking Questions Of APIs - The Swagger Edition

09 June 2015
I am currently trying to move forward the 917 companies, from 223 business areas, with a total 882 APIs catalogued, and 407 Swagger definitions created, while working on a distributed way to understand where the profiling for each company is, and how far along the underlying Swagger definitions is. I had kicked off another prototype APIs.json type a few months back I'm calling api-questions to handle just this, in a way that allows me to ask human readable questions about APis, while also storing in a distributed, machine readable format that can be indexed via each APIs.json file. The other evening I publishd a walk through of a Swagger file. I wanted to create a simple walkthrough for my readers, but my primary goal was to break down the moving parts of a Swagger file, and try to quantity what elements I would need before I could call a Swagger definition "complete"...

My API Service Composition Tiers

08 June 2015
I am slowly getting my new API stack in order, where I am close to opening it up for access to a wider audience. As part of this last round of work, I'm fine tuning my service composition strategy a little more. If you aren't familiar with API service composition, it is just about creating different levels of access to your APIs, and using my 3Scale API infrastructure I can easily break this down. The most common approach to API service composition you see out there is public and private, with maybe an additional partner tier. I'm taking a slightly different approach to defining my layers, and so far, her is what I have: Open - The completely open layer to my APIs that doesn't require any keys at all, like my website, but JSON...

How Do You Know When A Swagger API Definition is Complete?

06 June 2015
As I go through the research from APIMATIC regarding automatically generating client code using Swagger, and I prepare to crank out Swagger definitions for almost 1000 companies in the API Stack, one big question I face is, what exactly is a complete Swagger definition? An incomplete Swagger definition does you little good. I've gotten away with just mapping out some API endpoints, verbs, and parameters, to add another dimension to my API monitoring, but without authentication details, status codes, and the underlying data model, you can't do much else that is meaningful with them--as the APIMATIC research demonstrates. We need to start refining not just a definition about what is complete, but tooling and services that can help us get to complete as fast as we can, and automate the certification of any API, using Swagger...

A Walk Through A Swagger API Definition To Identify The Moving Parts

06 June 2015
I recently added a new tool to my hacker storytelling toolbox, that allows me to easily assemble walk through, that help me guide my readers through a scripted series of steps around any of my research areas. I first did it to walk through what I'd consider to be my minimum viable developer portal, and now I decided to apply to my Swagger research. I am working on a set of APIs that help me quantify whether a Swagger definition is "complete" or not, to help me tackle my goals around my API Stack research, and establish a rich set of complete, open API definitions that the community can put to use. What better way to quantify all the moving parts of Swagger, than to actually create a 101 walk through of its moving parts...

Comparison of Automatic API Code Generation Tools For Swagger

06 June 2015
I have met with the APIMATIC team several times over the last couple weeks to discuss the state of API definitions. If you aren't familiar with APIMATIC, they are a API code as a service provider, that generates high quality client code in several languages, if your APIs are defined using common API definition formats like Swagger (they are also the people behind SDKs.io). APIMATIC is as passionate about high quality Swagger definitions as I am, and have shared some really valuable research to help push forward the API definition conversation. In May, APIMATIC wanted to compare the quality of automatic code generation tools, using common Swagger specifications they found on Github. To set the bar for their research, APIMATIC established some basic operational parameters: Code generator must support Swagger file format Only client-side bindings are considered Must create complete libraries rather than just code snippets Only the following languages are considered: C#, Java / Android, Objective-C, PHP, Python Ruby While this research focuses on Swagger, I think the findings can be applied when thinking about other API definition formats like API Blueprint or RAML, but kicking things off with a focus on Swagger is wise...

Join @apimatic, @blockspring, and @apievangelist In Completing API Definitions For 1000 Companies In The API Stack

05 June 2015
3Scale and I have been working hard to craft APIs.json files for the top public APIs out there, including machine readable Swagger definitions, ever since we launched the open source API search engine APIs.io. We will keep working to define, and index the API space, but it is a lot of work ahead, and we could use some help. Over the last couple months I've had several conversations with folks about the need for Swagger and API Blueprints for popular APIs, so that the community can build valuable tooling and services on top of commonly used APIs. Two companies who I've been talking to are SDK generation service APIMATIC, and API spreadsheet integration provider BlockSpring. APIMATC wants see better quality Swagger definitions emerge, so they can build client SDKs that work, and make available via SKDs...

Visions Of My Perfect API Design Editor Using Electron

04 June 2015
Darrel Miller(@darrel_miller) reminded me of the desktop development platform Electron the other day, with his story on Moving Beyond the Browser with JavaScript and Hypermedia. I had been eyeballing Electron as a potential candidate for my perfect API design editor, something I honestly don't have the bandwidth to build, but is something I enjoy pushing forward in thought. If you aren't familiar with Electron, it is what powers popular desktop version of the apps that I use most--Github, and Slack. The open source desktop framework, developed and maintained Github, allows you to deliver simple, easy to maintain desktop experiences, using HTML, CSS, and JavaScript--powered by Chromium and Node...

Storytelling and the Future of Hypermedia APIs

04 June 2015
Helping people understand the potential you see around a particular approach to API design, is hard stuff. Providing easy to follow stories, and implementations that the average person can follow is something I've dedicated myself to at API Evangelist, and something I'll keep working on when it comes to evolving API approaches like hypermedia.  Hypermedia has long suffered from an image problem, something I feel can be remedied through a little hacker storytelling on the part of hypermedia API media type owners, API providers who bake hypermedia into their practices, and the developers who are crafting meaningful hypermedia driven experiences. In 2015 I feel like we are getting closer to fixing this, but as I said, this stuff is hard, and takes a lot of work...

Testing New Publishing

30 May 2015
This is my testing.

Generating Single Page Apps In React.js From Your Swagger Defined API With ReaCall

29 May 2015
I wrote about a simpler example of API to SPA the other day, continuing my journey for apps, services, and tooling that easily deploys a Single Page App (SPA) or light-weight web and mobile clients from a single API, or many APIs. One of the reason I am so transparent about my ideas, is because I depend on my audience to help educate me about what is out there--one of my readers, who is always schooling me, pointed me at Project ReaCall.  Jean-Jacques Dubray's (@metapgmr), Project ReaCall combines React.js and Swagger to make it easier for API providers to develop and evolve API Client SDKs (ACS). This is definitely the direction I'd like to see client SDK and SPA deployment space go...

"Have Fun with Your Terms of Service"

28 May 2015
This is a guest post from Marsh Gardiner, who knows a little secret...that anyone can submit stories to API Evangelist. All you do is submit a pull request on the Github repo that runs the site. Of course stories still have to meet my standards, but Marsh shares many of the same views of the APIs space, and knows what is important to my readers, and the API community. Spotted on Twitter today: Slack's new API ToS is fascinating. It forbids using their API to collect data for the government or law enforcement: pic.twitter.com/zBAtbYuHo8— Eric Mill (@konklone) May 28, 2015 … and based on Stewart Butterfield's response, this gem is the work of Anne Toth: @craig_montuori @konklone @etrepum All blame or credit to @clean_freak— Stewart Butterfield (@stewart) May 28, 2015 At their worst, terms of service sound like an invitation to live in a police state...

Regarding The Solicitor General Weighing In On The Oracle v Google API Copyright Case: Are You Really Surprised They Do Not Get APIs? I Am Not!

28 May 2015
My first emotion after reading the brief filed by the US Solicitor General, is that the federal government's stance is so wrong, antiquated, and shows how behind the curve our government actually is when it comes to the unfolding API economy around us. Then as with each moment in the past, associated with this very important legal case, I become tangled in the web that is politics and intellectual property (IP) law in our country--leaving me confused, betrayed, and embarrassed for the industry that I take pride in being a champion for. It is easy to get caught up in the page view buzz, emotion, and hype of each of these episodes, but in the end I will just keep fighting for open API patterns, and Oracle's damaging stance, and the fact the federal government is a revolving door for industry, really is just par for the course--business as usual...

A Cleaner, Simpler Example of API To SPA

27 May 2015
One of my areas of research that got boost of energy at Gluecon last week, was the area of Single Page Applications, aka SPAs. SPAs are one huge area of potential growth for the API space, but like many other areas, they haven't seen the wider, more meaningful deployments, or adoption, that I had hoped for early on. I think up until now the definition of what an SPA is has been heavily dominated by the technical side of things, as opposed to the delivery side--SPA are still mostly about providing solutions for developers, over solutions for the end-user or business owner. When it comes to SPAs, I stay away from the more established frameworks, opting for a simpler design--minimal platform or framework adoption...

Rolling The Dice - Swagger, Postman, and ALPS

27 May 2015
I enjoy playing with simple, meaningful ways of leaning about APIs. The other day, during the regular monitoring of the API space, I came across a simple dice rolling API, which I decide to map out using Swagger. Shortly after I did  this, I saw Mike Amundsen post an ALPS representation of the Dice Rolling API. Around the same time, I then imported my Swagger into my Postman client, and exported a Postman collection. Once I had the three formats, I sat back to consider what each of these representations mean to me: Swagger - A map of the surface area that is dice rolling. Postman - A single representation of actions that can be taken--now. ALPs - A representations of the what it means to roll the dice...

The Emphasis During Next Phase Of API Evangelist Will Be About You Telling Your Story

26 May 2015
I am going on five years of API Evangelist this summer, and I've been doing some reflecting about what the next five years will be about. While listening to my friend Mike Amundsen (@mamund), I had an idea, that I think I will evolve more during the operations of the next five years of API Evangelist (yes, sorry I'm not going anywhere). First, I want to clarify that when I started API Evangelist in summer of 2010, I spent a lot of time trying to create a logo, resulting in me creating this temporary (5 years) logo, that you have seen on my t-shirts for the last five years. After listening to Mike spin his yarn, I'm convinced that the next wave of growth for API Evangelist has very little to do with me, and my brand, than it does with the rest of the API community...

Why You Are Not Doing Microservices Right!

26 May 2015
Yeah, I know, it is a click-bait title. My goal is to not flame the haters, but educate everyone involved, both the people looking to learn about microservices, and those who are practicing microservices, so I'm hoping you will forgive me--my goal is not page views. I'm sticking to my goal of not making microservices a regular thing I talk about, but I wanted to share some observations after listening to folks talk at Gluecon last week--a week that was full of microservices love (and hate). In the past, I mentioned that I received a handful of emails, and DMS from folks letting me know I'm not doing microservices, and after Gluecon I think I have a beginning list of why I think people generally are telling me I'm doing it wrong...

Going Beyond Just Documenting Your API, And Making Things Fun

26 May 2015
I look at a lot of API documentation, something that until recently has been pretty static--pun intended. As an API consumer I really appreciate standardized approaches to documenting an API, like using Swagger or API Blueprint, but I also really enjoy when people go the extra mile to add little details, that make the experience a little more fun. A recent example of this is from the Spotify API team. When it comes to the search endpoint for the Spotify API, they put in this little addition: The field filter tag:new can be used in album searches to retrieve only albums released in the last two weeks. The field filter tag:hipster can be used in album searches to retrieve only albums with the lowest 10% popularity...

Swagger Allows You To See The Girl In The Red Dress

23 May 2015
While at Gluecon this week, one of the events I particpated in was the Swagger API Meetup, Tuesday evening. There was a small group of Colorado Bros (TM) there, admittedly there "just for the beers", who asked what is Swagger? Valid question, and something I'm always willing to help onboard folks with. First I made sure they knew what an API was, then simply stated, "Swagger lets you see the girl in the red dress" -- making a Matrix reference, hoping to onboard them with the concept of Swagger, via a familiar movie analogy.  As I've spent time hand crafting the Swagger definitions for my 25 APIs, which includes almost 350 endpoints, the surface area of my operations have slowly come into focus...

A Unique and Personal API Onboarding Experience

15 May 2015
I have written many times before about the right way to onboard with an API, as well as how not to onboard with an API. I see a lot of APIs, and can tell you which APIs have put thought into the process, and those who haven't. Helping companies smooth out the sharp edges on their API onboarding is something I spend a lot of time doing, so I work hard to make sure the topic shows up regularly in my writing. Today I want to highlight a slight different onboarding email I received from Weather2020: Hi there Mr. Lane!First off I'll get my lil bit of gushing out of the way.  I really enjoy what you're doing out there in the world.  I love your commitment and passion to the growing world and need for APIs and your focus on the narrative vs...

Are You Doing Anything Interesting With @APIBlueprint? Or Know Someone Who Is?

14 May 2015
I am preparing for a big week of discussion around API definitions at Gluecon, and in addition to working on my Swagger research, I kicked off deeper research into API Blueprin, looking for the companies that are doing interesting things in the space, using the machine readable API definition format. As i do with all my work, I have a Github repository setup for the research, allowing me to publish all of my work publicly, and manage feedback and engagement with the community, using my Github workflow. If you want to make any changes to the data you can fork and submit a pull request, or you can also suggest companies I should be looking at, as a Github issue. So far, I've broken things into four areas: Platform Integrations - Companies who are using the API Blueprint specification as part of their platforms--essentially baking it in...

Usage Of Swagger For The APIs At The UC Santa Barbara Lab for Research on Adaptive Computing Environments

14 May 2015
This is a Github issue submission I received, in response to whether or not anyone is doing anything interesting with Swagger. In the lead up to talks about Swagger next week at Gluecon, in Colorado. I'm pretty impressed with this work at UCSB, and while I am processing it, I wanted to share with you, and hopefully stimulate others to share what they are working on behind the scenes, using Swagger--I've gotten some pretty cool submissions so far. We use Swagger in a series of on going research projects at the RACELab of UC Santa Barbara. Our research focuses on designing and implementing new mechanisms for governing APIs in cloud platforms. Following are some of our published works that make use of Swagger...

It Will Be A Busy Week For API Industry Next Week At Gluecon

13 May 2015
I am preparing to head to Colorado next week for Gluecon--one of my can't miss events in the API space. Gluecon is always a great place to be, to discuss the API space with the folks who are leading the charge, but this year is shaping up to be a particularly important one. There are number of things happening this year, primarily focused around API definitions, that stand to have a pretty significant impact on how the space operates. To help showcase the goings on next week, I wanted to walk through my schedule, which I think speaks for itself. Starting next Tuesday, May 19th, we have two events: APIStrat, API Definitions, Design, and The API Lifecycle Workshop from 1:00 PM to 6:00 PM Swagger API Meetup from 7:00 PM to 9:00 PM Then on the afternoon of Wednesday May 20th, I am moderating the API session track on the main stage: 1:30-1:45 - Track introduction, Kin Lane (@kinlane) 1:45-2:15 - API Readiness: Visualizing and Virtualizing -- Lorinda Brandon (@lindybrandon), SmartBear 2:15-2:45 - How REST APIs Can Glue All Types of Devices Together -- Jerome Louvel, (@jlouvel) Restlet 2:45-3:15 - Roll-your-own API management platform with nginx and Lua -- Jon Moore(@jon_moore), Comcast 3:15-3:30 - Discussion (with audience) led by Kin Lane (@kinlane) 3:45-4:15 - Building a Node...

Are You Doing Anything Interesting With Swagger? Or Know Someone Who Is?

13 May 2015
I am preparing for a big week of discussion around Swagger next week, and I'm spending time going through Swagger research project, refreshing some of the companies I know are doing interesting things in the space, using the machine readable API definition format, Swagger. As i do with all my work, I have a Github repository setup for the research, allowing me to publish all of my work publicly, and manage feedback and engagement with the community, using the Github workflow. If you want to make any changes to the data you can fork and submit a pull request, or you can also suggest companies I should be looking at, as a Github issue. So far, I've broken things into four areas: Platform Integrations - Companies who are using the Swagger specification as part of their platforms--essentially baking it in...

Small Utility APIs: Deck of Cards

11 May 2015
I enjoy documenting APIs that I come across on the Internet. Not all designs catch my attention, but when they do, I like to add them to my monitoring systems, and with some of the smallest, open source designs, I like to fork them.  Today I came across the Deck of Cards API, a simple resource for playing cards, while reading Today in Tabs. I love simple, micro API designs like this, and in addition to adding it to my database, I wanted to make sure I documented the API using Swagger. You never know when an API will go away, so I wanted to capture a snapshot of the API as a machine readable API definition. The code behind is also open source, so I went ahead and forked the Github repository as well...

Applying A Little Hypermedia Is Helping Me Tighten Down My API Design And Tell A Better API Story

11 May 2015
I get hypermedia at a high level, but have no real experience designing or deploying a hypermedia API or client. For the longest time I just watched the hypermedia conversation from afar, but in the last year I have spent time learning about the different approaches, but I still have not gone as deep as I'd like. I'm looking to change this over the summer, and begin to add some hypermedia thinking to my own API design. To get started I've targeted my curation API for the addition of a hypermedia layer, and I'm choosing Siren as my hypermedia format. Siren spoke to me over some of the other approaches, but once I get my bearings I will look at tackling one or two more implementations. As I do with my other work, I'm just looking to share my thoughts in real-time, as I go along...

Small Utility APIs: Roll Dice

11 May 2015
I enjoy documenting APIs that I come across on the Internet. Not all designs catch my attention, but when they do, I like to add them to my monitoring systems, and with some of the smallest, open source designs, I like to fork them.  Today I came across the Roll Dice as a Service API, a simple resource for rolling dice, while reading Today in Tabs. I love simple, micro API designs like this, and in addition to adding it to my database, I wanted to make sure I documented the API using Swagger. You never know when an API will go away, so I wanted to capture a snapshot of the API as a machine readable API definition. The code behind is also open source, so I went ahead and forked the Github repository as well...

A Good Example Of Hypermedia API Using The Siren Specification

11 May 2015
I am spending a small amount of time each week, adding a new hypermedia layer to my link curation API. My goal is to better understand hypermedia, while also improving the designs of the APIs that I depend on for my own operations. During todays work, I was looking for a more extensive example of Siren being used by an actual API provider, taking me beyond what Kevin Swiber (@kevinswiber) provides in his examples.  The example I found that has really helped me go from 0-60 when it comes to Siren (well maybe more like 0-15), was the TV and streaming video API platform Wurl. The API has a pretty robust example of Siren being used in the wild, allowing me to reverse engineer the design patterns and apply in my own way--this is one way I learn things, through breaking down other people's work...

Sometimes Open Data Just Needs That Human Touch

05 May 2015
I had a great conversation with Chris Taggart (@countculture), the CEO of OpenCorporates, after his keynote at APIDays Berlin / APIDays Europe 2015 last week, about how they get the data they need, to make the change they want to see in how we do business globally. Us technologists get excited about the potential around the ingestion of large data files published by companies and governments, and the scraping of data where we can. All of this is definitely be part of the open data lifecycle, but often times the whole open data thing, comes down to the human variable. Almost every open data project I've embarked on, always has a portion of the process which involves me rolling up my sleeve, and cleaning up, and validating of data--there is just no way around it...

Guest Post: Why The API Pattern Is Broken And How We Can Fix It

05 May 2015
Has Owen Rubel emailed you, commented on your thread, called you or your co-workers? Your not alone, feel free to contact me for more information. This a guest post by Owen Rubel, fellow API architect, and "master of api automation, creator of #iostate, #apichaining". I am working with Owen to better understand API Chaining, and how it can be applied in several projects I am working on. Owen was kind enough to craft this post, to better help me understand is vision, as well as share with my audience. If you want to find out more about Owen, you can follow him on Twiiter @OwenRubel, and visit his Github repository for the more technical side of his work. In the early days of API development, the concept of the API was simple...

The Legal Side of Healthcare APIs

04 May 2015
I was taking a look at a new healthcare API recently, adding it to my stack, for deeper review at a later date. Whenever I add a company to my monitoring and review system, I go through the site to make sure they have some of the characteristics of a modern API. I am not interested in many of the APIs that I come across that are older web services, or just poorly done APIs. I want to make sure APIs have self-service registration, some web API characteristics, code libraries, support, and a minimum viable set of building blocks. The API I was looking at is Validic, which bills itself as a "Digital Health Platform". I'm coming across a number of new API driven, healthcare platforms, like Validic lately...

A Review of The CallFire Communication Platform

03 May 2015
Swagger is now Open API Definition Format (OADF) -- READ MORE This is a review of the communication API platform CallFire, crafting a snapshot of platform operations, from an external viewpoint, providing the CallFire platform team with a fresh take on their API from the outside-in. The criteria applied in this review is gathered from looking at the API operations across thousands of API providers, and aggregating best practices, into a single, distilled review process. This review has been commissioned by CallFire, but as anyone who's paid me for a review knows, money doesn't equal a favorable review—I tell it like I see it. My objective is to help CallFire see their platform through a different sense, as developers might see their platform...

I Will See You In Barcelona Next Week For APIDays Mediterranea

29 April 2015
After recovering from an amazing week in Berlin for APIDaysBerlin / APIStrat Europe 2015, and catching up on some work, which included a 20 hour push to get the last weeks API.Report completed, I am now preparing for API Days Mediterranea, May 6th & 7th in Barcelona, Spain. The event is billed as "The Independent Conference on APIs, NLP, and Language Technology", and brings together may of the leading API minds, but also the cross-over with APIs and language technology--something you won't see anywhere else. While the main event is next Wednesday and Thursday, things kick off the night before, on Tuesday, May 5th with some pre-conference workshops and partying at 3Scales office: 17:30 - Practical 3scale API Management Crash Course at 3scale's office (register) 19:00 - API Meetup Barcelona: Marketing APIs: Do's and Dont's and APIdays warm-up party at 3scale's office (register) Then starting Wednesday, the main event kicks off with many of the usual suspects, who don't just lead in the API industry, but also work very hard traveling the world evangelizing API best practices: Mike Amundsen (@mamund), CA Technologies - From Stacia to Hyperion and Back Again: A Hypermedia Hero's Tale Steve Klabnik (@steveklabnik), Hypermedia Evangelist - JSON API: your anti-bikeshedding weapon Bruno Pedro (@bpedro), Redbooth & API Changelog - How to Automate API Discovery Andy Thurai (@andythurai), IBM - Machine Learning with IBM Watson and Alchemy API Tyler Singletary (@harmophone), Klout - Topics as an Engine For Insights Tony Blank (@thetonyblank), Context...

The Technology, Business, and Politics of APIs Via A Community Driven API Life Cycle

29 April 2015
In 2010 I started API Evangelist, as part of my effort to better understand the world of APIs. I was looking to not just the technology of how it was done, I saw there were plenty of people doing this. I wanted to better understand the business of APIs, and how popular APIs were finding success with their business models, developer outreach, and other aspects of API operations--going well beyond just the technology. API Evangelist started simply as a blog. I was not a big fan of WordPress, as I knew it can be quite a security target, and as a platform, for a programmer like me, can be more difficult to get even the simple things done. With this in mind I started the first API Evangelist API, by following the same advice that I would be giving to my potential audience...

Thank You Berlin For Helping Make APIDaysBerlin / APIStrat Europe So Amazing!

27 April 2015
I am still coming off the high that was @APIDaysBerlin / @APIStrat Europe this last April 23rd through 25th in Berlin. There were a number of talks that I enjoyed, ranging from open data, to 3D printing, to hypermedia--too many to list. I love the German view of technology, data privacy, and generally on what is going on in the United States. Other than the wifi issues, the conference was a success. We sold out the event, with 450 people in attendance (goal was 400), and even with the final day being on a Saturday, the turnout was very impressive. Each session I ran, was full of questions, with an IoT session, and another architecture session running 10 minutes over, because there were so many good questions, I didn't want to stop...

My Open Data Panel At APIDaysBerlin and APIStrat This Friday In Berlin

21 April 2015
In addition to helping be the MC for the API event, one of the conversation I am facilitating at @APIDaysBerlin / @APIStrat Europe this Friday in Berlin, is an open data discussion on the main stage. What better place to discuss the world of open data and API, then in Germany. The country has some of the strictest laws when it comes to protecting the privacy of German citizens, and when it comes to API access to data, I couldn't think of a better place to have an open discussion in 2015. I have invited two data specialists to the stage Friday afternoon: Ali Jelveh (@jelveh), CEO & Founder Protonet GmbH and Free Your Data -  Ali Jelveh is Co-Founder and Chief Revolutionary Officer of Protonet...

Quantifying My Minimum Viable API Footprint Definition As Real API Portal

20 April 2015
I wrote a post the other day laying out what I'd consider a minimum viable footprint for API operations. My vision of just exactly what an API is, has gone beyond just the technical, ever since I started API Evangelist back in July of 2010. Early on I saw this was more than just about the API endpoints, and documentation, code samples, and many other building blocks were essential to the success (or failure) of any API platform, area, or ecosystem. This recent post was an attempt, here in 2015, to quantify what I would consider to be a minimum definition for API operation. After writing it I wanted to take another stab at actually creating a portal, that would stand up to the API rhetoric that I regularly produce...

Quantifying A Minimum Viable API Footprint Definition As Real APIs.json Driven Portal

20 April 2015
I wrote a post the other day laying out what I'd consider a minimum viable footprint for API operations. My vision of just exactly what an API is, has gone beyond just the technical, ever since I started API Evangelist back in July of 2010. Early on I saw this was more than just about the API endpoints, and documentation, code samples, and many other building blocks were essential to the success (or failure) of any API platform, area, or ecosystem. This recent post was an attempt, here in 2015, to quantify what I would consider to be a minimum definition for API operation. After writing it I wanted to take another stab at actually creating a portal, that would stand up to the API rhetoric that I regularly produce...

Exploring The Ways Can We Put API Driven Tools Like Known To Work

17 April 2015
I see a lot of software come and go. I adopt applications, tools, and online services for a variety of reasons, with some of these tools remaining a regular part my operations, with others coming and going with time. I'm currently abandoning Evernote, in favor of my own home brew note tool, while I'm also adopting a handful of new HTTP Client tools like Paw. There are a number of reasons these tools go away, sometimes the reason I needed them shifts, other times they evolve to a point where they are no longer useful to me, and other times they go away after an acquisition, or running out of money, and not being able to keep the lights on. In the end, when i find tools I believe in, and deeply integrate them into my life, and want to better understand how I can help ensure they will be successful...

If Government Faces Technical Hurdles When Meeting Open Data Requirements, We Need to Lean On Vendors For Solutions

17 April 2015
I was reading Obama administration agrees with Sunlight: Agencies should disclose what data they keep private, which is a topic I follow closely, as I'm passionate about government opening up their data inventory, but also because worked as a Presidential Innovation Fellow on helping agencies open up their data. I completely agree that agencies should have to disclose lists of even their private enterprise data repository, to help establish a clear picture of just exactly what is public or private government data. While reading the post, I noticed the statement that, "most agencies seem to have accepted and understood the need for this change, but some concerns have been voiced": The Department of Commerce, which holds a very sizable amount of data, has cited “certain technological issues that are creating major barriers to creating the PDL as described [in OMB’s guidance]...

Thinking Through How We Handle The Internet of Things Data Exhaust, And Responsible API Monetization, With Carvoyant

17 April 2015
I'm very fortunate to be the API Evangelist, as I get to spend my days discussing, some very lofty ideas, with extremely smart and entrepreneurial folks from across many different business sectors. An ongoing conversation I have going on with Bret Tobey (@batobey), the CEO of Carvoyant, is around the big data generated around the Internet of Things. Many companies that I engage with are very closed about their big data operations, where Carvoyant is the opposite, they want to openly discuss, and figure it out as a community, out in the open--something I fully support. In reality, the Internet of Things (IoT) is less about devices, than it is about the data that is produced. If someone is exclusively focusing on the device as part of their pitch, it is mostly likely they are trying to distract you from the data being generated, because they are looking to monetize the IoT data exhaust for themselves...

A Healthy API Strategy Does Not Involve Scheduling A Briefing To Discuss--Just Do It

17 April 2015
I get a number of folks contacting me about their API ideas, and email or call me, looking to schedule a meeting or briefing to discuss the API ideas. This is something I always reply with a request for existing links to the portal, blog, Twitter, and Github accounts of those involved. Even when companies are doing something interesting, I prefer to approach it like any random Joe or Jane would, from the public portal, with very little information up-front. Your overall approach to API, the value it delivers, and ease of integration should speak for itself, in my opinion. I am sure there are plenty of companies still who would prefer a briefing, meeting, call, or other personal touch, sales or pitch like engagement, but increasingly in an API driven world, a self-service, pull approach is preferred...

Preparing Postman Collections Ahead Of Time For Developers Like JustGiving Does

16 April 2015
I have been slowly adding Postman Collections to many of the APIs indexes for my new master stack. I index each API using an APIs.json file, as well as provide a master APIs.json which brings together all of the APIs, into the single portal I've published to Github. Within some of the APIs, you will see a Postman icon, allowing you to easily import the API definition into postman, directly from each APIs landing page. When I first published that I was publishing these Postman collections on my Alpha API Evangelist blog, someone from the donation API platform Just Giving said they also prepare Postman collections for their developers, and publish them to Github for their API consumers:  At JustGiving we give our API consumers a set of collections to import to make their jobs even easier, we also use the "Environments" feature to substitute different values depending on whether you're using our Sandbox or Production environment - it's a real time saver and also helps when supporting our API consumers...

On Twitter, Gnip, DataSift, And Making The Hard Platform Decision

16 April 2015
I have had Steve Willmotts of 3Scale's response to the announcement that Twitter was cutting off firehose access for over a week now, and bringing the higher level access completely in house via their Gnip acquisition. You can read the response from Gnip via their blog post Working Directly With the Twitter Data Ecosystem, and from DataSift in their The Twitter/Gnip Gap: Data Licensing vs Data Processing. Steve and I are in agreement with the points made via his How Not to be a Platform: Twitter’s Firehose Mistake post. Where I really struggled with over the last week, in producing a official response, was after responding How To Be A Platform: Making Tough Partnership Choices, from my friend Tyler Singletary...

Hypermedia APIs From Sébastien Cevey of The Guardian at @APIDaysBerlin / @APIStrat Next Week

14 April 2015
The most important stories told across the API space, the ones that have the biggest impact on API providers, and ultimately API consumers, are the stories that come out of the trenches of the API operations at the leading public API providers. This is why 3Scale and API Evangelist started APIStrat, and what the audiences over the last 3 years of operating APIDays and APIStrat have consistently requested--more stories from the trenches. With this in mind, we've asked Sébastien Cevey (@theefer) of The Guardian to come to @APIDaysBerlin / @APIStrat Europe 2015, and share a story from API operations at the worlds leading media API provider. Sébastien wanted to share their view of what Hypermedia APIs are, by comparing them to a classical RPC architecture and ad-hoc "JSON APIs"...

Hypermedia APIs From Sebastien Cevey of The Guardian at APIDaysBerlin / APIStrat Next Week

14 April 2015
The most important stories told across the API space, the ones that have the biggest impact on API providers, and ultimately API consumers, are the stories that come out of the trenches of the API operations at the leading public API providers. This is why 3Scale and API Evangelist started APIStrat, and what the audiences over the last 3 years of operating APIDays and APIStrat have consistently requested--more stories from the trenches. With this in mind, we've asked Sébastien Cevey (@theefer) of The Guardian to come to @APIDaysBerlin / @APIStrat Europe 2015, and share a story from API operations at the worlds leading media API provider. Sébastien wanted to share their view of what Hypermedia APIs are, by comparing them to a classical RPC architecture and ad-hoc "JSON APIs"...

Bridging Our Virtual and Physical Worlds With The Link Creation Studio

10 April 2015
APIs are very much a virtual concept, something that is very abstract, often difficult to explain, and is something that very much lives in the online world. Spending much of my daily life in this world, I’m always excited to come across APIs that bridge this digital world, with our existing physical worlds. At first read, you might think I’m talking about the recent growth of Internet of Things APIs, that are connecting physical devices like our thermostats and smoke alarms, to our mobile devices, using APIs. This is part of it, but for this post I’m referencing APIs that don’t just connect to objects in our physical world, but they actually bind to existing experiences, processes, and other aspects of our personal and professional worlds...

On APIs and Microservices

10 April 2015
I've been monitoring an emerging slice of the API, that has been dubbed "microservices" for some time now, and you've even heard me explore its use, when describing my architectural approach to redesigning more core API stack for my internal systems. I’m slowly redesigning my internal API stack, keeping them as small as possible, throughout all aspects of operations, deploying each endpoint in a single dockerized container, that contains the OS, database, web server and all server side API code. I'm also using Github, in conjunction with APIs.json to assist me in my orchestration, throughout every aspect of these APIs lifecycle from design to testing—all a new approach for me when managing my APIs...

How Not To Onboard With Your API: Fiber Locator API

10 April 2015
Somewhere during my weekly monitoring I found the Fiber Locator API, which like all APIs, especially the ones that ask me to “request access”, I signed up for the service. Understanding where telecommunications companies have laid fiber optic cable, for me, equals a potentially valuable API resource—sure I would consider integrating these resources into my applications, and systems. I’m never a big fan of APIs, who make you request access vs self-service registration, but if the API has value, I jump through hoops, so I can can better understand what an API does, which according to the Fiber Locator site: FiberLocator offers an application programming interface that gives you access to our database of over 265+ carriers, over 272,000 carrier lit buildings locations and 3,000+ data centers...

My Minimum Viable API Footprint Definition

10 April 2015
This is something I talk about often, but it has been a while since I’ve done a story dedicated to it, so I wanted to make sure and take a fresh look at what I’d consider to be a minimum viable footprint for any API—I don’t care if it is public or not. This definition has grown out of five years of monitoring the approach taken by leading API providers, and is also baked into what I’d consider to be a minimum viable APIs.json definition—which provides an important index for API operations. What do I want to see when I visit a developer area? More importantly, what does your average developer, or API consumer need when they land on your API portal? Let’s look at the basics: Portal - A clean, easily accessible, prominently place portal landing page...

Opportunities In The Long Tail Of API Deployment For Non-Developers, Using Kimono Labs

09 April 2015
I was just doing on of my regular check-ins with Pratap Ranade (@pratapranade), the CEO of Kimono. We try to make time to catchup on what each other are up to, and find where we can work together to incite API evolution. Pratap sees the space like I do, that APIs are more than tech, possessing huge potential when it comes to empowering folks to make change within their companies, organizations, institutions, government agencies, and the wider industries and countries they exist in. Unfortunately I can’t go into too much detail about the projects we are working on until they are ready, but I just spend over an hour talking through some pretty interesting use cases that have occurred via Kimono Labs, in which Kimono users are scraping data and content from existing websites, and crafting some pretty interesting APIs...

Here We Go Again, SOA And API - We Have Already Done This!

09 April 2015
This is another story that came to mind while listening to the last episode of Traffic and Weather. As John and Steve were talking about the API definition format Swagger switching from Reverb to SmartBear (thanks for shout-out about my Swagger post), they were discussing how Microsoft is using Swagger as part of platform operations, and made sure and reminded us listeners that all this has been done before. Bringing up a never-ending theme  in the world of APIs, that we just can't seem to shake loose. When people bring this up, what do they mean? Yes, modern API definitions like Swagger, are very much like earlier incarnations of WSDL and WADL. Ok. What now? We shouldn’t do it? It won’t work? Don’t even bother with Swagger? We should learn from history, and earlier efforts, and make sure we don't same mistakes? We should be scared of Swagger, and run for the hills, hide in a bunker? We should all switch back to SOAP and use WSDL? You just like to tell me I'm wrong, and has nothing to do with technology? Why I bring this up, is because more often than not, most of these conversation lean towards the first response — don’t even bother, except you don’t really know because people who state “we’ve already done this”, often leave it open ended, offering no constructive criticism...

Working Toward An API Definition Driven, SEO, and Section 508 Compliant API Documentation Interface

09 April 2015
This is a topic I’ve had an increasing number of conversation with folks about in the last couple months, and a friend of mine Tweeted in response to today, resulting in this lovely rant. This is about two very separate problems, in which the solutions are what I'd consider significantly overlapped. I’m talking about the need to make sure the valuable metadata, as well as underlying resources made available via an API is accessible to search engines, while also making sure the it is all Section 508 compliant, providing critical access to people with disabilities. In response to my recent post, on "Why The New API Blueprint Sharing Button From Apiary Is So Important”, said: I'm heavy user of @apiaryio but disappointed with discoverability features of the product...

Auto-Generating Code Using Swagger Still Means You Will Get Your Hands Dirty

09 April 2015
Yay! Another story generated by listening to Traffic and Weather (blame John and Steve). I do enjoy sharing my random thoughts while listening to those two. This one is around the SDK discussion during the latest episode, but as they noted, they’ve talked about SDKs a lot in the past. This particular reference was again, during the their discussion about Microsoft using Swagger to generate code—a topic which brought up the usual grumbles from John about SDKs. He loves to hate on SDKs, obviously suffering from severe SDK PTSD. I agree with his feelings about SDKs, they are well founded, but auto-generating code from Swagger doesn’t always involve with the generation of full-blown SDKs...

The Work It Takes To Connect And Keep Up With Each Valuable API I Come Across

08 April 2015
If I find a new company during my research, it takes me about a minimum of 15 minutes to lightly profile what they are up, and add to my system, and if I do a full profile, it can take several hours. All of this adds up to a lot of work, time that would be better spent on actually writing stories, hacking on the APIs, and publishing of the longer form research papers on what I’m seeing. In an ideal world, each of these APIs would have an APIs.json in the root of their domain, with details about the company and people responsible for API operations, and as much information about each API as possible. With a single click, I could import the entire profile of a company, and its valuable API resources into my monitoring system, ready for publishing to relevant areas of the API Evangelist network, as well as some of my partner sites like APIs...

What Are Good Example Of API Deprecation Policies

08 April 2015
I had one of my followers ask me if there as a “gold standard for API deprecation policies” out there. I’d say that deprecation policies are a little different than some of the other legal building blocks of an API, where the legal is a small portion of it, with the majority really being all about communication. To answer the question, I recommended Google. Not cause their deprecation policy itself is all the great, it is just because their overall approach to API deprecation is pretty robust—something I’m sure is derived from their experience so far. (wink wink) API deprecation at Google starts with some pretty clearly stated policies, but goes much further with: Deprecation Policy Deprecation Schedule Data Deprecation Details Blog Communication These are just a handful of the building blocks that Google employs as part of their approach to API documentation...

A Little Standardization Around How We Do Internet of Things (IoT) APIs And Developer Portals Could Go a Long Ways

08 April 2015
I was dedicating some time to researching APIs in the Internet of things (IoT) space, and stumbled across the Myfox API, serving the Myfox home security products. While the developer portal for the Myfox API doesn't have everything I'd like to see in an IoT developer portal, it is one of the better one's I've seen. If you think web or mobile app developers suck at providing a simple, and a coherent developer portal and experience, device platform providers are even worse. The Myfox API, has the essential building building blocks, with a simple overview, authentication info, simple Swagger driven API documentation, application management tools, and a clear terms of service for the platform. Additionally, there is a clear link between the primary Myfox website, the developer portal, and a myfox...

Considering The 3D Robotics Drone API As Potential Blueprint For The Drone Industry

08 April 2015
As my Internet of Things (IoT) research continues, I’m applying much of my API thinking from the mainstream API space to the world of IoT. A couple weeks ago I stumbled across the 3D Robotics Drone API, which to my surprise, was documented using a Swagger specification, providing a machine readable definition of the API, which helped me quickly get up to speed on what the Drone API delivers. I haven't put much thought into the detail for any drone APIs, something that has been adjacent to my mainstream research for over a year now, but I did have some basic opinions about what a drone API could have. So, when it comes to potential resources, I have to say the 3D Robotics Drone API delivers in all earlier areas I had been considering--with five main endpoints: The Vehicle API - Exposes operations for browsing and searching lists of vehicle, and retrieving single vehicle, including airspeed, ground speed, and battery...

Encouraging Feedback By Thinking Through Your API Road Map, Out In The Open, On Your Blog

08 April 2015
This story is derived from listening to the API podcast, Traffic and Weather. One of the things John Sheehan (@johnsheehan), and Steve Marx (@smarx) discussed during the recent show, was a post Steve wrote as part of his role as product manager, called "How many HTTP status codes should your API use"? I think the story is extremely useful to read, helping us all think through how we use HTTP status codes in our own platform, but personally I think the real story, is Dropbox talking out loud about their strategy. John and Steve pointed out on the podcast that someone had tweeted that the story was not in sync with the way Dropbox actually did their HTTP status codes. To which Steve replied, that is why he wrote the story, to talk it out, and solicit feedback...

Combined Calls: Monetization Through The Bundling Of API Calls

07 April 2015

Why The New API Blueprint Sharing Button From Apiary Is So Important

07 April 2015
API design service provider Apiary, quietly launch a new sharing button for API Blueprints, in their interactive API documentation, the other week. They added a setting in their account area, which allows users to be more open with their API designs: "Start sharing your API blueprint with other API enthusiasts, by enabling this feature within your API settings. Simply toggle the ‘Public Blueprint’ setting on and you’re ready to start sharing your API blueprint.” also stating that, “this is just the beginning of being able to socialize and learn from other public API blueprints." Now we you are visiting the Apiary driven API documentation for common platforms like: Akamai Imaging API Relayr Definition API Loader...

Where You Will Find Me Next: Berlin, Barcelona, and Broomfield

07 April 2015
I’ve been fortunate enough to be able to cut back on my travel in 2015, and focus on some important research, coding, and writing. I apologize to all the events I’ve said no to over the last couple months, but I hit a wall last year with speaking, and trying hard to make 2015 a much more healthier, and balanced year. With that said, here is where you can find me this spring. I have three places you can find me in April and May: Berlin, Germany - You can find me in Berlin, putting on @APIDays / @APIStrat, April 24th & 25th Barcelona, Catalonia - I will be speaking at APIDays Mediterranea, May 6th & 7th, in Barcelona Broomfield, CO @APIStrat Tech Un-Workshops @ Gluecon May 19th (1:00-5:00 PM) Leading the Swagger conversation at Swagger API Meetup @ Gluecon May 19th (7:00-9:00 PM) Gluecon - I will be at Gluecon 2015, May 20th, and 21st, speaking That is all the speaking I’m doing this spring, with one tentative date early in June at BYU...

I Wish API Providers Published Their Developer Portals On Github So I Could Submit Pull Requests

07 April 2015
I spend a lot of time looking through the developer portals of API providers. I see a lot of things, both the good and bad, while navigating these portals, and while some of the bad stuff I see are way too big for me to doing anything, there are many little things I see that I could help do something about. Sometimes it is just spelling mistakes, sometimes broken links, and other times I want to rewrite API descriptions, and add to the resources that are available for an API. During these travels, I got to thinking...what if API providers published their developer portals to Github? Just like I do with my API Evangelist sites. Then I could fork their portal, and submit pull requests with rewrites of the description of what your API does, adding little tweaks, here and there, helping polish the portal--potentially making things easier for developers...

API Streaming: Cache And Push Data From APIs Using StreamData.io

02 April 2015
I was introduced to StreamData.io the other day, by Gabriel Dillon (@gjdillon) of Readme.io. StreamData.io provides a caching, and push layer for apps to take advantage of, that can be deploy on top of existing APIs. I haven’t implemented StreamData.io yet, I am still evaluating it, and at first glance it looks like an interesting new real-time layer, that you can use on top of APIs, to improve application performance and user experience. I’m going to add StreamData.io to my real-time research right now, however once I start playing with I may add as an API deployment resource as well. I have some verification to do, but I’d love to test out the potential for StreamData.io to deliver cache and sync layer for common APIs, doing for APIs, what StreamData...

Blockspring Shifts The API Client Conversation With Their Google Spreadsheet API Add-On

02 April 2015
The one thing I've learned in five years as the API Evangelist is that us technologists and developers don't always see the world like everyone else. We focus on the perfection of the technology, our own desires for the future, and often miss the mark on what end-users actually need. This is one of the hallmark success of APIs over SOA, is that by accident, APIs jumped out of the SOA petri dish (thanks Daniel Jacobson - @daniel_jacobson), and was use solve everyday problems that end-users face, using the technology that is readily available (aka HTTP). While I think us API folks have done a great job of delivering valuable resources to mobile applications, and a decent enough job at delivering the same resources to web applications, and I guess we are figuring out the whole device thing? maybe? maybe not? Regardless, one area we have failed to serve a major aspect of the business world, is delivering valuable API resources to the number #2 client in the world—the spreadsheet...

Temp API Keys: Leave Them Laying Around The Web Where Devs Will Find Them

31 March 2015
I was reading Are You Or Your Customers Leaking Your API Keys? from Daryl Miller (@darrel_miller) the other day, which spurred me to float up a story in my Evernote, from a couple months back. My thoughts are only related to Daryll’s because it is about API keys, and their accessibility—the similarities stop there. Daryl is talking about a very different layer of key management, which we should all be thinking deeply about. API key management is an API provider issue, as much as it is an API consumer issue. As an API provider I need to have an easy way to manage all the keys I provide to developers. As an API consumer, I need to have an easy to manage all the API keys I get across the API providers that I depend on...

Amazon Echo: Voice Enablement Will Be Major API Driven Channel In The Future

30 March 2015
I've been tracking on the potential for voice APIs since Siri was first announced, a topic that often meant telephony like from Twilio, or audio transcription from Popup Archive and Clarify. When I close my eyes and think about the the future of APIs and voice enablement, it is more akin to the Siri example, where the digital world is (supposedly) just a voice command away. Imagine making all your employee directory, company calendar, or product catalog available via voice commands. How do you do this? You do it with APIs, and a voice enablement platform in-between the application developers, and the available API resources. Much like all other voice enablement, I think we have a huge amount of work to get anywhere close to the pictures we all have in our head, when if comes to voice enablement...

Quantifying The Community Around The Swagger API Specification

30 March 2015
This post is extracted from a deep dive I've been doing into the Swagger ecosystem, as part of regular conversations I have been having with Tony Tam (@fehguy), trying to understand how we can better tell stories about Swagger. I've been tuned into things for a while now around the Swagger community, and there is a lot going on, but from the outside, some of this can be hard to see. Seeking a better understand what is the Swagger community, I wanted to take a walk through the sites, forum, and Github repositories. First let’s start with the basics, what is Swagger? Merriam Webster defines Swaggers as: : to walk in a very confident way : to walk with a swagger. ;-) Seriously though, Swagger is a machine readable format (either JSON or YAML), for describing an API, providing a description of API operations, in a way that other applications can read, and understand...

Even More Pondering On My Microservice Definition

28 March 2015
I am evolving my own personal microservices definition, something that is constantly changing, as I work on my infrastructure, read other people’s own definitions (no shortage these lately), and continuing having conversations with smart folks across the space. I had the pleasure of having Mike Amundsen over the other night for dinner, and after having some interesting discussions about community, and potential micro services design, I’m adding a couple of elements to my microservice definition list. In my last post on this, I listed seven criteria I congress as part of my micro services definition: minimal surface minimal on disk minimal compute minimal message minimal network minimal time to rebuild minimal time to throw away I wanted to add two elements to my list, considering some of the other elements I’ve noticed at play when it comes to API bloat: minimal ownership minimal dependencies Minimal owners is a pretty easy one for me, as I’m the owner of all my microservices—the buck always stops with me...

WhatsApps Reason For Not Opening Up API Is Just Not Informed And Short-Sighted

27 March 2015
There was a quick post from Mashable the other day about a conversation with WhatsApp cofounder Brian Acton, called WhatsApp cofounder: Sorry developers, no API for you. Its pretty common argument you hear from business leaders, regarding why they won’t open up APIs. It has been a while since I railed on this line of thinking, so I am taking the opportunity to share why this is such an un-informed, short-sighted view of APIs. I wasn’t at the conference, so I a completely dependent on Mashable for this, but apparently someone in the audience asked: "We have done a lot of transactional messaging using traditional email and SMS, and we've recently moved into the international market," the engineer explained to the audience, who clapped and hollered...

Politics of APIs: Talk Of API Driven Regulation Is Increasing

27 March 2015
When I started API Evangelist, I was all about the Business of APIs, something I still focus on, but increasingly over the last couple years I am focusing more on what I call the politics of APIs. In my opinion, the politics of APIs can be anything from terms of service and privacy policies, to rate limits, pricing, and security, all the way up to court cases, patents, and government regulation. Today I want to focus on the very top of that spectrum—government regulation. The government isn't just getting into the API game, by deploying their own APIs, they are going to also increasingly be getting more involved with private sector APIs. In my weekly monitoring I'm seeing more chatter across several industries, like the UK treasury getting involved in banking API standards, and a push in the healthcare industry for more interoperability via APIs--just to highlight two recent stories...

With The Addition Of The DroneKit API, I Am Now Tracking On The World Of Drone APIs

27 March 2015
There are many areas I track on as part of my research. Things that do not show up on my weekly API.Reports, or in my analysis on API Evangelist. One of these is the area of drones. I’m fascinated by this potential area in the area of Internet of Things, but until now it was more of a side note, or one possible path for APIs and the Internet of Things. Amongst the numerous drone stories I curate, I'm seeing more shift in the space towards a developer focus. It isn't just about the drone itself, its about customizing, developing and using the drone as a platform. One recent story I noticed was 3D Robotics (3DR), one of North America's largest consumer drone manufacturer, announcing the release of a new DroneKit, which includes an API for drone app development...

How Do You Make Something, Something, The API Edition

27 March 2015
After reflecting on API management and the Apigee IPO, I’m thinking deeper on how the API space has come to be a “thing". To kick off this story, you have to start with the API itself, something very abstract, hard to see, let alone convey to the average person. A single API is difficult to quantify, let alone an entire sector, or the companies rising up to service this perceived sector—think of the argument from early API management service providers like Mashery, 3Scale, and Apigee had to make to their VCs. Don’t get me wrong, the API space has always been a “thing” to me, but along the road from 2010-2015, there has been plenty times, where I question the way things are...

Swagger Shifts Hands From Reverb to SmartBear

26 March 2015
The news came out yesterday that SmartBear was taking over ownership of Swagger, from Reverb. Swagger has been outgrowing its home at Reverb for some time now, becoming much more than I think even Tony originally imagined. You can find the official announcement from SmartBear on their site, and Tony’s thoughts over on the Reverb blog. No need for me to recap, but I did want to provide some of my personal thoughts on the shift in this very important project. I feel like we are embarking on the next stage in the evolution of Swagger. Over the last couple of years, the Swagger community has see growth, adoption, and investment at an unprecedented pace, culminating in version 2.0 of the spec and now its transfer SmartBear...

Reflecting On API Management And The Apigee IPO

24 March 2015
It has been a little over three years since I published my first roundup of API management providers. I’ve been tracking on this new breed of companies long before I started API Evangelist, but in 2011 I started formalizing how I monitored what these companies were up to. In 2015, I now track on over 35 API management service providers, offering everything from simple proxies, to the full API management infrastructure stack you get from 3Scale. I have met most of the API management providers, and after 5 years of covering them, it is no secret I have my favorites (you know who you are ;-). The business side of being an API management service provider has never really excited me, so I tend to stay away from the investment and acquisition stories, or speculating to much on who is winning the cash game...

Overcoming API Rate Limits Like They Did With WebhookDB

20 March 2015
I was listening to too infrequent Traffic and Weather API podcast today, and one of the topics John and Steve covered was an interesting approach to API consumption, and getting past API rate limits, with WebhookDB. I agree with John, that WebhookDB is pretty clever, and represents what I'd consider classic API developer ingenuity, when it comes to getting access to the resources they need. I’d have to give this one to my friend and API adversary Tyler Singletary (@harmophone), when he says rate limits stimulate developer creativity. +1 Tyler. So, what does WebhookDB do? ...allows you to replicate Github's database over HTTP using webhooks. It's useful if you want to treat Github's APIs as a database, querying over pull requests and issues...

An API Has No Value Until It Is Actually Used

20 March 2015
I am putting a lot of thought into the value of an API request and response lately. I've talked about the potential of a Postman collection as a unit of measurement, for the API economy. I’m also spending time breaking down the monetization strategies of the 700+ companies I track on, but I’m really looking to get beyond just the API pricing, and actually measure any evidence of real value that I can. This particular post is born out of a conversation with John Sheehan (@johnsheehan), CEO of Runscope, while we were in Sydney Australia last month for API Days Sydney. John had mentioned that when people asked him which are the best APIs out there, he replies “none of them, until they are used”...

Bringing My IT Infrastructure Out Of The Shadows With An API-First Approach

20 March 2015
I'm slowly migrating my own infrastructure, towards a microservice first approach, something you can follow the details of on my alpha.apievangelist.com blog. I've been running on my own custom brew content management system (CMS) since I started API Evangelist in 2010. There are many APIs in use across my system, both external publicly available APIs like Twitter and Crunchbase, and a wide variety of internal APIs I've developed myself. As I work to replicate each aspect of my CMS, carving off each potential micro service, I'm reminded of how much of what I do lives in the shadows. Little scripts I've written here, and there, jobs I haven't run in months, and just general code exhaust from years of operation...

APIs.json As A Distributed Transport Layer For The API Economy

18 March 2015
I'm working with multiple partners to define what I’d consider to be the firsts stops along the API lifecycle, when you use APIs.json as the scaffolding for your API operations. APIs.json is a machine readable format for indexing APIs, that exist under a specific website domain, or are part of a aggregate collection designed for a specific project or objective. To help me, and the folks I’m working with to better see the API lifecycle that APIs.json is enabling, I wanted to take a stroll through each of the stops along the API lifecycle, and think through the potential for additional formats, services, and tooling throughout the entire journey. I want to explore the possibilities for individual API providers, API consumers, as well as API service providers, and the aggregate level, where companies and individuals are delivering valuable tools and services to the overall space...

More Pondering On My Own Microservice Definition

17 March 2015
Like API, the term microservice has emerged as a force, along with a meaning that is very precise, or very broad, depending on who you are. The only thing I’m sure of at this point, is the term microservice is very personal, and means very different things to different people, depending on where you stand in the industry. Regardless I can't help but consider the implications of the term, internalize it, and see what value I can derive from its meaning in my own world. This exercise leaves me asking, what is a microservice? Over and over, acknowledging I may never fully know the meaning, and like API it will be more of a journey, then it never will be a destination. First and foremost in my world a microservice means simple, and small...

What We Do In The API Community Influences How The Rest of The World Is Making Change

17 March 2015
I was just talking with my friend Oliver Seiler (@0seiler) in New Zealand via email. Oliver is great at keeping me in tune with API related stories out of New Zealand. I was making sure he knew how much I appreciate people like him sending me regular updates, and that it is what makes API Evangelist go around—to which he replied, reminding of how important the work we are doing here in the US API space. Oliver told me what I hear a lot, "We still need to sell our story every single day and you wouldn't believe how much anything that comes from particularly you and 18F, but also ProgrammableWeb and GDS in the UK matters to our work." This isn't an isolated case, I hear this a lot from people I talk to in government, enterprises, and other institutions around then globe--the stories we tell are used to make change in how they think and potentially operate...

The API Journey: We Do Not Always Get Our API Strategy 100% Perfect, But We Can Communicate, Learn and Evolve

17 March 2015
Running the perfect API operation is pretty much a delusional dream. Even leaders  like Twilio and AWS have platform, and ecosystem produced problems on a regular basis. In my opinion, API are all about the journey, and we may never get our strategy 100% perfect, we can communicate, and evolve along the way—this is what I consider the API journey. To help demonstrate this in action, here a post from the GSA, about the SAM API, on the US Government API Forum: We've, rightfully, heard complaints about the SAM API languishing and the documentation not being as functional as it needs to be. We want to make sure users of the API feel comfortable using it to build real applications off of...

Get API Results Into A Google Spreadsheet By Pasting The Following Into A Cell

13 March 2015

The Enterprise Will Make The Same Mistakes With API And Microservices That They Did With SOA, Because Essential API Concepts Go Right Over Their Head

13 March 2015
I would say the enterprise space fleet has successfully shifted their course, heading in the general direction of everything API. SAP, Oracle, IBM, Microsoft, and the rest of the usual suspects have pledged their faith to APIs, mobile, and IoT, all in a very public way. For those of us who jumped off the SOA bandwagon a while back (getting on the API bandwagon, yeehaw), this can be amusing to watch, cause the API bandwagon is better y'know?. ;-) I sincerely hope that these large companies can make a shift towards an API way of life, or a microservice devops way of operating, or whatever the cool enterprise kids are calling it these days. Some companies will find success in these areas, while many, many others will just talk about it, and buy a wide range of vendor services that will help them talk about it—there will be a lot of money to be made (and spent)...

Postman Collections As Unit Of Measurement For Transactions In The API Economy

13 March 2015
I'm immersed in deep thoughts about the implications of machine readable API definitions like APIs.json, Swagger, and Postman Collections, which are being applied to APIs, in some very different, but overlapping, and complementary ways. Currently I’m working to define the overlap between APIs.json and Postman Collections, and how they work together. For me, any good API starts with a Swagger definition, or API Blueprint, which is the single, machine readable truth of what is the surface area of any API, which I consider fingerprint for what is possible with any API or micro service. Additionally when I am working with any API, or stack of APIs, I am using APis.json to organize them into a single coherent set of APIs, then rely on each APIs properties to point to essential resources like Swagger, terms of service, pricing, and anything else I feel is essential to operations...

Going Beyond Excel As A Data Source For API Deployment And Focusing On It As An API Client

13 March 2015
I've said it before, and I will say it again — Excel and spreadsheets will continue to be super critical for the growth of the API industry. There are an increasing number of solutions like APISpark for deploying and managing APIs using spreadsheets, something that will get easier over time, but so far I'm not seeing equal acknowledgment of the potential of Microsoft Excel as an API client. The majority of the world's data is locked up in spreadsheets, and CSV files. Something I learned during my short time in Washington DC, is that the API community is going to have to court the legions of data stewards who spend their days in spreadsheets at the companies, and government agencies around the world, if we are going to be successful...

Making The API Feedback Loop Machine Readable With APIs.json

13 March 2015
If you are following some of my recent stories, I’m heavily focused on APIs.json, as I work to organize my own stack of microservices, using APIs.son and Swagger. I’m working hard to define additional, machine readable layers to my microservices index that answer as many of the questions that I have about the microservices and APIs that I depend on. The first machine readable definition I include in any APIs.json collection I’m building is Swagger, which provides a JSON or YAML definition of the surface area for any microservice or API that I depend on. The second thing I put to work for my own APIs, is API Commons, which provides a JSON definition for the licensing of my APIs...

Transitory APIs: Intentionally Building APIs That Can Go Away At Anytime

12 March 2015
I use many types of APIs. Some are public APIs, operated by other people, and then there are the APIs I have designed, operate, and consume on my own. As I design, redesign, deploy, and manage my APIs, I'm in a fortunate place that I get to push the boundaries of API operations, without much of the friction of normal API platforms. I'm the only one providing and consuming many of my APIs, essentially running an API dictatorship. Over time I have built quite a few APIs that are still up, active, but nobody is using them. I have built them during some specific research, or to support a prototype, which once I was done with core work, I do not need the API to actually be alive and running. At some point in the future when I revisit the research, I may want to fire back up the APIs, but for now its ok if they are down, with a dormant Docker image, and server-side code living within its requisite Github repo...

Crafting Exactly The API Definition You Need With Swagger Vendor Extensions

12 March 2015
I was listening the APIs​Uncensored podcast last weekend, where Ole Lensmar (@olensmar), and Lorinda Brandon (@lindybrandon) sat down for a conversation with Tony Tam (@fehguy), the creator of API definition format Swagger. There are a lot of interesting API informational nuggets throughout the podcast, some of which I'll be writing about, but this one is about something Tony mentioned—called Swagger vendor extensions. I've been using Swagger for a while, and specifically Swagger 2.0 since its release, and Swagger vendor extensions was new thing to me—most likly user error. I don't ever sweat things I miss, because I consume so much information each day, things are bound to get past me...

Augmenting A Read Only API With AN External POST, PUT, And DELETE

11 March 2015
I am revisiting some work that I started when I was working in Washington DC as a Presidential Innovation Fellow(PIF). Actually there are several things going on here, a sort of perfect storm of API design thoughts. After reviewing hundreds of APIs, including APIs in the federal government, you start to want to either go mad, or start making changes to the API designs you are exposed to. This leads me to the other layer to this story, a common question I get regularly, regarding whether or not there are any write APIs in the federal government—meaning, can you POST, or PUT to a common government resources. Write APIs are important in government, and their scarcity reflect some of the systemic illnesses I feel exists in government IT...

A Glimpse At What I Am Imagining For API Driven Analysis, Visualization, And Beyond

11 March 2015
I came across an interesting piece of technology today while doing new curation for API.Report. RASON, an interesting approach to API driven analytics and potential UI and visualization, that kind of resembles what I have been envisioning for one possible future. The analytics tool is created by a company called Frontline Systems, and I’ll let them articulate what it is: RASON™ software is designed to make it much easier to create, test and deploy analytic models that use optimization, simulation, and data mining. RASON stands for Restful Analytic Solver™ Object Notation. RASON targets analytical professionals, excel power users, and web app developers, but here is where it gets over my head, "Problems you can solve with the RASON service include linear programming and mixed-integer programming problems, quadratic programming and second-order cone problems, nonlinear and global optimization problems, problems requiring genetic algorithm and tabu search methods -- from small to very large...

What is ALPS?

10 March 2015
I was watching an open thread around ALPS over at API Craft, something that is on my working list to better understand, apply more in my world, and tell the story all along the way. ALPS author, and API visionary (;-) Mike Amundsen (@mamund) responded to the thread with a nice overview, which I wantd to repost and share with you. So, what is ALPS? ALPS is not a runtime format like HTML or HAL ALPS is not a designtime format like RAML or Swagger ALPS is a Profile format for describing the bounded context of a service. ALPS can be used as source material for designtime formats like RAML, WADL, Swagger, WSDL, etc. on the server side. ALPS can also be used as source material for client-side frameworks like Ember...

An Outside-In Approach Will Play A Critical Role In Driving The API Economy

10 March 2015
I'm a big fan of private APIs, and all for keeping API access tailored to meaningful groups of users vs. just opening up data to the public, without first thinking critically about the possible pros and cons. With that said, I always encourage API providers to seriously consider the outside-in effect, when APIs are designed to be as accessible as possible, allowing unintended things to occur around your API resources. It isn't just about the developers who are directly working with your API, it is also the entire API industry, and service providers that serve it. A number of companies exist across the API space, providing valuable products, services, and tooling that is derived from one or many API platforms...

Visualize Your Cloud Presence Using Mohiomap

10 March 2015
There are lots of good visualization stories recently, or maybe I’m more focused on API driven visualizations. Who knows? This particular post is an API story because Mohiomap, the company at the center is using APIs to accomplish their “vision”, not because they have an API—which actually would be a nice way to pay it forward, but that is another story. Regardless, I think what Mohiomap is up to, is interesting on a lot of levels, bur primarily because in coming years we need to be able to better understand this new, cloud-based world we are creating for ourselves. Why am I blogging about this? Because Mohiomap is driven with APIs, and if done right, it can make a big difference in how we see our virtual selves, whether the business or brand personas we are crafting online, or our personal self that is spread across Twitter, Facebook, Dropbox, and other API driven platforms...

Targeting Some APIs In My Stack For House Cleaning And Maybe Some Design Iterations

10 March 2015
As I look through more APIs, and I don’t just play around in their developer portal, and look at documentation, I am actually get my hands dirty generating Swagger definitions, and authenticating and making calls to an API. There is no better way to get to know an API, that generating a Swagger definition, and integrating with it—something when done, you always walk away with a new perspective. Once I get more of the APIs profiled in my API Stack, I’m going to see if I can configure my API editor to let me iterate on other people’s API designs a little bit. As an API consumer, you don’t always get a voice in the design of the next version of an API, but with API definitions like Swagger and API Blueprint, you can actually make edits, and then share them back with a provider...

@Broadcom, I Am Going To Need Your Switches To Support Virtualized Containers So I Can Deploy My Own APIs Too

10 March 2015
While processing the news today over at API.Report, I came across a story about Broadcom delivering an API for managing their latest network infrastructure. The intersection of Software Defined Networking (SDN) and Application Programming Interface (API) is something I’m paying closer attention to lately. Hmmm. SDN + API = Brand New Bullshit Acronym? Meh. Onward, I just can’t slow down to care--{"packet keep moving"}. At the networking level, I’m hearing Broadcom making a classic API infrastructure argument, "With the OpenNSL software platform, Broadcom is publishing APIs that map Broadcom's Software Development Kit (SDK) to an open north bound interface, enabling the integration of new applications and the ability to optimize switch hardware platforms...

The API Journey Or What Is the Point of an API, By Tony Hirst (@psychemedia)

09 March 2015
Tony Hirst (@psychemedia) wrote an interesting story about what I would consider the API journey, which he called, “What’s The Point Of An API?”. I’m the first to call bullshit on the term API, which is more storytelling magic than it ever was technical, for me. In my opinion, the point of an API is rarely ever the actual technical implementation—sorry devs. ;-( The point of the API is the journey, for the API provider, and the API consumer (both dev and end-user). The point of the API is about the API provider reducing friction, when it comes to understanding, and put to work, valuable digital assets from data, content, to more programmatic, algorithmic elements like image filtering or video encoding, to more physical elements like a Nest thermostat, webcam access, or drone controls...

Postman Collections Will Take Your API Productivity To The Next Level

09 March 2015
If you are an API developer, it is likely you have used Postman, the simple tool for building, testing, and documenting your APIs. I have Postman open as a Google Chrome App, which allows me to make API calls as I’m designing, developing, and integrating with the APIs across my world. Something which opens up the response and requests of API calls that I’m making, giving me more insight into how things are actually working (or not). One of the key aspects of Postman, are the collections, which: A collection lets you group individual requests together. These requests can be further organized into sub-collections/folders to completely mirror your API. Requests can also store variations and responses when saved in a collection...

Ask The Stack When You Need API Support

09 March 2015
I was profiling the video sharing API Dailymotion the other day, going through their developer area and profiling their API operations. One of the things I do as part of the profiling of any company, is checkout how they execute their support. Dailymotion employs two very common building blocks for their platform support, including an API specific Twitter handle, and good ol fashion email—both pretty proven approaches. However Dailymotion also employs a third aspect to thier API support, by recommending you head over to Stack Overflow for some community support. Using Stack Overflow in this way is not that original, I see numerous API providers doing this, the part I found interesting was their reference to getting Dailymotion API support via Stack Overflow as, "ask the stack!" I like that, I think it reflects what Stack Overflow is to the API developer community, and was an elegant way to send API developers off your site, to get the support they need...

What Exactly Does Your API Do?

09 March 2015
A short, concise, portable description of what your API does, is one of the most critical building blocks of API management, and is essential to reducing friction when new users are on-boarding with any API. It can be easy to design, and populate your API developer portal from a perspective that is very much in the know. I do it all the time, structuring your portal to reach the widest possible audience can be hard—it is why I’m here! ;-) Here is a great example of providing all the right elements, but leaving out the essential detail that new API consumers will need. View the Dailymotion developer area, land on home page, and without clicking, tell me what Dailymotion does.   The portal has all the right moves, except it neglects to say anything about videos, or show a video picture...

Slowly Adding The People Layer To The API Evangelist Network

09 March 2015
I'm adding a new layer to my monitoring of the API space, what I consider to be the people layer of the API Evangelist network--the actual people who are executing on much of what I talk about, across my research, and storytelling. This is all born out of the network of people I already talk to regularly, to get the stories, and details for the research that I publish regularly. I have been tracking on many of the doers of the space for a while, behind the scenes, and this is just about exposing a select handful of individuals who can help you with some of the areas I discuss in my research and storytelling. Up until now, my research has been about showcasing: News Companies Tools All I’m doing now is exposing some of the people who are doing interesting things as well, and are open to being contacted about their work, and discuss how you can potentially tap their expertise to help you achieve your API objectives...

We Need An Open Library Of The Most Common Utility API Implementations

07 March 2015
I was spending time profiling APIs late last night while putting back a couple of IPAs. Yes this is what I do on a Friday night, you have a problem with that? Anyways, I was crafting Swagger definitions for the 7digital music APIs, and the I came across their territories API. "The Territories API serves data about countries that 7digital operates in, data about those counties, and a one or more languages with shop urls in each country”, something that I could see being pretty useful to developers when building music apps on top of the platform. There has been numerous APIs I’ve developed in the past, where the need for some supporting, utility APIs, such as a list of states, zip codes, counties, or other resources was called for...

A Breakdown Of My Dream APIs.json File

07 March 2015
I'm continuing my work, to help people understand what APIs.json is, and the varying ways that it can be put to use. My post the other week, breaking down Fitbits APIs.json file is a good example of where to get started, and as a follow-up I wanted to help further set the bar for what a minimum viable APIs.json looks like, and today, I am going in the other direction--toward my dream APis.json file. APIs.json starts with a basic set of descriptions for who you are, the API provider. Each header of an APIs.json file gives you a handful of parameters for describing who you are: name - your individual or company name, who is managing the APIs.json file. description - a description of your company and / or the API collection you are building...

My Ideal Profile Of Companies Who Are Doing Interesting Things With APIs

06 March 2015
When I come across a new company, during the course of my monitoring and information gathering across the API space, I enter them into my company API. Once a company is in there, and I’ve deemed it worthy enough for a closer look, I profile their operations. For my own organization, and in the spirit of transparency and collaboration, I wanted to breakdown what I mean by profiling. First I start with the basics: Name - The official name for any company or project. APis aren’t always clearly defined corporate entities. Description - A short, concise description of what a company does. You’d be surprised how hard this is. Logo - A clean, simple, medium resolution logo for company...

Three Ways I Am Putting APIs.json To Work

06 March 2015
I had a conversation with some folks who are building a wikipedia of API definitions the other day, looking to employ formats like Swagger, and APIs.json to make an open, authoritative directory of machine readable API designs—something I can get behind 100%. I can even contribute the 700+ APIs.json files, and the 250+ Swagger files I have generated as part of my research. When I have discussions about APIs.json folks, I always find it helpful to summarize the vision we have for the API discovery format, and described it in a short, concise way. This time around I was able to clarify the vision, in a way I hadn’t fully been able to articulate before. To help me remember what I said, I wanted to capture it here on the blog...

My API Discovery Research

06 March 2015
I am giving each of my primary API research sites a refresh, and first up is the home page of my API discovery research. As I update each home page, I'm going to publish here on API Evangelist to help bring more awareness to each of the main areas I'm studying. This is one of my API research sites, focused specifically on API discovery. My name is Kin Lane, and I am the API Evangelist, working as hard as I can to understand the world of the Application Programming Interfaces, widely called an API. This network of API research projects all run on Github, and is my real-time workbench, which means there is a lot of finished work present, but occasionally you will also come across areas projects that are unfinished--you have stumbled in my API discovery research, you will find the main API Evangelist site over here, with other links to my work...

Launching A Data Visualization API Into Your Own Infrastructure With Lightning

05 March 2015
I was reviewing one of the many entries in my review queue of companies who are doing interesting things with APIs, and stumbled across the data visualization API—Lightning. Their implementation grabs my attention on several fronts, but their focus on delivering their API within your own infrastructure via a Heroku button, is one of the most relevant aspects. This approach reflects a seismic shift occurring in how we deploy APIs, and how we deploy architecture overall. You need a data visualization API, let me deploy my API into your cloud, or on-premise infrastructure using popular approaches to virtualization—developers do not need to go to the API, the API will now come to you, and live within your existing infrastructure stack...

API Evangelist Call Thursday Summary For March 5th, 2015

05 March 2015
I work to isolate all of my calls on Thursdays, leaving other days of the week to more asynchronous forms of communication, and deep dives into coding, research, and storytelling efforts. Last Thursday was interesting, but this weeks conversations has spurred me to summarize some of the conversations that occurred on this busy day. This isn't something I'll do every thursday, and not all conversations will make it in, but I figured it would help me process, as well as share some insight into the types of conversations I'm having being the scene. Here is a breakdown of the conversations I’ve had today, anonymized to protect the lives of those involved: API Evangelist at Major Media Company - I usually dodge recruiter calls early on in the process, but this one got through because it came in as a referral from someone I knew...

Making Sure My API Roundup Stories Are Machine Readable By Designing Them As APIs.json Collections

04 March 2015
Making a list of valuable APIs has been a staple of my tech blogging for 10 years now, and as I work to find even more meaningful ways of defining the API space, I’m pushing the envelope on how I do API roundup stories. Instead of just finding a handful of valuable APIs, and providing an HTML list of them, I'm going to use APIs.json, to make sure all of my collections are machine readable by default. For each API I profile, it is valuable to have a nice logo, name, short description, and a link to the developer portal. However I want to also make sure other valuable, machine readable resources are also present like Twitter, Github, and Blog RSS. This is just the start, I want each API to also have a machine readable API definition using Swagger and API Blueprint as well--all indexed using an APIs...

My API Design Research

04 March 2015
I am giving each of my primary API research sites a refresh, and first up is the home page of my API design research. As I update each home page, I'm going to publish here on API Evangelist to help bring more awareness to each of the main areas I'm studying. This is one of my API research sites, focused specifically on API design. My name is Kin Lane, and I am the API Evangelist, working as hard as I can to understand the world of the Application Programming Interface, widely called an API. This network of API research projects all run on Github, and is my real-time workbench, which means there is a lot of finished work present, but occasionally you will also come across areas projects that are unfinished--you have stumbled in my API design research, you will find the main API Evangelist site over here, with other links to my work...

Adding Four New Building Building Blocks Providing An API Management API Blueprint

04 March 2015
I am adding four new building blocks, to my list of suggested building blocks that API providers should consider when crafting their API management strategy. These four building blocks, are based upon several things I’ve seen in the space, and how some current deficiencies I’ve identified that could slow things, and hold us back. These new building blocks are all about API providers practicing what they preach, and making the account for API consumers, and developers, programmatic through an API management API. As I was profiling the Maijet API as part of my email API research, I noticed they had an API for their developer accounts, and with the growth in the number of APIs being consumed, the need for account automation is only going to incease, something that is only getting even more critical when you think about the API service composition overhead needed to support the containerization and micro-services movement...

Some Please Build A True Next Generation Press Release Aggregation API

03 March 2015
I spend a lot of time wading through press releases at the number of the dominate aggregate news outlets, looking for API news. I also have a number of scripts running, keeping an automated eye on the press sections for some of the companies I track on. The number of press releases available in corporate press areas vs. the number of press releases submitted by PR outlets, is much larger--which is a missed opportunity in my book. Each day I look through PRWeb, PR Newswire, Business Wire and others trying to find the latest API stories. This is a process that will always be partially a manual process, as you just can’t look for API news without getting petroleum, education, pharmaceutical, and other API news—which has nothing to with my beloved application programming interface...

You Can Feel It When An API Evangelist Is The Real Deal

03 March 2015
I had the pleasure of finally meeting someone in person, that I feel like I’ve known for years, while I was over in Australia, for API Days Sydney—Keran McKenzie (@keranm), API Evangelist for MYOBapi. I got to drink, and talk with Keran (finally), but more importantly I got to listen to him talk about his approach to evangelism at the accounting API. I have given, and listened to more talks on evangelism and advocacy than I care to remember. I always work hard to make sure I sit and list to as many evangelism talks as I can—there is always something to learn. Keran's talk was informative, thorough, and most importantly it was genuine. Keran discussed many of the proven areas of evangelism we all share, but not in a robotic or corporate way, he shared his, and MYOB’s philosophy, and told the honest story about the challenges and triumphs...

Visualizing And Exploring My Microservices Catalog Using APIs.json With Swagger.ed

02 March 2015
I'm just getting started exploring the ways to use APIs.json when it comes organize my new Docker fueled, micro services stack. I’ve been using APIs.son to describe each micro service, as well as define the overall collection of almost 20 micro services. I’m using the include collection, as a navigation for the loosely coupled stack of micro-services, and my friend Chris Spiliotopoulos (@chefarchitect), has done some more work with his Swagger.ed, delivering some APIs.json goodness that is in alignment with where I want to take all of this. Adding to the discovery and visualization work he did for Swagger, Chris enabled Swagger.ed to look for valid APIs.son files as well, so when you browse to any APIs...

Using Machine Readable API Definitions To Solve A Persistent Question: Are There Any Write APIs In Federal Government?

02 March 2015
A topic I've written about before, and one that I answer regularly on forums, via email, and on Twitter is, “Are there any write APIs in the federal government?” It is a valid question, and as I said in my strategy suggestions for the federal government, write APIs are a critical aspect of all of this moving forward in a healthy way. Rebecca Williams (@internetrebecca) pointed me to a recent discussion on this topic earlier today, to which I added a couple of suggestions, but ultimately it is something I would like to see a more progressive solution emerge, something that can answer it real-time, and change as the API inventory in the federal government changes and evolves. Keeping a list, like 18F is doing, is a start, but we need more...

A Peek At The Future With White Label APIs

26 February 2015
I’ve been talking about the possibilities around wholesale APIs for a while now, something that is only going to become more prevalent with the popularity of micro services and containers. I thought this company's approach to white label APIs was pretty basic, but worth showcasing, providing a glimpse of what is possible when you are talking about B2B APIs. Recharge kit provides 15 separate APIs for wholesale usage. I thought it was a telco stack of APIs when I first landed, but it is an interesting mix of telco, utility, travel, and more. I predict companies will emerge with a much more nuanced stacks of micro-services than Recharge Kit, but their approach shows some of the thinking occuring in the space...

Generating Client Side Code From Machine Readable API Definitions

26 February 2015
This post has been open for almost two weeks now in Evernote. It began as a simple story about the possibility for generating code samples and libraries using Swagger. The longer it stays open, the wider the definition becomes, so I have to post something, just to draw a line in the sand. I’m not talking about generating code that runs on the server, this post is all about everything on the API consumption side of things. Shortly after Wordnik launched the machine readable API definition format Swagger, they launched a library for generating client side code samples in a variety of languages. This was something that was evolved upon by Apiary, with the launch of their API design platform, and introduction of API Blueprint...

Moving Away From Legacy Vendor Relationships To A Devops, Micro-Services Way Of Life At Nike

26 February 2015
I had the pleasure of attending a gathering at Heavybit Industries last week, a community for developer-focused entrepreneurs, where one of the headlining speakers was Nike CTO Chris Satchell. I wish I had taken better notes, but the one thing that stuck with me from his talk was his story about moving beyond their love affair with almost any software vendor that came along, and diligentlywork towards a micro-service oriented environment. As the CTO, Satchell was working to clean up the message of legacy applications used across the enterprise, which was the result of years of, as he put it, saying yes to almost any software vendor that came along. Music to the ears of the San Francisco audience, he was now working to move the company out of a single data center, into the cloud, redefining operations as micro-services, and instituting a devops mindset along the way...

The Alpha API Evangelist Workbench

24 February 2015
The API Evangelist network is my open workbench, and I understand for many, it can be confusing to see some of my half-baked ideas alongside some of my more hardened API 101, business of APIs, and politics of APIs work. I try to keep the API Evangelist blog containing information for the API newbie, as well as my more advanced API leader crew--something that is tough to do. I have a lot of ideas coming off the assembly line around my own infrastructure, Docker, microservices, and other more forward leaning areas. Normally I dump a lot of this mundane exhaust from my world over on Kin Lane, but that site gets picked up by DZone, due to historical connections, and that audience is pretty trollish, second only to Hacker News...

Driving Your Single Page Applications And API Cookbooks Using API Definition Formats Like Swagger And API Blueprint

24 February 2015
During my monitoring of the API space this last week I had one of those rare discoveries, amongst thousands of misses, and around a hundred slightly interesting nuggets, a simple move forward called Lucybot emerges.  I want to walk you through what I experienced as I had the tab open in my Chrome browser for the last week, in Lucybot's own words: LucyBot is a tool for on-boarding new API developers, and is meant to be used alongside traditional API documentation such as Swagger and I/O Docs. I really like this sentence when they start talking about generating API cookbooks: LucyBot generates cross-language cookbooks for any REST API. Design step-by-step walk-throughs for any use case, and LucyBot will provide cross-language code snippets, which expand into a working, visually-rich demo...

API Evangelism Sometimes Seems Similar To The Environmental Discussion - What We Would Like, Does Not Reflect What Actually Happens On The Ground

23 February 2015
I was just listening to segment on NPR, All Things Considered, about educating students around the environment. Throughout the program I couldn’t help be reminded of a similar imbalance in the world of APIs. Throughout my API experience I’m constantly faced with a separation between what I hear is possible, what I would like to see, and what actually occurs on the ground in startups, small businesses, and within enterprise organizations, and government agencies. You might have to listen to the segment to fully grasp what I mean, but essentially it comes down to this: we’d like a perfect world where we do not negatively impact the environment, and everyone understands the urgency, but in reality there are a lot of real world constraints that prevent us from truly realizing this vision...

Scaling What I Do At API Evangelist

23 February 2015
In my day to day operations, I get regular calls from VC's (Venture Capitalists) looking to better understand APIs, the role they are playing within specific industries, working towards a better awareness of how they will impact their portfolio. These conversations almost always end with the question, "what can I do for you?", something that always leads to the next question, "what does scale look like for API Evangelist?". A verty interesting set of questions... Interestingly, the answers to these questions are directly related to another common question I get from people in the space, "how do you make money?". I'm fortunate. I get to scale API Evangelist exactly as I see fit, because I get to choose who I take money from...

My Brain Dump On An API Definition Fueled Life Cycle

23 February 2015
I’ve written about this topic before, in an effort to understand the possible incentives for API providers to generate their own machine readable API definitions in formats like Swagger and API Blueprint. These machine readable definitions for APIs and microservices are important to have, but not everyone produces them by default for their APIs, and honestly nobody is going to create them until there are enough incentives to sweeten the pot. It helps me to walk through this story again, understand the incentives for generating API definitions to date, in hopes of better understanding where we are going. Early on Wordnik developed Swagger, to generate: Interactive Documentation - Making learning about an API, a hands-on experience, accelerating time to first API call...

Looking Beyond The Number Of APIs, Or Just New APIs, And Working Harder To Find Only The Most Important APIs

23 February 2015
I constantly struggle to stay in tune with the scope of the API space, and keep pace with its rapid expansion. As part of this struggle, I am always on the hunt for new ways to shift the way I look at the space—as long as it helps me understand things better, while also contributing as much valuable, and open information back to the API space. The With this in mind, the API Evangelist monitoring algorithm is always in flux, with the latest change being the elimination of the “number of APIs” or “number of new APIs”, from the monitoring equation. I have showcased the growth in public APIs for a long time now, and for a while, it was what I needed to motivate my research and storytelling, but after almost five years, these two data points are becoming a liability for me...

I Got Swagger.ed Last Week, And Now I Am Seeing API Visualizations

23 February 2015
Some of the side effects of being so open and transparent about my ideas, like the one I had around API visualizations, is that people who are doing similar things, like Ardoq, eventually find you. Even better, is when someone closely follows your thoughts, and takes your ideas, and sets into motion, your original idea, in a way that will allow it to become bigger than the original idea. Last week Chris Spiliotopoulos (@chefarchitect) sent me an email, with a simple Chrome extension attached, asking what I thought. After installing the add-on (just drag onto your Chrome extension page), I visited my notebook of Swagger defined APIs over at API Stack, and when Twilio’s Swagger definition loaded in the browser, I saw a little Swagger icon show up in my browsers address bar—you know kind of like when there is an RSS feed available...

Developing Small, Simple, Meaningful Tools That Make An Impact Across The API Space

23 February 2015
I have API tooling on the brain, a result of conversations on multiple fronts, and the evolution of my own thoughts on creating what I’d see as the perfect API design tool. My thoughts on API tooling, reflect my general API philosophy, and focus on developing small, meaningful tools that truly make an impact. First, nobody likes being dependent on bloated software products. The age where software looks like Microsoft Office in my opinion, is over, and I’m looking forward to a brighter future. I feel pretty strongly that we need small, simple tools, that work in concert, not via a single client I have to pay for 100% of features, to get just 2% of the features I actually need to get done, what I need...

The Role APIs Can Play When It Comes To Online Trolling

16 February 2015
There is an interesting story about Twitter trolling over at Yahoo News from CBCNews.ca, which includes recommendations from Adria Richards (@adriarichards) for using the Twitter API to crack down on trolling, based upon her own experiences. Here is the specific API mention from the story: Richards has shared her own recommendations for Twitter to clamp down on trolling, which include making trending harassment patterns available via the application programming interface (API) and allowing users to subscribe to blacklists to exclude words from their timelines. I think APIs can playing a larger roll when it comes to online trolling, but we’ll need someone to step-up and own the topic, working with Twitter, and other social networks to expose the right APIs, and give more control to end-users...

Meet The Platform Team Over At Mendeley API

16 February 2015
I was playing catchup on my feeds over the weekend, and came across a nice, meet the Mendeley platform team post, from the academic research API. I’m a big fan of these types of efforts, that help humanize API operations, and bring API providers closer to API consumers. From the outside, it is difficult see behind the API curtain, and showcasing the team, is one of the best ways to break down barriers. Simple things like showcasing the team, let each one tell their story, and providing Twitter accounts for each team member goes a long way in helping me connect with what an API does. Something that will continue beyond just this one post, because I followed each team member that is active on Twitter, and will be able to stay in tune asynchronously...

An API For The Interactive JumboTron Floor Display At The National Museum of Mathematics (MoMath) In New York

14 February 2015

Are Your APIs Ready For The Coming Containerization Evolution Of The API Space?

14 February 2015
If you were at Defrag in Colorado last November, or in Sydney, Australia for API Days last week, you’ve heard me talk about what containers are doing to APIs. There is a subtle, but important shift in how APIs are being deployed occurring right now, and as John Sheehan (@johnsheehan), the CEO of Runscope says, containers are doing for APIs, what APIs have been doing for businesses. As I was processing news for API.Report this morning, I found more evidence of this, with the release of logging API container from Logentries. APIs have made resources like “logging”, much more modular and portable, for use in multiple channels like mobile or via websites. A containerized logging API makes the concept of a logging API much more portable, by adding an entirely new dimension for deployment...

Changes To LinkedIn Developer Program Are No Surprise

12 February 2015
LinkedIn recently announced some changes to their developer program, which involves further tightening down the screws on who has access to the API, limiting public access to only a handful of very superficial APIs. If you want greater access to the business social network API, you will need to be an officially approved partner. As a result of LinkedIn’s announcement, you will hear more discussion about the demise of public APIs, as this is narrative many API providers would like to employ, to support their own command and control positions around their client, or very own API driven resources. There is nothing wrong with having private APIs with supporting partner programs, but this has no bearing on the viability of publicly available APIs...

Migrating My Own API Infrastructure Conversations To My Personal Blog And Keep API Evangelist About Mainstream Stories

08 February 2015
After seeing the conversation around my In The Future There Will Be No Public vs. Private APIs, I'm reminded of my own mission. I write on API Evangelist first and foremost for my own education, and secondarily I do it to help educate the normals about the importance of APIs. Not page-views. Not to educate the API echo chamber. Not to drive conversation over at DZone or Hacker News. Definitely not to insult anyone. That story was me working through my own service composition, and looking at one possible future. That exchange you hear in the story, and all my stories, is the conversation between the voices in my head, and is never mean to insult anyone (think Michael Keaton in Birdman). All of this has reminded me that API Evangelist is not about cutting edge stories, like the unproven stuff I'm doing with my own API architecture, docker and microservices...

APIMATIC Code-Generation-as-a-Service Has Built-In Support For API Commons Manifest

08 February 2015
The API savvy folks over at Apimatic are at it again, pushing forward the conversation around generating of software development kits, using machine readable API formats, and this time the doorway to your SDK is via the API Commons manifest. I'm going to go ahead and use their own description, as it sums it well, no augmentation needed. Using the code generation API, you can generate SDKs for your API directly from your Github repository.  Step 1: Describe you API using some format. You may choose from Swagger, RAML, APIBlueprint, IODocs, and Google Discovery formats. Automatic code generation makes use of information in your API description to generate method and classes names. Please be as expressive as possible by not leaving out any optional fields as applicable e...

A Minimum Viable APIs.json File For Your APIs

08 February 2015
I'm continuing my work to help people understand what APIs.json is, and the varying ways that it can be put to use. My post the other day, breaking down Fitbits APIs.json file is a good example of where to get started, but I wanted to help further set the bar for a minimum viable APIs.json. APIs.json starts with a basic set of descriptions of who you are, the API provider. Each header of an APIs.json file gives you a handful of parameters for describing who you are: name - your individual or company name, who is managing the APIs.json file. description - a description of your company and / or the API collection you are building. image - an image, logo, or icon that describes yourself or your company...

My Wish Has Been Granted: Swagger Driven API Visualizations From Ardoq

06 February 2015
I'm a big fan of putting my ideas for new tools, services, and other stuff out on the Internet, for public consumption. My mother taught me how to manifest things in my life, and this is my digital version of her teachings. By putting my ideas out there, a) I don't actually feel compelled to do them b) someone else might think it is good idea and build it, and c) when someone does build it and they start looking to publicize, they will find you. c) happened today. One idea that I put out there recently, that I really wanted to manifest, was a visualization layer for APIs using Swagger. My wish has been granted, and a startup called Ardoq, has done just that, developed a visualization layer using Swagger...

When You Are Ready For Nuanced Discussion About Who Has Access To Your API I Am Here

06 February 2015
David Berlin has a rebuttal post on ProgrammableWeb to my recent post In The Future There Will Be No Public vs. Private APIs, called Long Live The Private API. I’m a big fan of doing story responses using our blogs versus the sometimes difficult Twitter conversations that occur--so I am happy to craft a response as well. I’m less of a fan of playing into page view games of fabricated kerfuffles, and link-bait titles, which after re-reading, my own blog title was a little link-baity. However in reality, my story came from my workbench as I was reworking some of the service composition stack, and reflect that process, not the conversation it seems to have created, but hey, I am all about embracing unintended consequences...

Defining Virtual API Stacks Using The Service Broker API Over At IBM Bluemix

05 February 2015
I've been talking about developing virtual API stacks for a while now, and as I continue understand current shifts in cloud computing, I am doing my own reshuffling towards a more microservices, and docker-centric way of life. When I say the phrase “virtual API stack”, I’m talking about the ability to deploy a stack of APIs you need for a specific organization, project, app, or other configuration. In 2015, you should be able to quickly define exactly the stack of private, and public API services you need to accomplish exactly what you need--nothing more. As part of my research in this area, I’m tracking on similar patterns, that I see occurring at platform providers--today I found an example of defining virtual API stacks using the service broker API over at IBM Bluemix...

An Increase In Number Of Press Releases Involving API Integration

04 February 2015
I spent a portion of my time each day reviewing press release sites, in addition to the 1000+ blogs I keep an eye on, for syndication to API.Report. During the course of my work this year, I'm noticing an uptick in the number of press releases that are about some new app, feature, and partnership that has an API at its core. Telling the story of prominent integrations is something I am a big advocate for, but I think the growth in the number of official press releases about API integrations shows that the mainstream SMB and enterprise markets are putting APIs to work more, and looking to showcase. For me, this demonstrates that APIs are playing more of a central role in not just the deployment of apps, but the course of regular business for an increasing number of companies in 2015...

What Do I Mean When I Say APIs Are Just The Next Step In The Evolution Of The Web?

04 February 2015
I remember the vision clearly from 2004, when I first changed the URL for my Delicious social bookmarking account to make it return a list of bookmarks as XML instead of HTML. It was a vision of the programmable web--where everything I explored on the Internet, wasn’t just consumable, and right below the surface of any website or application I was using, there was also a machine readable version, allowing me to build whatever I desired. People are often surprised when they realize I do not have anything to sell them, and that I evangelize that APIs are not some new product, but just the next step in the evolution of the web. This is easy to say, however it can be much harder to demostrate to the “normals”, leaving me always hundting for easy to understand API implementations I can use to help bring me people closer to understanding...

What Exactly Is API Commons?

04 February 2015
As I travel around talking to folks about APIs, I spend as much time as I can educating folks about API Commons, and I’m constantly reminded how little people, who have even heard, and read about API Commons, really understand what it is. With this in mind, I will be regularly publishing examples of what API Commons is, to help onboard everyone to mine and Steve's (@njyx) vision of API Commons. API Commons is a machine readable pointer to the license of your API. As I talk with folks, and watch videos like this one at APICon in UK, I realize how many misconceptions there are about it. Many folks emphasize the Creative Commons license we’ve chosen, or the listing of APIs we’ve had added to our version of the commons, by publishing an API Commons manifest, which references a CC-BY or CC0 license...

APIs Used To Close, Rather Than Open The Internet

04 February 2015
I get a lot of folks who come to my blog, see the title, read one or two posts, and assume that I’m a blind lover of API technology, and that I see APis as a solution to everything. While some of this is true, I do love APIs, and think they are a great solution (in some cases), at the same time I’m also an outspoken critic of APIs, and work hard to be a voice of reason when I see people doing stupid shit with them. With this theme in mind, I want to once again remind everyone that APIs are neither good, nor bad, nor neutral by themselves, they are merely one of the tools companies can wield, and completely reflect the motivations of their masters. One such example of this in action, where I believe an API is being used for some pretty bad reasons is with the AT&T sponsored data API...

Recap Of APIs At Dept of Education, And The FAFSA API

04 February 2015
My work on APIs for the Department of Education, and the FAFSA API began while I was working in Washington DC as a Presidential Innovation Fellow. Shortly after leaving DC, I was informed that conversations around an API for the FAFSA had been put on back-burner, and in response I developed a prototype FAFSA API to help jumpstart the conversation. In December 2013, I went to one of the two data jams put on my the White House and Dept of Education, up in Palo Alto, CA at Stanford. Then, in January 2014 I heard there was talk at the secretary level, about officially pursuing a FAFSA API. Yay! By February I got an email that there was an opportunity for funding such an initiative, if there was a technical specification available...

I See An Opportunity In Paying Attention To Other Types Of APIs

04 February 2015
I've been pretty focused on web APIs in my API Evangelist world, steering clear of hardware, networking, desktop software, and the American Petroleum Institute. While you will never catch me paying attention to oil, I am slowly changing my tune on other types of legacy APIs. As I read through the first 700, of the 16K API related patents I’ve harvested from USPTO XML files, I initially started dismissing hardware related patents, and then some of the more network related ones as well. Then I started evaluating the impact these patents could have on the Internet of Things (IoT), and I am beginning to shift my stance. I may not fully profile the approaches of some of these API providers, but I think I will at least bookmark, and consider the approach, and how its being applied, while also putting on my web API architect hat...

APIs Are Establishing New And Useful Processes Faster Than Patents Can Keep Pace With

03 February 2015
I’m spending a lot of time reading API related patents lately. I downloaded all of the patent applications between 2005 and 2015, filtered for all patents that mention “application programming interface” in the title, abstract, or description of the API, resulting in a database of 16,485 patents. Currently I’m reading the 700+ that just mention API in title or abstract, and once done I’ll take a look at the rest. First, let me state that patents are not a concept I subscribe to. Personally, I do not believe in defining, and locking up ideas, but I do not live in the world I’d like, and after beginning my patent API search, I see patents are a concept that like API copyright, will be increasingly wielded across many industries where APIs are being put to use...

In The Future There Will Be No Public vs. Private APIs

03 February 2015
As I continue to evovle my service composition definition, using my 3Scale API infrastructure, across my microservices stack, the thought of public vs private doesn’t even enter the equation. I am doing my APIs using the Internet pipes, so they are public by default—then using my service composition I define the layer that actually regulates what is openly accessible by the public, what resources have limited access, and specifically how much of any resource any single person can access. When I’m working through my API Stack, the concept of public and private doesn't exist. This is a reality that plays out in conversations between people who don’t fully understand the world of API management—aka the tech blogosphere...

Static HTML Documentation Generated From Machine Readable API Blueprint Definitions Using Aglio

03 February 2015
I'm on the hunt for new ways to deploy attractive, interactive API documentation, from machine readable API definition formats like Swagger and API Blueprint. I am advocating for the development of new approaches to deploy UI documentation, and part of this showcasing what I find along the way. In the spotlight today is Aglio, which they describe as: An API Blueprint renderer that supports multiple themes and outputs static HTML that can be served by any web host. API Blueprint is a Markdown-based document format that lets you write API descriptions and documentation in a simple and straightforward way. Aglio is significant because it is driven from the machine readable format API Blueprint, and produces static HTML that can be served up anywhere, specifically on Github or Amazon S3 deployed using Jekyll...

A Machine Readable Version of The Presidents Fiscal Year 2016 Budget On Github

03 February 2015
The release of the the president's fiscal year 2016 budget in a machine readable format on Github was one of the most important things to come out of Washington D.C. in a while when it comes to open data and APIs. I was optimistic when the president mandated that all federal agencies need to go machine readable by default, but the release of the annual budget in this way is an important sign that the White House is following its own open data rhetoric, and something every agency should emulate. There is still a lot of work to be done to make sense of the federal budget, but having it published in a machine readable format on Github saves a lot of time, and energy in this process. As soon as I landed on the Github repository, clicked into the data folder, and saw the three CSV files, I got to work converting them to JSON format...

The Logo Page Over At The MYOB API Is Very Helpful

03 February 2015
I spend a significant portion of my day looking for company logos, for use in the API stories I tell. When I come across a proper implementation of a logo page, one of the business building blocks I recommend employing, I have to showcase it. I got an email from my friend and fellow API evangelist Keran McKenzie (@keranm) about updating the listing for the MYOB API on my API Stack. He sent me a better description, and a couple of new links that I didn’t have, including a link to their logo page. One thing that I think is particularly interesting about the MYOB logo approach, is that they offer an assortment of designs: Corporate Logo - The MYOB name and logo represent the MYOB business and is protected by copyright and trademark laws...

API Evangelist Logomaker

02 February 2015
In 2010, when I started API Evangelist, I sat down to create a logo, and after six hours of frustration in photoshop, I eventually just typed out my logo as a basic JSON representation, kind of as a joke, which I eventually planned on changing, but it stuck. With the latest batch of t-shirts I've ditched the "logo" portion, but will keep this legacy version floating around, here and there for nostalgic purposes. Along the way, I've added what I consider the function version of the logo, which I use for each of my research sites. I'm starting so many new research areas lately, I decided to create a logomaker API, so I can make new logos, and anyone else can make their own as well. There are three API endpoints for the API Evangelist logomaker API: Single - http://logomaker...

API Management Infrastructure And Service Composition Is Key To Orchestration With Microservices In A Containerized World

02 February 2015
As I work to redefine my world using microservices, I have this sudden realization how important my API management infrastructure is to all of this. Each one of my microservices are little APIs that do one thing, and do it well, relying on my API management infrastructure to know who should be accessing, and exactly how much of the resource they should have access to. My note API shouldn’t have to know anything about my users, it is just trained to ask my API management infrastructure, if each user has proper credentials to accessing the resource, and what the service composition will allow them to do with it (aka read, write, how much, etc.) My note API does what it does best, store notes, and relies on my API management layer to do what it does best--manage access to the microservice...

We Need Better API Documentation And UI Deployment Options

02 February 2015
I was having a Twitter conversation with John Sheehan(@johnsheehan) about the easiest way to generate interactive API documentation this weekend, without getting all tangled up in having to get into the weeds of Swagger UI. I love me some Swagger UI, something I think has transformed how we engage with APIs, but the JavaScript for it can be inaccessible, and difficult to customize--to say the least. There are other UI solutions to API documentation, projects like Slate from Tripit, from Readme.io, and some cool UI stuff over at OpenFDA, but really I haven’t seen much evolution beyond Swagger UI. Sure, Apiary.io has a great UI, but it isn’t the portable, customizable vision I have in my head (they are working on this, BTW)...

API Patents 2005 Through 2015

31 January 2015
I started doing research on API patents recently, and after about 5 days of processing XML files from the US Patent Office, I'm going to stop processing at the year 2004 (way back). This gives me 2005 through present day, and provides more than enough information for me to evaluate the role APIs are playing in the patent process, and inversely how patents are affecting the API space. In 2004, the XML data files I'm processing start to change, and I'm getting errors, resulting in me having to reconfigure my script, in addition to downloading the numerous, large XML files. I think I have enough of a sampling to start building a wider awareness of what is going on with patents and APIs, I can always come back and download 1995 through 2004...

Why Would Want To List All Your Universities Web Services (APIs) Out In The Open, Via Central Portal? What A Security Risk!

31 January 2015
I went up to California State University Channel Islands the other day to talk APIs with their tech team, and I was happy to find at least one strong API skeptic on the team. API skeptics also give me material for stories, so I thoroughly enjoy coming across them, and telling these stories is how keep polishing my argument for the next API skeptic encounter at campus IT, at the higher educational institutions that I visit. During the discussion I was asked several interesting questions, the first one was: why would you want to list of your web services (APIs) for your public university, out in the open, via a central portal?? What a security risk!! Sorry, But Security Through Obscurity Is Not A Strategy I’m sorry, hiding things, and hoping nobody finds them is not a valid IT strategy...

Breaking Down The Fitbit APIs.json File

31 January 2015
The quantified-self API Fitbit recently added an APIs.json for their domain. Their usage of APIs.json is a perfect, dead-simple, introductory example of how APIs can start putting APIs.json for their API platform. To help other providers understand, I wanted to take a look at the moving parts of Fitbits APIs.json, and to assist the conversation I labeled each part. A) The heart of an APIs.json, providing a name, description, image, and tags for API platform and collection. B) The technical details of where this APIs.json came from, which version it is, and when it was created and last modified. C) Similar to the overall APIs.json collection, each API gets a name, description, image, and tags, but also as the default URL people should go to find the API, as well as the base URL actually make calls to the AP, which is used as the API identifier...

Why Would You Ever Give Students API Access To The Student Information System (SIS), And Let Them Build Un-Sanctioned Apps That We Will End Up Having To Support?

31 January 2015
I went up to California State University Channel Islands the other day to talk APIs with their tech team, and I was happy to find at least one strong API skeptic on the team. API skeptics also give me material for stories, so I thoroughly enjoy coming across them, and telling these stories is how keep polishing my argument for the next API skeptic encounter at campus IT, at the higher educational institutions that I visit. During the discussion I was posed several interesting questions, and one of them was: why would you ever give students API access to the Student Information System (SIS), and let them build un-sanctioned apps that we will end up have to support? Family Educational Rights and Privacy Act (FERPA) FERPA gives students the right to review, control disclosure, and request amendment of their education record...

What Is Missing On My Microservices Using APIs.json

30 January 2015
I'm using APIs.json to organize my swagger defined microservices running in docker containers, and using the machine readable API index to drive navigation between microservices organized in a single collection. APIs.json provides a simple, machine readable way to index the technology, business, and political elements of each microservice I deploy. As I was auditing the 18+ microservices I’ve setup for my core operations, I wanted to audit each one, and make sure I had included various elements in each APIs definition, like where developers can onboard, terms of service, and where to find related code samples. To accomplish this, I was able to just compare each microservice APIs.json, with a master APIs...

Talking APIs Up At California State University Channel Islands

30 January 2015
I spent the day yesterday up in Camarillo, at California State University Channel Islands (CI). Half my time I spent speaking with a mix of folks from the campus tech team about APIs, and the other half I spent learning about video production at the university. I wanted to thank , Chris Mattia (@cmmattia) Director of Academic Technology, CSU Channel Islands, Michael Berman (@amichaelberman) VP Technology & Communication, California State University Channel, Mikhail Gershovich (@mgershovich) for having me up. The conversation I had with their tech team around APIs reflected other conversations I’ve been having with other higher educational institutions. It was a mix of business and technical talent from the school, ranging from instructional technologists, to front-end, and backend data people...

Proxy The Public API You Are Using With APITools And Send Me The Swagger It Generates, Please...

30 January 2015
APITools is a simple, open source, API middleware that allows you to “track, transform and analyze the traffic between your app and the APIs”. With just a few clicks you can proxy any API you use, and when you make calls through the proxy, you get a bunch of valuable information in return. One thing APITools does, that is extremely valuable to me, is it generates Swagger definitions, mapping out the surface area of an API, with each call I make. These API definitions have a wide variety of uses for me, ranging from better understanding the API designs of popular services, to providing API search services through open API search engines like APIs.io. If you are regularly developing against a public API, can you take a moment to swap the baseURL with one created in APITools, make all of your calls to the API, then send me a copy of the Swagger definition? I would sure appreciate the help in creating Swagger definitions for all of the popular APIs available today...

How To Generate An API Surface Area Map For A Microservice?

30 January 2015
I was struggling with exactly how much API surface area can exist for a service before it stops being micro the other day, and while I don’t think I’ll ever find a precise measurement for this, I’d like to have a fluid definition that I can use to automatically evaluate, how big an API is. So, what data can I gather, to help me quantify the surface area of my API? I’ll start with each endpoints, then count each verb, parameter, and potential response. Since I use Swagger for all of my API definitions, I can easily do this, and I can also understand each API response better because also I have them linked to the underlying data model. I’m not exactly sure how this surface area definition will work, ultimately I’d like to be able to separate verbose APIs by different layers, like the number of endpoints or parameters, or maybe the lack of verbs, or responses (not what is there, but what is missing)--I'm not sure...

How Much API Surface Area Before It Stops Being Micro?

28 January 2015
I have most of the core platform that I run API Evangelist on re-engineered as individual microservices, defined on Github, and running using Docker instances. I’m using APIs.json for discovery, navigation, and to connect swagger API definitions, to their docker backends. So far I have 18 microservices, which I define as very simple APIs, that do one thing, and focus on doing it well. I’m very critical about any feature I add in, working hard to keep each service as micro as I can, reducing complexity, and bloat in any single API. However, with each service I reach the point where I have to cut off feature creep, and establish an entirely new API definition--I am at this point with my link service...

Using APIs.json For My Microservice Navigation And Discovery

28 January 2015
I’m rebuilding my underlying architecture using microservices and docker containers, and the glue I’m using to bind it all together is APIs.json. I’m not just using APIs.son to deliver on discoverability for all of my services, I am also using it to navigate around my stack. Right now I only have about 10 microservices running, but I have a plan to add almost 50 in total by the time I’m done with this latest sprint. Each microservice lives as its own Github repository, within a specific organization. I give each one its own APIs.json, indexing all the elements APIs of that specific microservice. APIs.json has two main collections, "apis" and "include". For each microservice APIs...

Using Swagger As Fingerprint For My Microservice Docker Containers

28 January 2015
I'm rebuilding my underlying architecture using microservices, and docker containers, and I'm using APIs.json for navigation and discovery within these new API stacks that I use to make my world go around. As I assign each microservice, and APIs.json file, taking inventory of the building blocks that make the service operate, I also begin including docker into the equation, and I find myself using Swagger definitions as a sort of fingerprint for my docker powered microservices. Each microservice lives as its own Github repository, within a specific organization. I give each one its own APIs.json, indexing all the elements APIs of that specific microservice. This can include anything I feel is important, like: X-Signup - Where to signup for the service...

Incentives For Companies To Be More Public With Their API Presence

28 January 2015
I spend time each day reviewing about 15 different press release distribution websites, looking for API related news for API.Report, and potentially seeds for stories elsewhere on the API Evangelist network. One thing I’m noticing a lot, are companies who reference their API as bullet point in a release, or sometimes as a footnote in their about section at the end of the release, but when you go to their website you can’t find any mention of API. I’m guessing for many, they just haven’t thought about making the API something that is front and center, relinquishing it to just "feature status". There are also others who do not believe in the whole “public” API thing, and see their API as more secret sauce, something that should be kept close to your chest...

Wordnik API Is The Base Building Block Of Twitter Bots

28 January 2015
I’m fascinated by the rise of Twitter bots. Little automated bundles of social media joy, built to spew mostly nonsense, but everyone once in a while you find nuggets of wisdom in the Twitter API fueled bots. Personally I have never built a Twitter bot, only because I don’t need another distraction, and I can see the addictive potential of bot design. My partner in crime Audrey Watters (@audreywatters), who has hands on experience building her own bots, said something interesting the other day while we were partaking in our daily IPAs—the wordnik APIs it the base building block of any Twitter bot. Sure enough, when you search “twitter bots wordnik” on the Googlez, you get a wide variety of python, nobde...

The Politics, Marketing, And Fear of API Security

27 January 2015
I cringe, when I think about the number of mobile applications out there, that people depend on in their personal and professional lives, that are using insecure APIs, allowing personally identifiable information (PII) to flow across the open Internet. I’m a big advocate for helping mobile developers understand the important role that a public API can play in this situation, but another side of the discussions that also scares me is the fear, uncertainty, and doubt (FUD) that also emerges as part of this conversation. I’ve covered recent security and privacy involving mobile usage of APIs at Snapchat, and Moonpig, and was processing the API news this morning for inclusion on API...

APIs Role In Data Security And Privacy

27 January 2015
As we get close to wrapping up the first month in 2015, it is clear that Internet security and privacy will continue to be front and center this year. As technology continues to play a central role in our personal and business lives--security, transparency, and respect for privacy is only growing more critical. I know I'm biased in thinking that APIs will continue to take a central role in this conversation, but I feel it is true. Many of the existing conversations around security about platforms like Snapchat, and MoonPig, are directly related to APIs, while other security scope at companies like Sony, JP Morgan Chase, and beyond could easily be reduced with a sensible API strategy. Companies are increasingly operating online, but do not act like any of information lives in an online environment...

Finished Processing 973 API Related Patents From 2013

26 January 2015
I’m slowly processing XML files of patents from the US Patent Office. You can read the origin of my journey here, but as of today, I finished processing 50 files of patent applications for 2013, adding 973 API related patents to the queue. I’m still making sense of the different types of patents, and whether they are specifically for APIs, more API adjacent, or just mention API as one component in the patent definition. I figure I’ll go back to about 1990-1995, but not 100% sure at this point. So far I’ve identified 105 patent applications from 2015, 322 from 2014, and now 973 from 2013. I’m still reading the title and abstract of each patent application as they come in, building my understanding of what has been submitted, and the possible motivations behind each application...

My Experiences Generating API Server or Client Code Using Swagger

26 January 2015
When you start talking about generating server or client side code for APIs, using machine readable API definition formats like Swagger or API Blueprint, many technologists feel compelled to let you know, that at some point you will hit a wall. There is only so far you can go, when using your API definition as guide for generating server-side or clienit-side code, but in my experience you can definitely save some significant time an energy, by auto-generating code using Swagger definitions. I just finished re-designing 15 APIs that support the core of API Evangelist, and to support the work I wrote four separate code generation tools: PHP Server - Generating a Slim PHP framework for my API, based upon Swagger definition...

Doing The Research In Preparation For My Patent On A Patent API

25 January 2015
David Berlind’s (@dberlind), Amid The API Copyright Controversy, An API Patent Claim Surfaces story from this last Friday, planted some ideas in my head around APIs and patents—something that once takes hold, becomes hopeless for me to resist, and 48 hours later, here are my initial thoughts. Before I begin, let me state, patents and APIs, much like copryight and APIs, are not concepts I subscribe to, but because they are concepts that are being wielded in the API space, I am forced to enter the conversation. I’ll let you read David’s piece on Pokitdok’s claim regarding their “patent-pending API” for yourself, something I find very troubling (about Pokitdok)...

A Conversation About My Subway Map API On The APIsUncensored Podcast

23 January 2015
There is a new podcast on SoundCloud called APIsUncensored, from the folks over at SmartBear. I was honored to have a mention in the first episode, where they brought up a project I did a couple of months back, which I called the Subway Map API. I published a full story on what I was doing, and launched supporting Github repo, and API, but the work was very much a weekend side project, and something that will need a lot more love before it goes anywhere. Ole Lensmar (@olensmar) admitted that when he introduced the project, he didn’t really get it, but ultimately in their segment, they accomplished what I was looking to do—stimulate conversation. The Subway Map API isn’t about the ideas I plotted on the map for API Evangelist, it is about the format for grouping, and mapping out iof deas—then evolving them through conversation...

As API Space Expands, So Do The Sources Of Knowledge: New YouTube and SoundCloud Channels

23 January 2015
The API space is continuing its rapid expansion, and along with the number of API design, deployment, management, and integration providers, and the number of API conferences, there are some new sources of discussion around APIs--one as a YouTube Channel, and the other as a SoundCloud podcast. API Workshop - We'll discuss topics around API Design, including: sustainability concepts: how to design APIs that last, new ideas in API design, voices and posts from the API blog world. APIsUncensored - The official home of the APIs Uncensored podcast, a monthly series where Ole Lensmar and Lorinda Brandon blather about all things APIs with experts in the industry. API Workshop is a production by J(a)son Harmon (@jharmn), and APIsUncensored is from the smart folks over at SmartBear(when describing them I always feel tricked into saying they are smart)...

Preparing For My Talk At API Days In Sydney With Lots of Docker, Swagger, and APIs.json Work

23 January 2015
i’m spending a lot of time lately, playing around with different approaches to deploying APIs in Docker containers. Part of this is because it is the latest trend in API deployment and management, but also because I’m preparing for my talk at API Days in Sydney Australia next month. I am always working to keep my keynotes in sync with not just my own work, but in alignment with where the wider conversation is going in the API space. I’m building off my talk at Defrag last November, which was titled, "containers will do for APIs what APIs have done for companies". The title of my talk at API Days in Sydney is, "The Programmable World With APIs And Containers". While some of my talk will be inspirational, trying to understand where we are headed with APIs and containers, much of it will also be rooted in my own work to run my own business world using APIs and Docker, and using APIs...

Simple, Intuitive API Backends With HTTPHUB

22 January 2015
I come across a lot of API related companies during my monitoring of the space, which I queue up, and as I have time, I work to explore and understand what they do. One company that I’ve had open in a tab for the last week is HTTPHUB. HTTPHUB is very interesting. It starts by giving you a root namespace, like https://kinlane.httphub.com, and from there I can add on any resources on, and make it either public or private—then I can POST any JSON to this resource in the body. So I could create https://kinlane.httphub.com/notes/, and craft a simple form + script to post any data I submit to my HTTPHUB resource. I think that HTTPHUB captures the simplicity of APIs. Obviously the system will have some limitations, but ultimately it makes on boarding with the concept of APIs, and getting up and running with an API backend as frictionless as possible...

Translating Postman Collections Into APIs.json Collections And Back Again

21 January 2015
I've been a Postman user for a while, as a tool for quickly making API calls against the APIs I use most, and explore the new APIs I discover daily. As I use Postman, I can't help but think the concept of assembling collections of API calls using Postman, is in sync with part of our vision for APIs.json--we just need a common way to communicate. APIs.json is not just for defining the API operations that exist within a specific domain, which is the most common approach, it is also about assembling collections of multiple APIs, for a specific purpose. In my mind, the motivations for assembling Postman collections, and APIs.json collections are definitely in alignment. Similar to providing resources for translating between popular API definition formats like Swagger and API Blueprint, I want to make sure and translate between emerging API discovery and collection formats...

How Not To On-Board With An API

21 January 2015
I wrote a piece earlier today about the kick-ass on-boarding process at the National Institutes of Health (NIH) 3D Print Exchange API--within two clicks I had my API key and was making an API call. To contrast this post I wanted to provide an example of how not to on-board with an API. I am always amazed at how hard people make it to sign up and play with an API in 2015. Today's example of on-boarding with the most friction you can imagine comes from the Garmin Wellness API--I think their API signup form speaks for itself. I understand you are worried about what people might do with your API, but that is kind of the whole point of doing an API. If you are looking to encourage innovation on your API, this is not how you want to on-board your developers, and make a first impression...

This Is How You On-Board With An API

21 January 2015
I sign up for a lot of APIs, and when I encounter a frictionless on-boarding process, I feel the need to showcase, and help everyone understand how important it is to make the process as easy as possible. I'm still amazed at how many new APIs make this really, really hard. I will write a separate story after this about how not to on-board with an API, but for now lets take a look at a kick-ass example. This example comes from the National Institutes of Health (NIH) 3D Print Exchange API. When it comes to signing up for API access, the only thing that can make this easier is providing an API for the process, but for right from the home page you can signup for an API key. Once I provide my first name, last name, email, and optionally some details on how I will use the APIs, I am given my API key...

A New 3D Print Exchange API from the National Institutes of Health (NIH)

21 January 2015
There is an very interesting new 3D Print Exchange API from the National Institutes of Health (NIH). The NIH 3D Print Exchange is designed for publishing "biomedically-relevant" 3D models, that anyone can download and use as blueprint for printing on a their 3D printer. I've been tracking on 3D printing APIs since 2011, when I started profiling how APIs were being used by printing, and 3D printing providers. It is interesting to see an industry focused 3D printing API emerge, which I feel is a sign the space is maturing, and will continuing to evolve in 2015. Another thing to note in this story, is simplistic approach the NIH took in deploying their API. The 3D Print Exchange API has all the essential building blocks to help you understand what the API does, on-board with the API (another story), and get the support you need throughout integration via Twitter, Github, and email...

The Next Steps For The The Recreation Information Database (RIDB) API

21 January 2015
I referenced the Recreation Information Database (RIDB), in my story late last year, when I was asking for your help to make sure the Department of Agriculture leads with APIs in their parks and recreation RFP. I'm not exactly sure where it fits in with the RFP, because the RIDB spans multiple agencies. Here is the description from the RIDB site: RIDB is a part of the Recreation One Stop (Rec1Stop) project, initiated as a result of a government modernization study conducted in 2004. Rec1Stop provides a user-friendly, web-based resource to citizens, offering a single point of access to information about recreational opportunities nationwide. The web site represents an authoritative source of information and services for millions of visitors to federal lands, historic sites, museums, and other attractions/resources...

REST API Design: Bridging What We Have, To The Future, By Organizing The JSON Junk Drawer

21 January 2015
API storyteller J(a)son Harmon (@jharmn) has a new YouTube channel up called API Workshop. He's going to be publishing regular API design workshop episodes, with the latest one titled REST API Design: Avoid future proofing with the JSON junk drawer. J(a)son provides a nice overview of how you should be structuring the JSON for your API, focusing on the usage of key / value stores. Ironically he uses APIs.json as an example of why you SHOULD NOT use custom key / values within your JSON. What is ironic about this, is that he makes the case for APIs.json properties, giving me a great starting point for helping folks better understand APIs.json, and why properties are key to its evolution, and flexibility...

We Added 3 New Speakers To @APIStrat Lineup - Have You Submitted A Talk?

15 January 2015
We just added three new speakers to the lineup for @APIStrat Berlin this April 24th and 25th. I get pretty excited about this part of the event planning lifecycle, which is all about reviewing talks that being submitted, and working with the rest of the APIStrat, and now the API Days team, to develop the best lineup possible. Here are the three that we added today: Antti Silventoinen (@lamantiini) of Music Kickup Jordi Romero (@jordiromero) of Redbooth Matt Boyle (@mboylevt) of Shapeways   These three speakers represent APIs and the music industry, project collaboration, and 3D printing—which I think is a pretty nice representation of how APIs are making an impact in 2015...

Instant Access To APIs Via Github Profile

15 January 2015
An open project for me this month, is about better understanding how API keys are provisioned, and how developers are given access to valuable resources. As the number of APIs grows, so do the number of APIs that we depend on in any single application, forcing developer to have to manage many API keys, potentially from many different platforms. It doesn’t take an API expert to see that many current practices by API providers requiring consumers to manually register for an account, will not scale. We need more automated ways for not just discovering, but also on-boarding with APIs, allowing API consumers to begin using an API, without the current overhead required. One idea I’m bouncing around in my own APIs, is allowing for instant account creation via an API, allowing you to programmatically generate new account, a new app, and API keys...

Storing API Keys In The Private Master Github Repository For Use In My Github Pages

14 January 2015
My public websites have been running on Github Pages for almost two years now, and slowly the private management tools for my platform are moving there as well. Alongside my public websites, I’m adding administrative functions for each projects. Most of the content is API driven already, so it makes sense to put some of the management tools side by side with the content or data that I’m publishing. These management tools are simple JavaScript, that use the Github API to manage HTML, and JSON files that I have stored either publicly or privately within repositories. I use Github oAuth to work with the Github API, but to work with other APIs I need a multitude of other API keys, including 3Scale generated API keys I use to access my own API infrastructure...

Storing API Keys In The Private Master Github Repository For Use In Github Pages

14 January 2015
My public websites have been running on Github Pages for almost two years now, and slowly the private management tools for my platform are moving there as well. Alongside my public websites, I’m adding administrative functions for each projects. Most of the content is API driven already, so it makes sense to put some of the management tools side by side with the content or data that I’m publishing. These management tools are simple JavaScript, that use the Github API to manage HTML, and JSON files that I have stored either publicly or privately within repositories. I use Github oAuth to work with the Github API, but to work with other APIs I need a multitude of other API keys, including 3Scale generated API keys I use to access my own API infrastructure...

Use APIs.json To Organize My Swagger Defined APIs Running In Docker Containers

10 January 2015
I continuing to evolve my use of Swagger as a kind of central truth in my API design, deployment, and management lifecycle. This time I’m using it as a fingerprint for defining how APIs or micro-services that run in Docker containers function. Along the way I’m also using APIs.json as a framework for organizing these Swagger driven containers, into coherent API stacks or collections, that work together to accomplish a specific objective. For the project I’m currently working on, I’m deploying multiple Swagger defined APIs, each as separate Docker containers, providing some essential components I need to operate API Evangelist, like blog, links, images, and notes. Each of these components have its own Swagger definition, and corresponding Docker image, and specific instance of that Docker image deployed within a container...

Using Containers To Bridge What Swagger Cannot Define On The Server-Side For My APIs

10 January 2015
When I discuss what is possible when it comes to generating both server and client side code using machine readable API definitions like Swagger, I almost always get push-back, making sure I understand there are limitations of what can be auto-generated. Machine readable API definitions like Swagger provide a great set of rules for describing the surface area of an API, but is often missing many other elements necessary to define what server side code should actually be doing. The closest I’ve gotten to fully generating server side APIs, is when it came to very CRUD-based APIs, that possess a very simple data models--beyond that it is difficult to make "ends meet". Personally, I do not think my Swagger specs should contain everything needed to define server implementations, this would make for a very bloated, and unusable Swagger specification...

Internet Of Things Security And Privacy Will Always Begin With Asking If We Should Do This At All

08 January 2015
As I read and listen to all of the Internet of Things stories coming out of CES, I’m happy to be hearing discussions around privacy and security, come out of the event. I feel better about IoT security and privacy when I hear things like this, but ultimately I am left with overwhelming concern about of the quantity of IoT devices. There are many layers to securing IoT devices, and protecting the privacy of IoT users, but I can't help but the think that Internet of Things security and privacy will always begin by asking ourselves if we should be doing this at all. Do we need this object connected to the Internet? Are we truly benefiting from having this item enabled with cloud connectivity? I'm going to try and keep up with tracking on the API layer being rolled out in support of IoT devices, but not sure I will be able to keep up with the number of devices, and the massive amount of hype around products and services...

Scrubbing Individuals And Company Names From Stories I Tell

08 January 2015
I find it more valuable to scrub the names of the APIs from about 75% of my stories, which I feel helps them be received by a widest possible audience as possible. If I say “API Provider X”, other providers just think I’m talking about that company, but when I make it generic, I find API providers think I’m talking about them. There are many reasons I would scrub individual or company names from a story, most often this is because they’ve asked me not to reference them public, but are fine with me telling the story in an anonymous fashion. However, it occurred to me over time that there are other more powerful storytelling influences potentially behind leaving out specific characters...

Generating Swagger Specs For The APIs Of The 700+ Companies That I Monitor

08 January 2015
I'm about 1/3 of the way into generating Swagger specifications for the APIs at the 700+ companies that I monitor. I have the Swagger specs for almost 250 APIs so far, and have no idea how many I’ll have when I'm done (ha, will I ever be done), as the target is kind of ever moving. The only way to get to know an API better than having to create a Swagger spec for it, is to actually integrate with it. Thankfully I’m not integrating with ALL of the APIs I monitor, but I do want to get more intimate with their API surface area, right up to actually having to integrate. There are four ways that I obtain a machine readable API definition for an API: Manually - Good ol fashioned elbow grease because there is nothing standard about an APIs documentation, or even the API itself, forcing me to hand craft a Swagger definition that works...

Providing An oAuth Signature Generator Inline In Documentation

08 January 2015
I talked about Twitter's inclusion of rate limits inline with documentation the other day, which is something I added as a new building block, that API providers can consider when crafting their own strategy. Another building block I found while spending time in the Twitter ecosystem, was an oAuth signature generator inline within the documentation. While browsing the Twitter documentation, right before you get to the example request, you get a little dropdown that lets you select from one of your own applications, and generate an oAuth signature without leaving the page. I am seeing oAuth signature generators emerge in a number of API platforms, but this is the first inline version I’m seeing...

Using APIs To Help Achieve A More Owner-Controlled Internet of Things Experience

07 January 2015
A blog post that caught my attention recently was Fuse, Kynetx, and Carvoyant, by Phil Windley (@windley). Phil is pushing the boundaries of connecting devices to the Internet, and is very vocal about his thoughts on the subject—something I support 100%. If you want a taste of what Phil is thinking, check out his keynote from APIStrat Chicago 2014. His blog post is a worthy read, but what really caught my attention was in the last paragraph—the simple statement that he is: “using Fuse as a means to explore how a larger, more owner-controlled Internet of Things experience could be supported” I’m intrigued by this concept, and feel it reflects my mission with API Evangelist, where I’m looking to create not just a more educated and informed API providers and consumers, but also a more knowledgable, and empowered end-user...

My Dream Stack For Machine Readable APIs.json Properties

07 January 2015
The properties of each API that is listed in an APIs.json file can be called anything, as long as you preface it with X-, and the URL can point to anything you wish--to me this is one of the most flexibile aspects of APIs.json. The majority of APIs.json API properties are going to be to URLs designed for human consumption, but the ultimate goal of the project is to establish a core set of machine readable URIs that will help move the API discovery conversation forward. The first three machine readable properties for APIs listed in an APIs.json are: API Blueprint - The machine readable API definition format in markdown. Swagger - The machine readable API definition format in JSON and YAML...

Putting All Your API Resources Into Single Query Parameter Like Flickr Does

07 January 2015
When you use a well designed, and I hate saying it, but a RESTful API, you know it. I’m not a restafarian, who is super strict about API design, but I do know an easy-to-use, intuitive interface when I hack on one. Having API resources defined as intuitive URIs, with a handful of sensible header or query parameters, that allows me to excercise my HTTP Verbs, just makes me happy. I do not expect all API providers to be API design experts, but one design pattern that always frustrates me is when you pack all of your API resources into a single parameter. Flickr calls it “method”, and Brightcove calls it “command”, and while both of these media API providers then offer a rich number of “methods” or “commands”, I just can’t help feel this single design decision always detours API integrationa  down bumpier, darker side street or alley...

The Quickest Way To Proxy, Secure, Rate Limit, and Monitor My APIs

07 January 2015
As I am designing my APIs, one of the first things I decide is whether or not I will be making this public. If its a simple enough resource, and doesn't put too much load on my servers, I will usually make it publicly available. However if an API has write capabilities, could potentially put a heavy load on my servers, or just posses some private resource that I want to keep private, I will secure the API. I use 3Scale for my API management infrastructure--I have since 2011, long before I ever started working with them on projects, and organizing @APIStrat. When it comes time to secure any of my APIs, I have a default snippet of code that I wrap each API, validating the application keys, and recording their activity--which 3Scale calls the plugin integration approach...

Developer Support With Google Helpouts

07 January 2015
I was cruising around the Google Developer area and I stumbled across Google Helpouts. A service being billed as “Experts with Answers, Meet Developers with Questions”. Seems like a more one-to-one version of Stack Overflow, where you can get the answers you are looking for when it comes to development on the Google platform, but in a more direct, one-to-one way. Inversely, you can contribute your developer skills, and be one of the knowledgeable developers who are giving back to the developer community. The Google Helpouts page describes it as: Give Back - Continue Learning - Build Your Reputation. I signed up for an account, gave my profile, but the tags that I was able to connect with my profile really didn’t match my skills...

Connecting Our History At The Digital Public Library of America Using APIs And JSON-LD

07 January 2015
If I had to pick one API that I worship the ground they walk on, and yet for some insane reason I don’t write about very often—it would be the Digital Public Library of America. I can go on for days about how important the work that DPLA does. If you aren’t up to speed on DPLA, "The Digital Public Library of America brings together the riches of America’s libraries, archives, and museums, and makes them freely available to the world”—via APIs! ;-) I’m a history lover, so DPLA is extremely interesting, but what they do is so much more important to society at-large, an area that very few APIs can achieve. I am making an extra effort to publish more DPLA stories on API Evangelist, not just because they need it, but also because their approach to APIs is extremely forward thinking and relevant...

Server Skeletons In Restlet Studio And APISpark

06 January 2015
I was working in APISpark, playing around with different approaches to creating APIs for data stores i have in Amazon S3, Github, and in Google Spreadsheets. The cloud API deployment solution allows me to generate APIs from CSV, XML, JSON and spreadsheet stores in these locations, to a central API platform faster than I could even consider doing manually. As I’m managing a simple data API I have, I see the option to generate a “server skeleton” in the toolbar, something that is also available to me when working in the Restlet Studio. This is one of the benefits of creating machine readable API definitions like Swagger or API blueprint of your APIs. Restlet doesn’t generate server code for you from your file stores, it generates a machine readable definition of your file source, then lets you generate a “server skeleton” from that...

Reddit API Methods Listed Alpha or By oAuth Scope

06 January 2015
I was taking another look at the Reddit API over the weekend, and thought their listing of API endpoints was pretty interesting. They provide two ways of looking at the platform APIs: API Section - Listing of Reddit APIs by account, apps, links, listings, and other groupings. oAuth Scope - Listing of Reddit APIs by the endpoints oAuth scope. Not sure if it is something all APIs should follow, I just thought it was an interesting approach, something I haven’t seen in any other API area. Reddit has a number of APIs, I can see if you have specific goals with the API, this might be useful to have API sorted in this way.

API Evangelist In 2015

06 January 2015
In 2015, I will enter the 5th year of API Evangelist. To quote one of my favorite bands--“What a Long Strange Trip Its Been”. I couldn’t be more thankful for the career choice I made in 2010, and extremely grateful for the partners, and loyal readers I’ve established along the way. This list is very long, but I have to specifically call out 3Scale, and their support of what I do, without them API Evangelist wouldn’t be happening, I wouldn’t be doing my research, and open projects like APIs.json, and API Commons wouldn’t exist—additionally we wouldn’t be having the @APIStrat conversation that 3Scale makes happen. I’m not a big year end wrap-up or predictor type of guy, but this doesn’t mean I do not spend a lot of time reflecting this time of year...

Treating All Mobile Application API Usage Like It Is External

06 January 2015
I have read several stories about security breaches in the past couple days, ranging from exploitation of APIs across the distributed systems we are increasingly depending on, to no security at MoonPig for their mobile app, and the reverse engineering of a popular mobile app—this time it is the Kayak mobile app. Maybe I am biased, but I can’t help but think, in a world increasingly driven by mobile devices, we need to treat all applications like they are external, get to work seting up a proper API program, and secure all apps the same way, no matter whether they are used for internal, partner, or public usage. Treating internal apps differently, opens things up for a whole world of hurt when internal systems are compromised, and ignoring how public facing your API is, when embedded in a popular mobile app, goes into the same category...

Another High Profile Mobile To API Security Breach, This One At MoonPig Greeting Cards

06 January 2015
I saw a story of yet another security breach related to how mobile phones are using APIs today. This one is from Paul Price, on his blog ifc0nfig.com, about the greeting card site MoonPig. Paul highlights the not just lack of, but actual absence of security when making API calls to MoonPig, allowing you to impersonate any user, place orders, add/retrieve card information, and any other API driven feature of the mobile application. MoonPig is looking into it of course: We are aware of claims re customer data and can confirm that all password and payment information is and has always been safe. — Moonpig (@MoonpigUK) January 6, 2015 When those of us in the API industry talk about public APIs, many folks think we are talking about APIs like Twitter that have publicly available information, or public APIs that allow for anyone to sign up for the service, when in reality, most of the time we are talking about APIs that use the public Internet for transport...

Reverse Engineering Of The Kayak API From The Mobile App

05 January 2015
I am beginning to track on reverse engineering API story that I come across, so if you find any, feel free to share my way. If you aren’t familiar with this growing trend, I’m talking about the reverse engineering of APIs from popular mobile apps, specifically in situation where the company doesn’t have a public API or developer presence. APIs are driving the mobile applications tht we are increasingly depending on, but for some reason in 2015 not all companies expose, or share information about this API surface area with the public. The latest story I came across in this trend is the reverse engineering of the Kayak API using mitproxy. Once upon a time, there was a public Kayak API, but somewhere along the way it went away...

What Exactly Is APIs.json?

05 January 2015
As I travel around talking to folks about APIs, I spend as much time as I can, educating folks about APIs.json. In the course of my evangelism, I’m constantly reminded how little people, who have even heard, and read about APIs.json, really understand about what it actually is. With this in mind, I will be regularly publishing examples of what APis.json is, to help on-board everyone to Steve (@ngynx), and mine vision for APIs.json. APIs.json is an open format, in partnership between 3Scale and API Evangelist, to help API providers make their APIs more discoverable, assist API brokers in aggregating multiple APIs deemed valuable within specific industries, and ultimately empowering API consumers in finding exactly the APIs they need to be successful...

Your Secret Sauce Does Not Include Restricting Access To Your APIs

05 January 2015
Your company's secret sauce doesn't involve keeping your APIs closed and proprietary—it is about making them as open and accessible as possible, to the point where even your competition can’t help but uses them. I’m am always amazed at the amount of effort some companies put into hiding their API interface away, making me register before I can see anything, and dig through the SDK to even understand an APIs surface area. If you have a public API, or a publicly available mobile app, you have a public API—put it out there. Be loud and proud of your API designs (if you aren’t, then we should have another discussion), make them front and center, within two clicks of your developer landing page...

Our IoT API Is Available In Java, C++, and Node.js

05 January 2015
I am spending a lot of time lately reviewing Internet of Things (IoT) providers, as I work on a white paper for Gigaom. There are some very interesting approaches to APIs out there in IoT-land, and I’m starting to get a feel for some of the patterns, trends, and habits of how IoT providers are approaching their developer efforts. One pattern I see a lot, and can only assume it comes out of the hardware side of engineering, is a focus on programming language when you talk about your API--something I recommend shifting away from. In the world of web APIs, the focus on the interface, and what it does, and actual programming languages are abstracted away, and provided merely as samples, libraries, and SDKs...

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