{"API Evangelist"}

Weekly API.Report For March 30th, 2015

I swear 3D Printing is continuing to cross over in some interesting ways:

Interesting week for acquisitions in my opinion:

Seems like agriculture is a continuing trend:

Several diverse areas within analytics caught my attention:

Some API aggregation tidbits:

Helpful API debugging assistance from Splunk:

Big shifts in the world of API definitions:

Some API deployment advice from this week:

Valuable API design from this week:

Keeping developers up to speed with a little API evangelism:

Some API events activity (mostly from my events ;-)

Great API lifecycle guidance out of Nordic APIs:

  • The Entire API Lifecycle - I think I'm going to break these lifecycle discussions into their own area. Normally I put under business of APIs, but recently some of the conversation is elevating way beyond just business.

Lots to highlight from API management this week:

Also some interesting API monetization chatter:

Some good API monitoring leads from this week:

I am not the only one busting out the good API news:

API performance is something I'll be breaking out more as well:

Big moves fro Talend in the area of API reciprocity, and I guess cloud storage:

Like seeing talk on API stability:

Previoius weeks have been a lot of talk by me, but this wee there were two amazing visualization discussions:

Two interesting authentication pieces: 

Thoughts on automobiles:

The banking chatter I felt worthy of higlighting:

I am tracking more on blockchain now too:

Bots can be fun to throw in as well:

Browser APIs are normal, but I'm keeping a closer eye on to educate myself:

The infamous area called the business of APIs:

Oh the magic of cameras with IPs:

Two API career paths to highlight this week:

From the city government front:

Hard to tell who is winning when it comes to cloud computing:

Some interesting cloud storage specific items too:

Have to look at comments out of Facebook:

Ony a handful container related stories this week:

I will try to push more content to Tumblr as part of my evangelism work:

A single conversion story to share:

  • Parsing EDI to XML (and vice verse) - I was doing some Swagger conversion tools, and came across this simultaneously doing my monitoring. figured it was interesting enough to track on for future reference.

Paying our respects to cURL:

At the cybersecurity front:

Data is always a big thing:

The conversation around the data center continues to grow:

Two database items caught my attention:

Couple of deprecation items flagged as part of story:

Devops creeping into the mix:

And like that, drones are on the menu:

I'm hoping for a lot more election data and API activity in the future:

An interesting email integration between platforms I track on:

The coverage of embeddable comments at Reddit:

Encryption love from aWS:

Some great energy stories this week:

Focus on the enterprise:

The super fun area of facial recognition:

The news worth discussing out of the federal government:

Three things caught my eye in the financial space:

Look fitness from the gaming console!

Hackathon news that makes me happy:

Some of it is more IoT than healthcare, but still pretty robust this week:

A single, very cool hotel related story this week:

IDE space is coming into focus when it comes to APIs:

Good ideas are contagious in the API space:

Keeping an eye on the international picture:

  • Data Protection Around the World - More great stuff coming out of DataSift, and this time an important international view of things. Something we are going to need to be more educated on.

The always active Internet of Things (IoT):

Investment blips on the radar:

An important discussion about the legal system in our country:

Libraries stories are the best:

Location is critical:

Pulling back the machine learning curtain:

Some mapping activity I followed this week:

Media is one area Microsoft is kicking butt in:

Mostly about Facebook messaging, but a handful of stories from the week:

The always fun microservices conversation(s):

Mobile chatter:

Museums stories too!

Love this music item this week:

Two new APIs to highlight:

From the mainstream news space:

Telling partners is critical to the space going round:

Some good, some weird patent news:

Strong week for payments:

No really API, but photos are key to what I do:

Interesting police stories this week:

Several fronts from world of politics:

Stories from the Politics of APIs:

A lone printing story:

Lots of privacy chatter to discuss:

Some more protection stories this week:

Two real-time thoughts from the week:

The area of Reclaim Your Domain is an area I showcase much, but track on all the time:

An eye on regulation:

API providers, make sure and provide resources like a calendar of events:

A fat SDK section this week:

Lots more security news, as expected:

Semantics isn't something you see often in my coverage:

I track on sensors, or they'll track on me:

Can't tell whether this is a thing, or anti smart meter propaganda:

  • Smart meters – not so smart - An interesting take on smart meters not working, and biggest the first casualty of IoT hype. Not sure I subscribe to everything that he lays out, but definitely think we should be skeptical. I will keep an eye out for other examples supporting or against these thoughts.

Some interesting spreadsheets related items to discuss:

Yes, some state government news I can showcase:

Couple of transparency items that caught my attention:

Obligatory Transportation story:

Showcase the two-factor authentication so it becomes widespread:

Video talk from several of the big API players I track on:

Hacking the wearables this week:

Quantifying The Community Around The Swagger API Specification

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 though Swagger is machine readable, and designed for other applications, it has also become a language for humans to describe and collaborate, around a shared, quantifiable, vision of what an API can do, throughout all stages of the API life cycle. 

If you want to learn about Swagger yourself, you can tune into these channels to learn more:

My goal with this post is evolve my understanding and awareness of what Swagger is, and hopefully along the way I can help increase yours as well. In my experience, many people have a very distorted, and limited understanding of what Swagger is, and I’d like to take some time to evolve that. When I started this research, my objective was to help Tony deliver a new website, and on-boarding materials for Swagger, assisting people of all skill levels in finding all things Swagger. I am just taking this moment to walk through what at I have so far, and craft a more robust version 1.0 narrative about what Swagger is, something that blogging helps me work through.

One of the biggest misconceptions I find when I talk with folks about Swagger, is that it is interactive documentation, when that is actually Swagger UI--when it comes to Swagger all roads start with the Swagger specification:

  • Swagger-Spec - The goal of Swagger is to define a standard, language-agnostic interface to REST APIs which allows both humans and computers to discover and understand the capabilities of the service.

You can find version 2.0 of the spec here, which is the current active version in use. The Swagger spec lets you describe all the essential aspects of API operations, with information about the operator, the host and basePath for the API, details about what type of content it produces or consumes, like JSON or XML. Most importantly it lets you describe each of the paths for an API, with details on parameters, responses, and other details of each specific API path. Swagger also provides you with the ability to describe the underlying data model definitions, describing the valuable resources being served up via APIs.

To grasp the last paragraph, you have to have a pretty solid understanding of the moving parts of an API, but in short the Swagger spec gives us a language to potentially map out all of the common parts of an API. It also allows me to describe the security for each API, and tag to organize APIs into specific buckets. I use Swagger to describe the almost 20 APIs my business uses daily, with varying amount of detail about each resource, and the information it serves up. All the 20 of the Swagger definitions provide me with a machine readable map of my own IT infrastructure—as well as a common language that almost any other developer, or potentially not developer can learn to read, and work with.

With Swagger we now have a common way to communication around the APIs we develop, and also map out the public APIs we also depend on like Twilio, SendGrid, or even Twitter. Now what? Why do we do this? There are an increasing number of incentives emerging for why you generate machine readable API definitions like Swagger, which is part of the reason I’m looking to further quantify the Swagger community, so I can add to the master list.

Let’s start with what I’d consider to be the primary building blocks of Swagger, developed by the Swagger team, as part of the core offering:

  • swagger-ui - Generation of interactive API documentation, which Swagger is often known for.
  • swagger-codegen - Generation of client code in a variety of languages using a Swagger definition.
  • swagger-js - A JavaScript library to connect to swagger-enabled APIs via browser or Node.js.
  • swagger-socket - A REST over WebSocket tool for creating real-time integrations with Swagger.
  • swagger-node-express - Swagger module for Node.js w/express module
  • swagger-scala-module - Swagger support for Scala.
  • swagger-editorA visual editor for Swagger.

Those six repositories represent the core tooling that the Swagger team has evolved around the specification, providing what I’d consider to be three stops along the API life cycle:

  • Documentation
  • Server Code
  • Client Code

Swagger is often known for its interactive API documentation (aka Swagger UI), but there has also been a lot of work done on the codegen platform, and editor, taking things well beyond just API documentation. This is just the beginning of what is possible with Swagger. In an effort to find out what else is being done with Swagger, and what is being built with the specification, I wanted to see what the community is up to, which platforms they are integrating it into, and what other standalone tooling is being built using Swagger.

I want a better understanding of the core group of companies who have embraced the Swagger specification, and baked it into their own platform. I know there are hundreds of them out there, but finding them can be easier said than done, especially when I'm looking some sort of public announcement, blog post, press release, service description, to use as my reference. So far I have 49 companies that I’m tracking on, who have pulled the Swagger spec, and incorporated into their own platform and infrastructure.

3scale (reference)

Akana (reference)

Apache Apollo (reference)

Apache Camel (reference)

Apigee (reference)

Apigility (reference)

APIMATIC (reference)

apis.io (reference)

APIs.json (reference)

APItools (reference)

AppNow (reference)

Ardoq (reference)

Axway (reference)

Beego (reference)

Catch Software (reference)

Cloud Elements (reference)

Django REST (reference)

DreamFactory (reference)

elastic.io (reference)

Espresso Logic (reference)

Gluu (reference)

IBM (reference)

Magnolia CMS (reference)

Microsoft Azure (reference)

Neo4J (reference)

Netflix (reference)

Nomos Software (reference)

