These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is defining not just their APIs, but their schema, and other moving parts of their API operations.15 Feb 2018
I am profiling financial market data APIs currently, and as I’m doing my work profiling APIs, I’m always on the hunt for interesting elements of their API operations that I can showcase for my readers. While looking at the financial market data API from Intrinio, I found that I really, really like their application showcase, which providers a pretty attractive blueprint for how we can showcase what is being develop on top of our APIs.
The Intrinio application showcase is just clean looking, and has the bells and whistles you’d expect like categories, search, detail or list view, and detail pages providing you all the information you need about the application, and where you can find tutorials, code, and other relevant resources.
Another thing I really like is it isn’t just about web and mobile applications. They have spreadsheet integrations, and help walk you through how to “apply” each type of integration. This is what the application in API means to me. It isn’t always just about finished web, mobile, and device applications. It is about applying the resources available via the programmatic interfaces to some problem you have in your world.
Anyways, the Intrinio application showcase is totally worth profiling as part of my research. It is a great blueprint for other API providers to follow when crafting their own application showcases. This post give me a single URL that I can share with folks, and reference throughout my stories, white papers, guides, and talks. I’d love to see this become the standard for how API providers showcase their applications, keeping things simple, clean, and bringing value to their consumers.
Tony Tam, the creator of the OpenAPI specification, formerly known as Swagger, has announced he will be exiting his role at OAI and SmartBear. Tony says the specification is in good hands with Ron Ratovsky (@webron), Darrel Miller (@darrel_miller), and others in the OAI. Tony doesn’t give any hints about what he’ll be up to, but will be walking away from his baby entirely.
I have given Tony a hard time during the transition from Wordnik to SmartBear, and the creation of the OpenAPI, but I am a huge fan of what he has done, and super bummed to see him go–hoping he won’t leave the API community completely. There are many building blocks that go into doing APIs and OpenAPI, or Swagger, is the most significant single building block that has emerged in the seven years I’ve been doing API Evangelist. Swagger has had a profound impact on the world of APIs, and OpenAPI will continue doing this in the future, if the right conditions are still present across the API landscape.
Swagger has helped us talk about our APIs. Swagger has helped us collaborate around our APIs. Swagger has opened up a whole lifecycle of API tooling to help us along our journey. I always felt like Swagger reflected Tony’s personality, and with it’s evolution to OpenAPI, and the OpenAPI Initiative means it’s grown beyond it’s creator. OpenAPI is in good hands. I think it is a good time for Tony to step away, and feel like his baby has begun to grow up, becoming much bigger than what he can do on his own (even with Ron’s amazing help).
Thank you for all your work Tony. You made your mark on the API space. You managed to develop something that was useful for API documentation and code generation, but quickly became about design, testing, monitoring, and every other stops along the API lifecycle. I am stoked to have had the chance to work with you, and spend time telling stories about your important work. I hope you find some time to read some good books, and take time for yourself, and hopefully you don’t go to far from the API space, or at least come back and visit from time to time.
I am coming across more API providers who have carved off specific "skills" derived from their API, and offering up as part of the latest push to acquire new users on Slack or Facebook. Services like Github, Heroku, and Runscope that API providers and developers are putting to work increasingly have bots they employ, extending their API driven solutions to Slack and Facebook.
Alongside having an application gallery, and having an iPaaS solution showcase, maybe it's time to start having a dedicated page to showcase the bot solutions that are built on your API. Of course, these would start with your own bot solutions, but like application galleries, you could have bots that were built within your community as well.
I'm not going to add a dedicated bot showcase page until I've seen at least a handful in the wild, but I like documenting these things as I think of them. It gives me some dates to better understand at which point did certain things in the API universe begin expanding (or not). Also if you are doing a lot of bot development around your API, or maybe your community is, it might be the little nudge you need to be one of the first APIs out there with a dedicated bot showcase page.
I'm going to keep beating the patent API drumbeat, until I bring more awareness to the topic, and shine a light on what is going on. While I will still be my usual self and call out the worst behavior in the space, I am also going to try and be a little more friendlier around my views, and try and help bring more options to the table. This is a serious problem, nobody is talking about, and one that has many dimensions and nuances--if you want my raw stance on API patents, you can read it here.
One area I wanted to try and cover, in response to my friends trying to convince me their aren't bad people, in having patents. I know you aren't, and it isn't my goal to make you look bad in this, it is only to shine light on the entire process, how broken it is, and call out the worst offenders. If you truly believe in patents, protecting the work you've done, and that your intentions are good, share your patent portfolio with the world, and showcase it like you do the other aspects of the work you do. You will craft a press release about everything else you do, do the same for your patents.
I do not think patents are bad. I think ill-conceived patent ideas, that haven't been properly vetted by the under resourced USPTO, that are used in back door dealings as leverage, and litigated in a court of law are bad. I'll take your word that your patents are good, and you aren't operating in any of these areas, if you are public, transparent, and openly proud of them, as you state in private conversations.
Part of the purpose of my research is to encourage good behavior in the sector, by highlight the common building blocks of the space. I think I will add a patent portfolio building to my research. While I have ZERO examples to highlight, I encourage API companies to do this, and would love to highlight in a positive way, any company that is straight up enough to showcase their patents. If you are proud of your API patents, and do not have bad intentions in having them, please publish your portfolio, show case them as you would anything else you are doing--help bring API patents out of the shadows.
Time Tracking API platform Harvest has embraced Github as part of their API ecosystem. I'm always on the hunt for examples of API providers using Github, so I figured I'd showcase Harvest's creative use of the social coding platform.
Starting with their documentation, the Harvest team has moved the API documentation to a Github repository, allowing developers to "watch" the API, get updates when changes are made, asks questions or even contribute to the API docs by submitting a pull request.
Harvest is also using the wiki portion of their Github repo for a developer application gallery they are calling Community Creations and Hacks, where they showcase innovative uses of the Harvest API--currently displaying 20 integrations by Harvest users.
I'm currently tracking on 11 separate uses of Github for API management, and always on the hunt for new ways to use Github to support API ecosystems. Nice move Harvest!
I stumbled across the Twitter Counter API in my monitoring for the API Stack this morning. The Twitter Counter API allows you to retrieve key metrics on any Twitter account like username, url and avatar. All data you can get via the Twitter API, but with Twitter Counter API you get additional information like account growth statistics and ranking, that Twitter doesn't provide at all.
I find it fascinating that someone can build an API to augment an existing API, which is why I keep talking about it, I guess :) We are seeing a more standardized version of this with API aggregation providers like Singly and Adigami, where they not only aggregate APIs from a variety of sources, they also build entirely new APIs based the added value that is created after they are brought together.
Thinking about if further, it would be cool if you could submit your API to be listed in your parent API providers API area. Think of APIhub and Mashape, but every API area would have its own 3rd API marketplace. API providers often allow 3rd party developers to submit code libraries and samples to be listed as resources, as well as applications for listing in an application showcase. So it makes sense to potetially allow for your developers to submit APIs for validation and publishing into a designated area.
Poster boy for how to properly run your API ecosystem properly, Twilio, recently updated their DOer Gallery to highlight developers in the Twilio ecosystem that build cool stuff on the popular voice and SMS API.
Twilio has the best record I’ve seen of any API, when it comes to showcasing and being loved by their developer community, and I'm sure the DOer Gallery plays an important role in that.
The Twilio DOer Gallery has the following features:
- Personal Details
- Short Bio
- Other Profiles
Devloper Galleries like Twilios might not be for every API platform. But if you have a passionate base of developers you might want to consider giving them their own profile and a gallery where they can not just discover and interact with each other, it can let other companies find potential developers to execute projects via your API.
A Developer Gallery can be a great way to give your API developers some love and attention. Twilio even features developers from their DOer Gallery on their blog in a "DOer of the Month".
Would showcasing your “API DOers” benefit your API community?
Factual has launch a new application gallery to showcase the diverse number of applications built using data provided by Factual.
You can search for apps, browse by category, and filter by open source, paid or free apps. Looks like there are about 18 apps in the directory currently ranging from augmented reality to daily deals.
The Factual App Gallery isn’t a particularly unique launch, we are seeing app showcases popup within many APIs, but it shows that Factual is gaining steam, and I think it shows the appetite for building apps around datasets is growing.
- 1st prize - Makerbot Thing-O-Matic 3D Printer
- 2nd prize - 1TB USB hard drive enclosed in a vintage nintendo game (Zelda, Metroid, etc)
- 3rd prize - Set of BuckyBalls magnetic building spheres
- NewIn - This application shows new members joining LinkedIn from around the world.
- ChromeIn - Integrate LinkedIn directly into Google Chrome. Easy access to your LinkedIn updates, anytime.
- Signal - Signal is aimed at making it easy for all professionals to glean the most relevant insights from the never-ending stream of status updates and news. An API Labs is a great way to showcase experimental and innovative projects that utilize your API.
If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.