{"API Evangelist"}

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

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.
  • The Mission API - Exposes operations for browsing and searching lists of mission, and retrieving single mission.
  • The Administrator API - Access to administrative resources including debugging, logging, and flight simulation.
  • The User API - Access operations for browsing and searching lists of user, and retrieving single user.
  • Authentication - Session operations for logging in and out, and identifying user.

The vehicle stuff I expected, but I was pleasantly surprised to see the resources around logging, and specifically the mission API. When it comes to transparency, and accountability around drone activity, I feel pretty strongly that these types of resources will be essential, and eventually will be mandated by government entities. I’m glad that 3D Robotics is ahead of the game, in providing API driven resources that deliver in this way.

What I didn’t expect, when I stumbled across the user and mission management APIs, was the social, online layer. As part of the 3D Robotics Drone API platform, the company offers DroneShare, where you can publish your user profile, and your missions. I was coming at this from the angle of a potential industry regulation tool, or possible drone pilot resource management—I didn't think it would be done as social, and potential entertainment platform.

Here is the description from the site:

"This is the beta release of Droneshare. Droneshare is a mission viewing and sharing application that works with ground control applications to let you share your mission data. This project is open source, if you would like to improve it, it is probably best to start at our github repo."

This is why I thoroughly enjoy doing my research, because it expands my understanding of specific business sectors that APIs are touching. While I was discovering DroneShare, I also learned about the existence of the "Don’t Fly Drones Here” project, from Mapbox, which provides a database resource of restricted zones, where you can’t fly drones. Which brought me back to my original thoughts, regarding what resource we will need to keep the drone industry sane, rather than just focusing on social and entertainment.

Ultimately I see a lot of patterns here, that reflect several possible drone futures we are potentially crafting. I see social networks, where drone pilots compete for the best jobs, based upon their missions, and equipment usage. I also see potential for entertainment--think about the networks that have arisen for watching people play videogames, and competitive gaming platforms, but apply that to the world of drones. I also see potential elements of government regulation, where the FAA and other agencies, require drone pilots to log their equipment, and activity, logging all drone flights, and potentially sharing publicly via drone social networks to increase accountability.

In the end, I’m thinking that the 3D Robotics Drone API provides a potential blueprint that could be used by other drone manufacturers, and cloud platforms that serve the drone industry. The 3D Robotics Drone API pattern could be held up as an open specification, that the government could weigh in on, making sure the proper regulatory resources are available, and that drone activity can be accessed, and audited via a secure API, available via the Internet.

The world of drones is fascinating to me. On one hand, the security and privacy considerations scare the shit out of me. On the other hand, they are endlessly fascinating to me, and ultimately I’m going to be purchasing a drone, so I can play with more, and understand better—its a business expense you know!

Man, I have a great career. I'm so privileged to be doing what I do—even if our world is under a threat of attack by drones!

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

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.me user portal, for device consumers and would-be developers to easily on-board with everything. I haven't fully profiled that Myfox platform, but at first glance it is clean, well laid out, and most importantly the link between the website, API, and user accounts is clear, and easy to navigate.

As I think this through, and after recently finishing a white paper called Building an API-driven Ecosystem for the Internet of Things, for the now defunct GigaOm, I can't help but think the IoT space is going to need to agree on some sort of standard approach for not just managing how they design, deploy, and manage APIs, but also how they deliver developer and user portals. To help you visualize what I mean, consider the number of Internet connected devices any single household will own, all with their own portal, and on-boarding process. #FUN

In short, developers, and end-users will get IoT account fatigue pretty quick. I don't think that we are going to standardize everything across the space, I am not delusional, but I can't help but think that the sharing of some common blueprints, could go a long ways in reducing friction for developers, and device consumers. I'll take my research from the GigaOm white paper and produce a blueprint, that IoT device makers can use, to to hopefully be more successful in deploying their developer portals, platform accounts, and maybe help influence a tiny bit of consistency in how IoT platforms function.

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

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.io From SendGrid
CloudBreak From SequenceIQ