Open311 (reference)

OpenDaylight Project (reference)

OPENi (reference)

OpenShift by Red Hat (reference)

Pivotal (reference)

Postman REST Client (reference)

Quandl (reference)

REST United (reference)

RESTBase (reference)

RESTFiddle (reference)

Restlet / APISpark (reference)

Sandbox (reference)

Service Stack (reference)

SmartBear Software (reference)

SnapLogic (reference)

StrongLoop (reference)

Synapp.io (reference)

TIBCO Software (reference)

Visual Studio (reference)

WaveMaker, Inc. (reference)

WSO2 (reference)

Yelp (reference)

This list represents a pretty interesting mix of folks who understand the potential of Swagger, and have invested in the community by making it a core part of their operations. I know there are more of these out there (a lot more), but they haven’t talked publicly about what they are up to. This is just what I’ve aggregated from going through the Swagger site, group, and Github repositories, and from what I already know of the API space, from my monitoring.

After looking at the platforms who have pulled the Swagger specification into their operations, I wanted to see if I could also begin to quantify the community of APIs who have deployed Swagger UI, providing interactive API documentation for their own API platform. Since this is what Swagger is known for, I knew I would find quite a few to showcase. So far I have found 62:

World Population Project (reference)

3scale (reference)

ACI Blog Index (reference)

API Evangelist (reference)

API2Cart (reference)

AppSpin (reference)

Banckle (reference)

BetISN (reference)

Bitdango (reference)

BitTitan (reference)

CallFire (reference)

Carnival Mobile (reference)

CDScience (reference)

CityGro (reference)

CitySDK (reference)

Clarify API (reference)

Climate Change Costs (reference)

Cloudify (reference)

CommaFeed (reference)

Concur (reference)

DataValidation API (reference)

Datumbox (reference)

DreamFactory (reference)

DroneKit (reference)

Evercam (reference)

Expedia (reference)

fanart.tv (reference)

Formagg.io (reference)

GeoTrellis (reference)

Getty Images (reference)

GroupDocs (reference)

Guru (reference)

HabitRPG (reference)

hapi.js (reference)

Kubernetes (reference)

League of Legends (reference)

League of Legends eSports (reference)

Likibu (reference)

Mobovivo (reference)

Mozilla Open Badges (reference)

MuckRock (reference)

MyFox (reference)

MyNeighbor (reference)

MySMS (reference)

Pingup (reference)

Pop Up Archive (reference)

Project Chronos (reference)

PTisp (reference)

Puppet Labs (reference)

QI Bench (reference)

Rackspace (reference)

ReliefWeb (reference)

Sensr.net (reference)

Shoeboxed (reference)

Skimlinks (reference)

Subledger (reference)

TaDaweb (reference)

taxamo (reference)

The Resumator (reference)

UK Commission for Employment and Skills (reference)

Wordnik (reference)

YunoHost (reference)

Finding websites that have implemented Swagger UI is harder than you think. There are only three search engines I could find that let you search the source code of websites for JavaScript files and code. Ultimately I ended up mostly depending on my own ability to find new APIs, and manually uncover whether or not Swagger was actually in use. I’m working on a stack of Swagger and API Blueprint discovery search engines, but they aren’t quite ready for this dive.

Next I wanted to look through some of the tooling that has evolved as part of the Swagger community, which Github is definitely the place to begin this journey. When you search Github for the word Swagger, you get almost 1000 repositories. I was going to programmatically explore these results, but found that manually browsing through them was the best path to take, allowing me to make a decision on what each developer was up to.

The one thing I learned doing through this process—Swagger means many different things, to many different people. Most refer to Swagger, and mean Swagger UI, while others refer to it as generating server side code, or maybe client side code. Moving forward, there needs to be a lot of work done helped educate people about first, what Swagger is, a specification, and what are  each of the areas of tooling that are built on top of the Swagger specification.

Even after looking through the almost 1000 Swagger related Github projects, things are still very hazy for me, but I did learn a lot along the way, about what languages, frameworks and platforms developers are using Swagger, and the types of tools and integrations they are developing.

The best way to look at all of these projects is by language—here is the Github breakdown.

  • 411 JavaScript
  • 135 Java
  • 61 Ruby
  • 41 Python
  • 32 PHP
  • 31 Scala
  • 22 C#
  • 17 Shell
  • 13 Clojure
  • 8 Groovy

This isn’t accurate, because many of the JavaScript repositories are actually other languages. I forget to make sure Github knows what language a repo is sometimes too. Regardless, it gives you an idea of which programming languages developers are using to work with Swagger—one layer to look consider.

Beyond the programming languages I want to know which platforms and frameworks developers are applying Swagger. Here are 36 frameworks and platforms I’ve identified so far.

