I am Kin Lane, the API Evangelist...

This is my online domain where I work to understand the world of the Application Programming Interfaces, also known as APIs. This new way of sharing data using the web is touching almost every aspect of our increasingly digital lives, providing access to the bits and bytes that make our personal and professional worlds go round.

This is my research specifically into how API platforms are showcasing (or not) the applications that are being developed on their platforms. I find showcasing to be not just valuable, but tells a lot about a platform and how it views its consumers. Just watching companies, as well as the absence of companies tells me a lot about what the motivations are behind operating an API platform.

API Evangelist is a network of data driven projects and APIs which I curate and manage as part of this ongoing research, hoping to provide easy access to the moving parts of my work. Everything you see here runs on Github, making everything forkable, and reusable for both humans and machines.

API Evangelist Partners

These are my partners who invest in API Evangelist each month, helping underwrite my research, and making sure I'm able to keep monitoring the API space as I do.

DreamFactory Software develops and markets a technology that enables developers to connect modern mobile applications to enterprise back-end infrastructure in the cloud.

Latest From Blog on API Design: Either You Own The Conversation Around Your APIs Or Someone Else Will

11 Jul 2017

I was looking at how many of the top mobile applications in the iTunes story actually had a public API presence, and was finding it very telling what came up in the Google search results for each company when I searched [company name] + API. It tells a lot about how a company sees the world, when they don’t have a public API presence, but they have a very public mobile application that uses APIs.

An example of this is with Tinder, where the top listings are all Github rogue API repositories, when you Google “Tinder API”. Tinder doesn’t own the conversation when it comes to their own APIs. While the Tinder APIs are public, and well documented, Tinder prefers acting like they are private–they aren’t. Pinterest uses SSL pinning, but there is even a good amount of information out there at how to get around that, making the mapping out and documenting of Tinder APIs a pretty doable thing.

Honestly, I don’t care about Tinder’s APIs. They are just an easy example to point a finger at and use as a poster child. I don’t even expect them to have fully public APIs that any developer could use without permission. Sure, lock that shit down, but provide a sandbox, and make sure every application gets approval before they can more access to live data. Make sure that you own the API conversation by having a developers portal, and provide information regarding what it takes to get access, and maybe some day actually become an approved partner.

I’m not saying that every company should have freely available public APIs. I’m saying every company should own the public conversation around their APIs, no matter what their strategy for developing applications around a platform’s APIs. Have a presence. Own the conversation. Have a door for application developers to walk, even if there is a waiting room. Not all applications will be competing with your own web, mobile, device, or network applications. Some will be about enabling data portability for you users, or maybe provide useful access aggregate data for use in visualizations–you never know what folks will be bringing to the table, why keep the door closed?

I understand. You may not be all team API like I am, but you are using APIs to drive your mobile experience. I just don’t get why you wouldn’t want to own the conversation around these APIs. You are leaving so much on the table. If your mobile app is finding success, people will want access to the goodness going on behind it–a rogue API is what kickstarted the Instagram API in the early days. It is pretty easy to reverse engineer any mobile application, and map out the surface area of the API behind, as well as the authentication in play. Either you own the conversation around your API, or someone will step up and do it for you in todays online world.

Rogue API News

These are the news items I've curated in my monitoring of the API space that have some relevance to the rogue API conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.

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.

About This Research

As I keep an eye on the space I curate news, bookmark organizations, watch interesting tools, and work to understand what deployment solutions are being applied by leading API providers. I take everything I find and publish here as part of my research.

I then take this research, and what I've learned and publish stories on the blog, and more long form content like my industry guides, and white papers for customers. This is one way that I generate revenue to keep it all going.

If you'd like to see me focus more on webhooks I could use more partners investing in this area, helping me find the time to study more about what is going on. Feel free to contact me directly if you want to talk more about webhooks.