The machine readable API Blueprint definition, driving the documentation now has the potential to be accessible. This may not seem like much, but it is actually fundamental to the health, and growth of the overall API industry. Developers cannot learn from other developers, and from leading API platforms, and share best practices for API design across the space without it—we need this to grow, and evolve.

This is one of the reasons Swagger has seen such wide adoption, because it isn’t just an open format, it is also because the API definitions that these public platforms generate are also available to share, and learn from. You can still lock down the valuable resources made available via an API, but the interface patterns we apply to our APIs should be shared as widely as possible, for everyone to see. This is why I’ve been fighting so hard to push back against Oracle in their API copyright case against Google—API designs do not need to be locked up.

I’ve been able to find API Blueprints on the open web, and on Github for some time now, but this opens up the playing field to be able easily discovery, and engage with existing Apiary, and API Blueprint driven APIs at a new level. Much of what I’ve learned about Swagger and API design has come from being able to click on the raw link on Swagger UI, and reverse engineer the Swagger definition behind the curtain. I’ve never been able to do this with API Blueprint, or Mashery I/O docs. I have been able to get at the WADL behind the Apigee Explorer, but it is a pain in the ass, and the definitions are usually out of date by the time I get to it.

The effects of Apiary’s move won’t be some immediate thing, it will take time, but the more API Blueprints that are shared, the more users will learn about the powerful API definition format driving many public APIs—this is good for Apiary, good for API providers, and good for API consumers. Thanks Apiary for doing this, it makes me happy. It also gives me a head start on making sure my API Stack is API Blueprint fluent, and that more API Blueprint driven APIs are present in my research.

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

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:

That is all the speaking I’m doing this spring, with one tentative date early in June at BYU. I won’t be traveling again until the fall, when we do @APIStrat again, and of course @DefragCon!

I’m excited to be in Berlin and Barcelona, two of my favorite European cities, and of course Broomfield, CO (specifically the Taproom). I am also excited to not be traveling as much, and able to focus on my wider research, coding, and writing. #thanks

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

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. I’m sure this thought scares the hell out of some companies, who can’t imagine, allowing outside input like this, but if you sit down and think about it for a while, it just might make sense.

When I was in Washington D.C., I created a default portal template that runs on Github. I might upgrade this, and make it available for API providers to use as a forkable template, to seed any API developer portal. Doing this makes it easy to provide a base set of building blocks that every API provider should start with, allowing them to delete the elements that they don’t want. I am also considering making a default one, that can be used as a starter developer portal for Internet of Things (IoT) platforms.

I thoroughly enjoy the pull requests that I get for spelling and grammar mistakes I made on API Evangelist, from some of my favorite grammar trolls. Running all of my websites on Github Pages has changed the way I tell stories, and interact with my audience. I’ve always encouraged API providers to use Github for an increasing number of API management tasks, but actually running your entire portal as a Github repo, would this to a new level. This approach could be used for larger, or smaller developer platforms, and I even use Github pages as a front-end for private API developer portals--ask me how.

It is just a suggestion for you API providers, and soon to be API providers. Github provides a very low cost, scalable way to launch your portal, and you never know, people like me who spend a lot of time in your developer portal, might actually help make it a better place. I wish more API providers would publish their portal as a Github repository, as well as graphic designers in the space help craft template portals, that providers can put to work. My portal definitions will always reflect best practices that I see across the API landscape, but they won’t always be the slickest looking when it comes to graphic design—just not my core competency.

Combined Calls: Monetization Through The Bundling Of API Calls

I was doing my regular monitoring, and found myself on the AlchemyAPI site. Not exactly sure how I got there, but I stumbled across their HTMLGetCombinedData API, which can be used for analysis on HTML content, and is one of 3 separate APIs, AlchemyAPI is calling "combined calls".

