03 Mar 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.
Keran gives an energetic talk, but it wasn’t just the high energy that sold it for me, it was demonstrating that he actually gives a shit about how to do it right, admitting he doesn’t know everything, or nails it in all categories, and he gives an honest, friendly, approachable, and genuine story of what is API evangelism at MYOB.
This approach to API evangelism is critical to success. You won’t last long as an evangelist if you are full of shit, or the company behind you is, sorry—I’ve been in this position too many times. Don’t get me wrong, every API evangelist role is difficult, and full of compromises, challenges, and things that are out of your control—even in my world. In the end, the only thing you can do is be honest, genuine, and as transparent as you can, and never be afraid to tell you story like Keran does.
03 Mar 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. In short, these sites suck. Their UI is crap, and their search mechanisms are shit.
The biggest problem with these news outlets do not usually even have RSS, let alone an API, requiring me to go to each site, each day, and sift through the search results. The world of press releases is like many other industries I engage with—needs a dead simple API driven solution. I want a press release API that allows any company to submit for free, but the problem is nobody will in the beginning, so it also needs to go out and find the direct corporate press sources as well, and scrape this long tail of the PR world.
I’d pay a monthly fee to be able to search this vast PR database via an API, and be able to integrate directly into my API monitoring system. It is something I could build, but I just do not have time, and as I do with my other ideas, I am putting out there for someone else to do. The API would be a very simple design, but the legwork to make it truly a rich, and valuable source of press, would take a significant amount of time.
This is one of the ideas I hope someone does not do, thinking it is a VC level start-up idea. It really is something that a handful of folks could bootstrap, and do very well in monetizing premium services, but if you go get VC money you will probably fuck it all up, and have to chase some unnecessary approaches to making money. If someone doesn’t do soon, I’m going to have to build an API focused version, because I am spending about 1-2 hours a day on this each day.
02 Mar 2015
I am a couple days late on this weeks API.Report, after being sick last week, taking the weekend to recover--at least I got it done. The process is proving to very valuable to my understanding of what is going on, so I predict it will continue.
The 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.
I am a big fan of any API 101 work out there, helping on-board new users, and industries:
I thought this was interesting - around open data and addresses:
We will continue to see open data and APIs impacting agriculture:
I'm working hard to push for new tooling around popular API definition formats:
Some interesting movement on several API deployment fronts:
Great advice and insight when it comes to API design:
API goings on at API conferences, and meetups:
Only two API integration stories worth showcasing this week:
Lots of rich API management related news stories, helping me understand how providers are operating:
This was some of my thoughts on what types of API tooling I'd like to see emerge in the space:
Some interesting news out of the API driven automobile space:
I am working on a similar report, so I was happy to see other research to stimulate the banking API conversation:
Mostly my own business of APIs thoughts, but a couple of interesting additions to learn from:
An interesting CDN API story:
A few of my thoughts on generating client code using API definitions:
It is really interesting to watch the giants battle it out in the world of cloud computing:
Also keeping eye on the leading, API driven cloud storage and document providers:
I thought Matrix was interesting enough to showcase as an API communication story:
My efforts to keep track on the latest containerization stories:
I'd like to see more stories, and open data and API work around crime resources:
I'm going to have to get better at breaking out data, into more meaningful categories (the list is kind of big):
So many areas of my research are interesting, and the data center has central role:
A few stories involving databases, and the potential for deploying APis from common data connections:
Interesting to better understand API discovery from Microsoft, around their office suite:
A politics of APIs discussion I haven't seen before:
Education related API stories always make me happy--there just aren't enough:
Two interesting embeddable API stories this week:
Another important conversation going on in 2015 is around encryption:
An area we need more activity is when it comes to energy APIs:
Lots of momentum with APIs in the federal government:
Many layers to FinTech, and I am trying to give different views of the financial API discussion:
EH, insurance, quantified-self, and government regulation when in the healthcare industry:
An area I will continue to carve off the bigger IoT discussion is APIs used in the home:
I'm feeling like HTTP/2 is going to keep moving the ground under our feet in coming months:
An interesting take on image search, and I'm seeing lots of activity over at Autodesk:
As the enterprise beats the IoT drum, the rhythm is focused on industrial implementations:
Some quick takes on API integration:
Like data, I'm going to have to get better at organizing and breaking areas of of the Internet of Things (IoT) area:
I like to keep an eye on companies who are hiring for API focused roles, and I think the last one is really interesting, and a little scary:
I'm guessing IBM and the Watson team will dominate the machine learning and AI APIs conversation:
Nice mapping roundup from PW:
Just a couple microservice related thoughts from the week:
A couple more big moves when it comes to mobile, from New Relic and Akamai:
Some API monetization stories, ranging from the sane to crazy over at AT&T:
Music is always an important discussion when it comes to APIs:
Keeping a close eye on these data center, and networking related stories:
Im going to do a little hacking on Microsoft's new notes API, to see what it delivers:
Couple of open source discussions to highlight:
Keeping an eye on who is partnering across API space:
I'm not sure what category to put this into yet:
I think its clear that Google wants to play in payments, if they can find their footing:
Interesting usage of YouTube (which has APIs), with police story out of Seattle:
I predict lots of investment in open data and API driven tools in politics and elections:
Lots of great privacy discussions to follow this last week:
I guess I'm still tracking on quantified self, stories that catch my attention seem to be few and far between:
Pubnub rock'n real-time, with some interesting implementations:
Handful of reciprocity stories:
Another regulation blip from federal government, this time in healthcare:
Scraping will continue to play big role:
The API SDK conversation continues to move forward:
Lots to think about on the security front:
Maybe another area I'll carve off IoT is smart watches:
Single Page Applications (SPA) and APIs are getting interesting:
I thought this was an interesting spreadsheets story, and there are lessons there for the API space:
Google making some terms of service (TOS) changes:
When I think of future of transportation, I think transit APIs:
One of the most important aspects around the politics of APIs is transparency:
My thoughts about how APIs and micro-services will evolve the vendor relationship:
API driven visualization is something that keeps me excited about APIs recently:
In my opinion, wholesale APIs will be an important side effect of the containerization of APIs:
WordPress is still an import platform development kit (PDK), especially if Twitter is tackling themselves:
That concludes my report on what I read last week across the API space. I'm still working on pulling together a summary e-newsletter version, allowing people to get an executive summary of what I thought was important from the week--I am hoping it will be available next week. I'm also going to auto-generate some visualizations, and summary counts for each week. I'd like to see a tag cloud, and overall counts to help me understand the scope of news I cover each week.
As I did last week, I'm walking away with a better awareness of what is happening across the space. It isn't enough for me to read all of this API news in isolation, it helps to see it side by side with other news, allowing me to see and understand patterns that I may have missed.
Thanks for reading. ;-)
02 Mar 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.son, like the one I have for my micro services stack, you see the little APIs.son search icon in the address bar.
When you click on the APIs.son search icon in the address bar, you get a very cool visualization. Its pretty basic at the moment, just a visual catalog of the APIs available in the include collection of my stack, but when you connect up with the Swagger visualization work he's already done, we could have a pretty cool API catalog for managing and exploring microservices.
I have almost 20 micro-services listed, and Swagger.ed gives me the ability to navigate it in a very interactive way. Whats next? We don’t know…it is about exploration, and finding out the most meaningful way of exploring the APIs I deploy and aggregate into APIs.son collections.
I can see having a visual catalog of all of my API design that I collect, then deploy, and evolve them as needed for various parts of my infrastructure or for my clients, into other sub-collections? Disconnected collections? Loosely coupled collections? Not sure how tight I want things, part of the micro service definition for me is the size of the network connecting the services, as well as the services theselves.
02 Mar 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.
One of the side projects that I work on a couple of hours each week, is the profiling of federal government APIs using APIs.json, and Swagger, for use in my federal API stack. I only have a handful of the 120+ APIs that I’m profiling completed, but once done, you will be able to search for APIs based upon whether or not an API uses the verbs GET, POST, PUT, and DELETE—giving you a much more detailed picture of how government APIs function.
Generating machine readable API definitions in Swagger and API Blueprint are time consuming, but once you tie it together using a discovery format like APIs.json, it opens up a lot more opportunity to answer questions about government APIs. I’m doing a lot of the heavy lifting currently, to establish a critical mass of API definitions in federal government, then I am hoping that each agency will take ownership over maintaining their own definitions--if not, I think it can just as easily be done from the outside-in, by the community.
I’m excited for the potential, when all of the meta-layer of APIs and open data in government is rich, well defined, and machine readable by default. The continuing data.json work out of the government, and our own APIs.json format is looking to help with this over time. There is a lot of work ahead, as well as education to occur, before the meta data layer for government APIs is machine readable by default, but once it is, we’ll be able to answer questions like this in a much more efficient way.