AngularJS (reference)

Apache Ant (reference)

Apache Camel (reference)

Apache Maven (reference)

Apache Wink (reference)

ArangoDB Foxx (reference)

BackboneREST (reference)

CakePHP (reference)

CKAN (reference)

Django REST (reference)

Django Tastypie (reference)

elasticsearch (reference)

Express (reference)

Feathers (reference)

Flask (reference)

Flask MongoRest (reference)

Flask Restful (reference)

Gradle (reference)

Grails (reference)

Grape (reference)

Grunt (reference)

Guzzle (reference)

Jersey (reference)

Laravel (reference)

LINQPad (reference)

MongDB (reference)

Nancy (reference)

Pyramid (reference)

Salesforce (reference)

Sequelize (reference)

Silex (reference)

Sinatra (reference)

Spring (reference)

Symfony (reference)

Tornado-JSON (reference)

Veneer (reference)

Beyond the programming languages, frameworks, and platform integrations I’m looking to also understand the types of tools developers are actually building, and take Swagger beyond what the core development team, and working group could do. It is hard to understand the objectives of each of the developer projects I came across, but here are the X areas I’ve identified so far:

  • Converter
  • Generator
  • Parser
  • Schema
  • Validator
  • Server
  • Command-Line
  • Powershell
  • Client
  • Proxy Generator
  • Aggregator
  • Tester

This added a couple stops along the API life cycle for me, that Swagger is serving. I hadn’t envisioned a Swagger powered CLI or Powershell tool. I’ve only lightly thought about proxies, and aggregators driven by Swagger. When you bundle this with the platforms above who have integrated Swagger into their products and services, it starts to paint an even bigger picture of what is possible with Swagger.

I think I’m going to wrap up this dive into the Swagger ecosystem here. I still have all of the contributors, watchers, and people who have forked the core Swagger products, and well as many of the people involved in Swagger discussions via the Swagger Google Group and Twitter account to consider. Plus I think this article will flush out some other projects that are out there, being executed by my readers. Storytelling along the way is the best way to flush out hidden details in my opinion, and is one of the main reasons I’m so transparent--I depend on people emailing and tweeting at me about stuff.

This exercise has given me a new perspective on the Swagger community, and introduced me to some new companies, and tools. If you are doing anything cool with Swagger, please let me know, and I’ll add it to my research. Remember, if you don’t tell the story about what your are doing with APIs, nobody knows, including me—API evangelism 101. This is just my first attempt to better quantify the Swagger community, and I’m happy to include what you are up to in future updates.

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

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.

It is my mission to find these signs across the API landscape, and keep an eye on what they are doing. One platform that is now open for beta is Amazon Echo. Amazon says, "Echo is designed around your voice. It's always on—just ask for information, music, news, weather, and more.” APIs are how we will deliver on the “more” part of this equation. The difference between Apple Siri, and Amazon Echo at this point, is Amazon will let you (API providers) help deliver on the “more” part of Amazon Echo discovery equation.

I’m signing up for the beta, and if I get access, I will share more stories. I encourage you to sign up as well, and if you have any work your doing with Amazon Echo, or know of other API driven voice-enablement platforms I should be paying attention to, let me know.

Even More Pondering On My Microservice Definition

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. However, It is a good reminder to make sure all of my services have a vCard applied to their APIs.son file index. It is important to easily known who is responsible for any public or private API, and with APIs.son and Swagger, this is easy to do.

When it comes to minimal dependencies, this gets a little tougher for me. My world isn’t too bad, because my systems are small, and I’ve been the only developer. The down side is I’ve been the only developer, and I’ve bee lazy about how many dependencies an API might have, and also been fairly sloppy about how I integrate with 3rd party APIs. Adding this item to my list will help me keep an eye on how I establish dependencies between services, keeping them minimal, and well documented.

That is it, I just wanted to add ownership and dependencies to my list of considerations—I just like making a production out of everything.

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

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.

DroneKit has a web API defined using Swagger, which is the first Drone API I have actually added to my system. I am sure there are more out there, and now that I’m tracking on closer, I'm sure I'll find them. The number of drone related stories that flow through my feeds is getting pretty out of control, and I'm thinking the space needs some standard approaches to APIs identified, to help develop better drone solutions, but also potentially inject some transparency into this growing layer of IoT.

Now that I have an API blueprint for a drone API, in Swagger too! ;-) I will be able to start thinking about what some of the API patterns for drones might look like, and what some of the common building blocks might be for managing the technical, but also business, and political side of drone operation. I’m thinking that when it comes to drone operations, APIs might not just be a nice to have, they might be something that becomes mandatory in trying to bring this fast growing, not well defined space, under some control.