If you aren’t familiar with AlchemyAPI, the company has a number of valuable APIs, which you can use to make sense of content and data from on, or offline source. I use AlchemyAPI for API Evangelist, to pull keywords, and the content out of blog posts, helping me shed the overall look of a site, and any advertisements--getting down to the raw content. What I thought was particularly interesting about this API, was their approach combined calls, and specifically their approach to monetizing these aggregated API calls.

There are three specific APIs they are considering "combined calls":

These three APIs are only available in the AlchemyAPI pro and enterprise packages, which for me makes see this aa a potentially new approach to API monetization. I don’t see it as something that works for all API providers, but when you have numerous decoupled APIs, which developers may also be implemented several of them at a time, or daisy chaining them together—a combined API call, might save some developers valuable time.

Combined API calls also seem like a potential opportunity for API platform developers themselves. If an API platform, provides tools for developers to aggregate, and stitch together multiple APIs, and publish their recipes, it is something that could produce some interesting patterns, that may better deliver solutions to the problems developers actually face during integration. At the very least, allowing developers to publish SDKs that accomplish the same thing, might achieve the same thing.

I am just looking to share my thoughts on AlchemyAPIs approach to aggregating their API calls, and specifically the focus on monetization, adding the concept to my research. Maybe it is something others can for their API platforms, or maybe API developers, could provide aggregated API recipes, for specific API platforms, or across multiple platforms.

Weekly API.Report For April 6th, 2015

My Weekly API.Report represents the best of what I've read throughout the week, and is only what I personally felt should be showcased. Each news item comes with a link, and some thoughts I had after curating the piece of API related news. I'm trying to break down stories into as coherent buckets as I can, but it remains something that is ever changing for me, but ultimately I will settle on a clear definition for each of the research areas.

Always a good report, when I start with 101:

More on the legal side of 3D Printing, than API:

An interesting Account Management feature:

A handful of interesting Acquisitions to note:

I'm see more Analytics related items like this focused on gaming lately:

I'm calling these API Aggregation, but they are kind of a new take on the topic:

  • AlchemyAPI Web Combined Call - I thought this was an interesting approach to monetizing APIs, by saving developers time. In a world where you have a bunch of microservices that do one thing, and do it well, I think aggregate or combined API calls ike this as premium service will be more common. 
  • AlchemyAPI Text Combined Call - Seems to be something they are doing across the board. Will keep an eye out for others doing this too.

This reflects some of the API Broker style broker I"d like to see more of:

More movement on API Definitions, and not just Swagger, some pretty nice moves from API Blueprint last week:

Handful of API Deployment resouces this last week:

API Deprecation rumors and misconceptions out of Fecebook:

The API Design advice for the week:

The always evergreen topic of the API Economy:

A single, slick approach to API Evangelism:

Couple of API Event related items this week:

Some API Integration insight from SalesForce:

The growing area of API Lifecycle discussion:

Lots API Management moves to evaluate from the last week:

Some very different looks at API Monetization:

An API Monitoring discussion:

The other API News from the space:

A single API On-Boarding story, to showcase how NOT to on-board:

Some API Performance thoughts from Restlet:

Some API Reciprocity stories from the private and public sector:

The growing area of API Testing:

The only lightly touched on area of API Virtualization:

  • Patterns of API Virtualization - I think API virtualization is interesting, but it is hard to help people understand the potential. I'm thinking there needs to be a lot more examples, and storytelling before they become common practice.

An interesting API blip in the world of Architecture:

The PopUp Archive team rock'n the Audio discussion in my roundup:

Pulling out just the area acuqisitions area, and look at in terms of Authentication:

 I just couldn't resist putting this one in the Automobile area:

The Banking conversation keeps on heating up:

The ever enjoyable general bucket of the Business of APIs:

Two things to look at on the Internet connected Cameras front:

Where I place Career related items:

I'm putting this under Censorship, even though it might also be legitimate use cases:

An interesting API related Certification item:

  • An Open Can of Tin Badges - Tin Can API - Not quite certification for APIs, but an experience API driven badging and certification. So you could craft specific API experiences, using the Tin Can API, and have the result be a badge delivery. 

A Chat story out of the business social network world:

Just a single City Government story this weeK:

Some expansion, and contraction from the world of Cloud Computing:

Two Cloud Storage stores that barely caught my attention:

A single, important Commerce story:

The Containers bucket is pretty small this week:

Diverse number of Content related items this last week:

A single County Government too:

A number of Data nuggets this last week:

And directly Database related:

I am seeing a consistent uptick in number of Device related API approaches lately:

DNS is so important to all of this working:

Two takes on the Documents when it comes to Dropbox:

Only a handful of Drone related stories I felt were worthy enough to discuss:

Kind of sort of some Education stuff:

A single Email item:

Some Embeddable thoughts:

An Encryption talk in the messaging world:

APIs in the Federal Government:

Couple of Hackathons to showcase:

I love having Hacker Storytelling items to showcase:

Two Healthcare stories:

A single, weird Home story:

One item to note in my IDE related research:

Two International items:

Internet of Things is kind of tame this week:

JavaScript wisdom from the week:

Yes! Libraries:

IBM continuing to dominate Machine Learning:

A single Mapping item out of Google:

Media related items in the news:

Messaging talk:

A single Microservices tale:

A handful of Mobile to aggregate:

A single Museums story:

Some thoughts from the world of Music:

Love the Outdoors news:

A single Partner story to note:

Payments not as hot this last week:

A robust Politics of APIs tag this last week:

Some helpful, and some frustrating Privacy discussions:

Good to see more API discussion in the world of Real Estate and Mortages:

The Real-Time discussion always dominated by PubNub with their kick ass content:

Security discussions I am watching:

A cool Showcase out of the Noun Project ecosystem:

Some Shuttering of companies in the cloud space to note by itself:

The every fascinating Single Page Applications how-tos:

Adding a single Software Defined Networking item, cause it has good content:

I love anything out of NASA that is Space related:

Isolating this again as a Speech related items, because it goes beyond just machine learning:

Big, big week for Spreadsheets:

And a single State Government item to cover each level of government this week:

Busted out Telecommunications, to show how stunted the industry can be:

Not as much Transparency talk this last week, but a handful to showcase by themselves:

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

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.

We have done a decent job of providing resources to data stewards, helping them deploy APIs using spreadsheets using services like API Spark, but other than a handful of innovative implementations from companies like Octoparts and Twilio, there are no solid API consumption resources that target the spreadsheet environment. Meaning there is no easy way for mainstream spreadsheet users to put common API driven resources to work for them within the spreadsheets that they live in daily--that is until today, with the launch of the Blockspring launched their Google Spreadsheets Add-On.

Yeah I know, making APIs work in spreadsheets has been done for a while, via Google Spreadsheets and Excel Spreadsheets, but nobody has standardized it like Blockspring just did. So let’s take a quick look at the implementation. I went to the Google Chrome App Store, and downloaded the add-on.



Then using a new spreadsheet, I click on add-ons > Blockspring, and logged into my account. After giving Blockspring access to the Google Spreadsheet via my Google Account oAuth, I was given an API console in the right hand sidebar of my spreadsheet interface. The API options I’m given aren't the usual geek buffet, they are everyday use scenarios that would attract the average spreadsheet users.


I select the IMDB movie search, which once chosen, I’m given the option to populate my spreadsheet with results, providing me with API driven resources, right in my worksheets. The best part is it is complete with one cell as a search term, allowing me to customize my IMDB search.

Using Blockspring, I’m given easy to use, API driven resources, that anyone can implement, like visualizing the recent news:

Or possibly evaluate stock volatility clustering, using stock market data APIs (cause you know we all do a lot of this):

Blockspring gives me over 1000 API driven functions that I can use in my Google Spreadsheet—kicking everyone’s asses when it comes to potential API client delivery. While us technologists are arguing over whether or not we can automatically generated Swagger driven SDKs, and the importance of hypermedia APIs when deploying the next generation clients, someone like Blockspring comes along and pipes in APIs to the #2 client in the world—the spreadsheet. #winning

Now the game will be about getting the attention of Google Spreadsheet users, and developing comparable Microsoft Spreadsheet tooling, and getting mainstream Excel users attention as well. The rest of you will have to get the attention of Blockspring, and make sure your API resources have simple, meaningful endpoints that can be piped in as Blockspring Google Spreadsheet functions. Spreadsheet driven business units should not have to learn about APIs and go look for them, at each individual API portal—APIs providers should find and education business users about their resources, via one of the most ubiquitous tools in business.

Nice work Blockspring, in helping ensure the space move beyond excel as a data source for API deployment, and focusing on it as an API client, delivering vital API resources to the business users who can potentially benefit the most, and are willing and able to pay for API access in my opinion.

P.S. As soon as I finished this I remembered this story from last weeks API.Report Free Federal Energy and Economic Information Delivered Straight to Your Spreadsheet - not an standardized approach, but definitely an important implementation to showcase.

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

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.io is doing for apps—delivering on one of my ongoing ideas for caching high use APIs.

When I was working in Washington DC, I had the pleasure of working during the federal government shutdown, where I wrote a piece asking if we can depend on our federal government APIs, and talked about caching APIs with AWS cloud formations, or Open Shift. My objective is to ensure there redundant sources for APIs coming out of government, providing developers with a more stable solution, they can depend on. I even added this thinking into the early APIs.json design, allowing you to define cached indexes of APIs.

I’ve added StreamData.io to my real-time research, and I’ll get in there and play with more, as I have the time. Then I’ll get a better understanding of what you can do with the API caching and syncing, seeing if it is possible to deliver this layer for my APIs as well as my apps—something that is even more appealing in this age of Docker containers. #FoodForThought

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

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. In short, key management isn’t easy, and there are no clear solutions that serve both ends of the key management coin.

As an API provider, I use 3Scale API Infrastructure to manage my API keys. Using my API portal, developers can sign up for their own accounts, manage their apps, and the keys that are issued. 3Scale does all the heavy lifting for me, all I have to do is manage my API service composition, and keep an eye on dev usage, as well as keep an eye on my own app usage. I use all my own APIs for my apps too! Sometimes my apps are the bad actors, it not always the developers who abuse API access. 

As an API consumer, I’m working hard to pull my API key world together, using a home brew format I’m calling simple api-keys. I’m am using Github for all of my API and microservice related projects, so I’m beginning to centralize how I store keys, and how I manage them across all my apps. With a central storage, and management process, I’m hoping to get a better handle on which APIs I use, and introduce more regular cycles of key management, where I refresh API keys on a strict schedule.

With the work I’m doing on the API consumption front, and reading Daryll’s post got me thinking about keys. If our API management house is in order, and we can manage different groups of API keys, monitor their usage, and revoke them at will, why can’t we just have a pool of API keys that we can just leave laying around? I’ve seen many APIs provider default keys, embedded in URLs available in API documentation, allowing you to make sample calls, why can’t we apply this a little bit wider? It seems like we could have a rolling pool of API keys, that we leave laying around in code snippets, how-to guides, and stories, which allow instant access to APIs—which we monitor, and if we see abuse we can revoke, and refresh with new set--easily done if you use Github Gists for storytelling (snippet centralization).

I’m going through my entire API stack, and generating Postman Collections, and I’m considering generating some API keys that are designed for use in specific stories, 101 resources, and other public and private evangelism efforts. It is just a thought at this point, that I wanted to put out there for discussion. Seems to me, if we really want to reduce any friction in on-boarding, we could start using “some” API keys in conjunction with SEO, SMM, and other existing evangelism metrics and analysis tools that are in our toolbox.