The API Evangelist Blog - 2019

This blog is dedicated to understanding the world of APIs and exploring the technology, business, and politics of APIs.


I Am Joining Postman As Their Chief Evangelist

12 September 2019
I am determined to continue taking my career to the next level. I’ve done well doing API Evangelist over the years, but I feel like I’ve gone as far as I can all by my lonesome. To level things up I feel I need more than just my words. I need some meaningful tooling, and collaboration with people who are building interesting and meaningful things with APIs to get to the place I envision in my minds eye. There are just a handful of startups out there who have both captured my API imagination, are making a meaningful impact on the API sector, and share my ethical view of the API sector, and one of them is Postman. I’ve supported Postman since they emerged on the scene, and as of today, I am joining their team as their Chief Evangelist...

AsyncAPI Version 2.0 Is Ready For Use

11 September 2019
The latest major version of the event-driven API specification format AsyncAPI is ready for production. The AsyncAPI community has been working hard in recent months to hammer out the next generation specification for helping us all better define a common definition for our event-driven APIs so that we can use across the API lifecycle. AsyncAPI is a sister specification to OpenAPI (fka Swagger), and while you can describe HTTP APIs using the format, it excels at helping us define our event-driven API infrastructure, and bring all the same documentation, mocking, testing, and other critical stops along an API lifecycle we will need to be successful.I’m going to be playing around with a couple implementations using AsyncAPI 2...

API Management For An Event-Driven API Landscape

11 September 2019
I’ve talked recently about a second coming of API management, which in my opinion is a wave that has several fronts. One of those fronts I see rolling out is in the area of event-driven API infrastructure. API management for request and response API infrastructure is pretty well defined, but the same concepts applied to event-driven infrastructure represents a pretty significant opportunity within this second evolution. Something that will span HTTP 1.1, HTTP/2, and TCP API implementations, providing the essential API management building blocks we might take for granted with HTTP 1.1 implementations, but as API providers expand their API toolbox to possess a variety of implementation patterns, they are beginning to look for consistent management capabilities across all their APIs...

Discovering The Confluent Schema Registry

10 September 2019
While spending time doing some research into schema management tooling I came across the Confluents Schema Registry. The schema management solutions is one of the first formal tools I’ve come across that is specifically designed for helping folks get their schema house in order when it comes to APIs. I’m sure there are others out there, but this was the first solution I've documented that addresses this in an API context as well as having an API, providing some of the critical features needed to make sense of the crazy schema mess enterprise organizations find themselves in.Here is the language from the Confluent website describing what the registry is all about: Confluent Schema Registry provides a RESTful interface for developers to define standard schemas for their events, share them across the organization and safely evolve them in a way that is backward compatible and future proof...

The API Reality In Our Heads Versus The Reality On The Ground

10 September 2019
I am spending some time grounding my views of the API landscape. Working my through all of my beliefs, and systematically blowing them to bits to see how they hold up against the stress of reality on the ground. This is something I’ve become very good at when it comes to my personal beliefs in recent years, and something I’ve been working to transfer to my professional world to help me keep a grip on what is going on. There are a number of reason why I fall prey to things that are not real in this game, and I’m pretty aware of the shady things that occur in the business world, but when it comes to technology I find the stories it whispers in my ear prove to be particularly enchanting and seem to go from whisper to truth at a velocity I don’t always understand...

Continue Pushing The API Documentation Conversation Forward

09 September 2019
I am been finally seeing the investment across the API sector I wanted to see when it comes to API documentation. There are multiple API definition driven API documentation offerings available on the market now. Both open source and high quality commercial services. A couple years after Swagger UI made it’s splash I began lobbing for more investment in open source API documentation tooling, and after four years I’m starting to see it beginning to happen. However, let’s not rest on laurels and make sure we keep investing and building on the momentum that we have established, and continue making API documentation more valuable to developers, but also to business users who are interested in putting API resources to work...

Bridging Grand Visions of an API Lifecycle With People on the Ground Being Successful In Their Work

09 September 2019
While my work as the API Evangelist can burn me out some of the time, I generally find it intellectually challenging. The work takes me from industry to industry, country to country, and to the highest levels of technology, and down to the work that goes on across development teams within companies. APIs are everywhere. Really, they are. They are impacting each one of our personal and professional lives, and this is one of the things that keeps me coming back doing what I do. The diversity of API implementations, and levels at which I can engage with the industry keeps me interested, continuously learning and producing.I enjoy thinking about the API space from the 250K level. It is interesting to study what is, what has been, and where things might be going when it comes to APIs...

API Evangelist Does Not Run On GitHub Anymore

06 September 2019
I migrated the main API Evangelist site off of GitHub the other day. The moved followed the migration of 100+ network sites of my API research a couple of weeks back. While I still have a handful of definitions and tooling published to GitHub, the migration of my main site signals a pretty huge shift in how I operate the site. I’ve operated the site 100% on GitHub since 2014, using YAML as the backend data store, and Jekyll to publish the pages, blogs, and data-driven pages. I have always done this to keep the site as open and accessible as I possibly can, sharing all of the data behind what I was doing However, in 2019, due to increased GitHub API rate limits, Jekyll build timeout limits, and shifts in the purpose of API Evangelist, I don’t see the value in me working to keep things open and available on GitHub anymore...

Where Do You Like Your API Complexity?

06 September 2019
I prefer my API complexity at the path, query, then schema levels of my API design—specifically in that order. I don’t mind a huge number of individual API calls to get the job done because I just script away this aspect of API complexity. However, I do fully understand that many folks prefer their complexity at the query and schema levels over having lots of individual paths. I find that developers love to rant about imperative API complexity, and in my experience the folks who don’t like path level API complexity are also some of the most vocal types of folks who are very confident that their way is the right way, when in reality, there is no right way—just the way YOUR consumers will want or need to access the API resources you are serving up...

API Management Should Not Just Limit Me, It Should Allow Me To Scale

06 September 2019
I do a lot of thinking about API management. After almost a decade of contemplating how we manage our API infrastructure, I feel it is still the most important stop along the API lifecycle. I don’t care how well designed, deployed, documented, and supported your APIs are, if you aren’t tuned in using API management, you aren’t going to be successful. API management provides you with the tools to you need to define and understand how your consumers will put your API resources to work. After almost 15 years of evolution, API management hasn’t changed too much, but there is one core capability I’d like to see evolve, expanding upon the often go to feature of API rate limiting...

The Different Ways API Providers Use The OpenAPI Servers Collection

05 September 2019
I was looking through the OpenAPI definitions I have harvested via some automated scripts I have running, and I came across an API definition that had a variety of URLs available for their APIs, making this part of the definition something I want to study more, identifying the common patterns in use. I harvest a growing number of OpenAPI definitions and Postman Collections to help me stay in tune with who the interesting API providers are, and documenting what the common building blocks of APIs are, helping shine a light on the useful practices that exist across API providers within many different industries. The OpenAPI server collection is beeing used to help automate switching between a variety of locations, and is most commonly used to differentiate between the different stages of an API server, as see I this example: This is just the most common usage of the OpenAPI server collection out there...

Controlling The Conversation Around Your Mobile Application APIs

03 September 2019
I have seen it play out over and over since I began monitoring the API conversation. Companies who launch APIs to power a mobile application but refuse to, or are unaware of how they should be controlling the conversation around public API infrastructure. The most common reason for this is that companies do not view the APIs behind their mobile applications as public APIs, and that somehow because they are buried within their mobile application, that they are safe from hackers. Completely clueless of the fact that anyone can run any mobile application through a proxy and reverse engineer the API infrastructure behind any mobile application.Mobile application platforms that do not control the conversation around their public APIs are the ones who end up having security incidents down the road...

Benefits Of Treating My API Infrastructure As API-First

26 August 2019
Most API providers I speak with see the value of consistently delivering API infrastructure to power desktop, web, mobile, device, and network applications. Less than 10% of these providers see the API infrastructure that powers their APIs, and ultimately their applications as APIs. Meaning, these providers do not view every stop along the API lifecycle as a set of APIs, ensuring that your API definitions, design, mocking, deployment, management, monitoring, testing, orchestration, security, and documentation all have APIs, and are able to be governed programmatically. Mostly it is because they are just getting started on their API journey and / or they just don’t have the bandwidth to be able to step back and look holistically at what they are trying to accomplish...

Doing A Diff Between Available Web, Mobile and Public APIs

22 August 2019
I spend a lot of time running web and mobile applications through a proxy to reverse engineer their APIs. I generally use Charles Proxy for routing my desktop, web, and mobile traffic through, which then automatically saves a JSON dump of sessions every five minutes, and syncs with Dropbox via my shared folders. From there I have a schedule service that will look in the shared Dropbox folder every hour, sift through the Charles Proxy JSON dump, and look for JSON, XML, CSV, and other common machine readable formats—which are then converted into OpenAPI definitions. Allowing me to reverse engineer desktop, web, and mobile applications as I use them, and map the API surface area for these targeted applications...

An API Policy Domain Specialist At Twitter

22 August 2019
There are some jobs on the Internet I apply for no matter what my current situation is, and an API policy domain specialist at Twitter was one of them that popped up recently. I applied for the job within the first couple of hours after it came out, but haven’t heard from them. I can speculate on the reasons why, but I think a story about the job posting itself is actually more interesting, so I’ll focus there. It is the first time I’ve seen a job posting for this role, but I think it will eventually become a required role in the future for any company with a public API—-that is, if companies want avoid the trouble Twitter is going through right now, which again, is making Twitter the poster child for how to do APIs both right and wrong...

Multiple Overlapping API Life Cycle(s)

21 August 2019
One of the toughest parts about teaching people about APIs is that there are many different views of what the API life cycle can be depending on who you are, and what your intentions are. As an advocate or evangelist for a single API you are speaking externally to the API consumption life cycle, but internally you are focused on the API delivery life cycle. As an API Evangelist for many APIs, targeting providers, consumers, and anyone else who comes along, I find it a constant challenge to properly speak to my intended audience. One problematic part of my storytelling I regularly see emerge is that I speak of a single API life cycle, where in reality there are many overlapping life cycles. So, to help me think through all of this I wanted to explore what these overlapping tracks might be—coming up with four distinct iterations of overlapping API building blocks...

Human Empathy Is One Of My Most Important API Outreach Tools

20 August 2019
I am an empathic human being. It is one of my top strengths, as well as one of my top weaknesses. It is also one of the most important tools in my API toolbox. Being able to understand the API experience from the position of different people throughout the world of APIs is a cornerstone of the API Evangelist brand. Personally, I find APIs themselves to be empathy triggering, and something that has regularly forced me out of my silos, then allowing me t put myself in the shoes of my consumers. Something that when realized in a perpetual fashion can become a pretty powerful force for dialing in the services you offer, and establish, maintain, and strengthen connections with other people within the community...

The API Conferences I Am Tracking On For The Fall

20 August 2019
As we approach the fall it is time to begin thinking about the conference season, and what the most relevant API conferences are. I haven’t been doing any events this year, but staying in tune with the conference circuit has always been important to my work. Who knows, maybe I will be spend some more time investing in API related events after taking a break for six month. When it comes to API events and conferences, here is what I am tracking on.

A Second Wave of API Management is Going On

19 August 2019
I fully surfed the first wave of API management. API Evangelist began by researching what Mashery, Apigee, and 3Scale had set into motion. API Evangelist continued to has exist through funding from 3Scale, Mulesoft, WSO2, and continues to exist because of the support of next generation providers like Tyk. I intimately understand what API management is, and why it is valuable to both API providers and consumers. API management is so relevant as infrastructure it is now baked into the AWS, Azure, and Google Clouds. However, if you listen to technological winds blowing out there, you will mostly hear that the age of API management is over with, but in reality it is just getting started. The folks telling these tales are purely seeing the landscape from an investment standpoint, and not from an actual boots on the ground within mainstream enterprise perspective—something that is going to burn them from an investment standpoint, because they are going to miss out on the second wave of API management that is going on...

Postman Collection As A Single Quantifiable, Shareable, Executable Unit Of Representation For Any Digital Capability

19 August 2019
In my world API definitions are more valuable than code. Code is regularly thrown away and rewritten. API definitions hold the persistent detail of what an API delivers, and contain all of the proprietary value when they are properly matured. OpenAPI has definitely risen to the top when it comes to which API definition formats you should be using, however, Postman Collections have one critical ingredient that makes them ultimately more usable, sharable, and meaningful to developers—-environmental context. This small but important difference is what makes Postman Collections so valuable as a single quantifiable, shareable, executable unit of representation for any digital capability. Like OpenAPI, Postman Collections describe the surface area of a web API, but they have that added layer to describe the environment you are running in, which makes it much more of a run-time and execute-time experience...

Four Phases Of Internal API Evangelism

16 August 2019
General evangelism around what APIs are, as well as more precise advocacy around specific APIs or groups of API resources takes a lot of work, and repetition. Even as a seasoned API evangelist I can never assume my audience will receive and understand what it is that I am evangelizing, and I regularly find myself having to reassess the impact (or lack of) that I’m making, retool, refresh, and repeat my messaging to get the coverage and saturation I’m looking for. After a decade of doing this, I cannot tell which is more difficult, internal or external public evangelism, but I do find that after almost 10 years, I’m still learning from each audience I engage with—-proving to me that no single evangelism strategy will ever reliably work, and I need a robust, constantly evolving toolbox if I am going to be successful...

Seeing API Consumers As Just The Other Ones

16 August 2019
As API providers, it can be easy to find ourselves in a very distant position from the consumers of our APIs. In recent weeks I have been studying the impacts of behavioral approaches to putting technology to work, something that has led me to the work of Max Meyer, and his Psychology of the Other-One (1921). I haven’t read his book yet, but have finished other works citing his work on how to “properly” study how animals (including humans) behave. While the psychological impact of all of this interests me, I’m most interested in how this perspective has amplified and driven how we use technology, and specifically how APIs can be used to create or bridge the divide between us (API providers) and our (API consumers)...

An API Platform Reliability Engineer At Stripe

15 August 2019
I find that the most interesting and telling API building blocks come out of the companies who are furthest along in their API journey, and have made the conscious effort to heavily invest in their platforms. I try to regularly visit API platforms who are doing the most interesting work on a regular basis, because I am almost always able to find some gem of an approach that I can showcase here on the blog. This weeks gem is from API rockstar Stripe, and their posting for a reliability engineer for their API platform. Here is a summary from their job posting: As a Reliability Engineer, you’ll help lead an active area of high impact by defining and building proactive ways to further hone the reliability of our API...

An Observable Regulatory Provider Or Industry API Management Gateway

15 August 2019
I wrote a separate piece on an API gateway specification standard recently, merging several areas of my research and riffing on a recent tweet from Sukanya Santhanam (@SukanyaSanthan1). I had all these building blocks laying around as part of my research on API gateways, but also from the other areas of the API lifecycle that I track on. Her tweet happened to coincide with other thoughts I had simmering, so I wanted to jump on the opportunity to publish some posts, and see if I could slow jam a conversation in this area. Now, after I defined what I’d consider to be a core API gateway set of building blocks, I wanted to take another crack at refining my vision for how we make it more observable and something that could be used as a tech sector regulatory framework...

A Look At Behavioral API Patents

05 August 2019
I have been studying uses of behavioral technology lately. Riffing off my partner in crimes work on the subject, but putting my own spin on it, and adding APIs (of course) into the mix. Applying on of my classic techniques, I figured I’d start with a patent search for “behavioral application programming interfaces”. I find patents to be a “wonderful” source of inspiration and understanding when it comes to what is going on with technology. Here are the top results for my patent search, with title, abstract, and a link to understand more about each patent. User-defined coverage of media-player devices on online social networks In one embodiment, a method includes detecting, by a media-player device including multiple antennas, a client system of a user is within a wireless communication range of the media-player device...

Some Of The API Gateway Building Blocks

05 August 2019
The inspiration for this post wasn’t fully mine, I’m borrowing and building upon what Sukanya Santhanam (@SukanyaSanthan1) tweeted out the other day. It is a good idea, and something that should be open sourced and moved forward. I’ve been studying with API management since 2010, and using gateways for over 15 years. I’ve watched gateways evolve, and partnered regularly with API management and gateway providers (Shout out to Tyk). Modern API gateways aren’t your grandfather’s SOA tooling, they’ve definitely gone through several iterations. While I still prefer hand rolling and forging my APIs out back in my woodshed on an anvil, I find myself working with a lot of different API gateways lately...

Didn’t We Already Do That?

02 August 2019
When you are in the API game you hear this phrase a lot, “didn’t we already do that?”. It is a common belief system that because something was already done, that it means it will not work ever again. When you are operate solely in a computational world, you tend to see things as 1s and 0s, and if something was tried and “didn’t work”, there is no resetting of that boolean switch for some reason. We excel at believing things are done, without ever unpacking why something failed, or how the context may have changed. One of the things I’m going to do over the next couple months is go through the entire SOA toolbox and take accounting of everything we threw away, and evaluate what the possible reasoning were behind it—-good and bad...

Reverse Engineering Mobile APIs To Show A Company Their Public APIs

02 August 2019
One story I tell a lot when talking to folks about APIs, is how you can reverse engineer a mobile phone to map out the APIs being used. As the narrative goes, many companies that I talk with claim they do not have any public APIs when first engage with them. Then I ask them, “Do you have any mobile applications?”. To which the answer is almost always, “Yes!”. Having anticipated this regular conversation, if I am looking to engage with a company in the area of API consulting, I will have made the time to reverse engineer their application to produce a set of OpenAPI definitions that I can then share with them, showing that they indeed have public APIs. The process isn’t difficult, and I’ve written about this several times...

About Giving Away API Knowledge For Free

01 August 2019
I’m in the business of providing access to the API knowledge accumulated over the last decade. Despite what many people claim, I do not know everything about APIs, but after a decade I have picked up a few things along the way. Historically, I have really enjoyed sharing my knowledge with people, but I’m increasingly becoming weary of sharing to openly because of the nature of how business gets conducted online. Specifically, that there are endless waves of folks who want to tap what I know without giving anything in return, who work at companies who enjoy a lot of resources. I know people have read the startup handbook, which tells them to reach out to people who know and get their view, but when everyone does this, and doesn’t give anything in return, it is, well…I guess business as usual? Right? ;-( Taking a sampling from the usual week in my inbox, I’ll get a handful of requests reflecting these personas: Analysts / Consultants - Other analysts reaching out to share information, and get my take on what I’m seeing...

The Future Of APIs Will Be In The Browser

01 August 2019
I have been playing with the new browser reporting API lately, and while it isn’t widely supported, it does work in Chrome, and soon Firefox. I won’t go into too much technical detail, but the API provides an interesting look at reporting on APIs usage in the browser. Offering a unique view into the shadows of what is happening behind the curtain in our browser when we are using common web applications each day. I have been proxying my web traffic for a long time to produce a snapshot at the domains who are operating beneath the covers, but it is interesting for browsers to begin baking in a look at the domains who are violating, generating errors, and other shenanigans. As I’m contemplating the API discovery universe I can’t help but think of the how “API innovation” is occurring within the browser...

The Challenges Of API Discovery Conversations Being Purely Technical

31 July 2019
Ironically one of the biggest challenges facing API discovery on the web, as well as within the enterprise, is that most conversations focus purely on the technical, rather than the human and often business implications of finding and putting APIs to work. The biggest movement in the realm of API discovery in the last couple years has been part of the service mesh evolution of API infrastructure, and how your gateways “discover” and understand the health of APIs or microservices that provide vital services to applications and other systems. Don’t get me wrong, this is super critical, but it is more about satisfying a technical need, which is also being fueled by an investment wave-—it won’t contribute to much to the overall API discovery and search conversation because of it’s limited view of the landscape...

Differences Between API Observability Over Monitoring, Testing, Reliability, and Performance

31 July 2019
I’ve been watching the API observability coming out of Stripe, as well as Honeycomb for a couple years now. Then observability of systems is not a new concept, but it is one that progressive API providers have embraced to help articulate the overall health and reliability of their systems. In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. Everyone (except me) focuses only on the modern approaches for monitoring, testing, performance, status, and other common API infrastructure building blocks to define observability. I insist on adding the layers of transparency and communication, which I feel are the critical aspects of observability—-I mean if you aren’t transparent and communicative about your monitoring, testing, performance, and status, does it really matter? I work to define observability as a handful of key API building blocks that every API provider should be investing in: Monitoring - Actively monitoring ALL of your APIs to ensure they are up and running...

Peer API Design Review Sessions

30 July 2019
Public APIs have always benefitted from something that internal APIs do not always received—-feedback from other people. While the whole public API thing didn’t play out as I originally imagined, there is still a lot of benefit in letting other see, and provide open feedback on your API. It is painful for many developers to receive feedback on their API, and it is something that can be even more painful when it is done publicly. This is why so many of us shy away from establishing feedback loops around our APIs. It is hard work to properly design, develop, and then articulate our API vision to an external audience. It is something I understand well, but still suffer from when it comes to properly accessioning peer review and feedback on my API designs...

API For Processing Common Logging Formats And Generating OpenAPI Definitions

30 July 2019
I’ve invested a lot of time in the last six months into various research, scripts, and tooling to help me with finding APIs within the enterprise. This work is not part my current role, but as a side project to help me get into the mindset of how to help the enterprise understand where their APIs are, and what APIs they are using. Almost every enterprise group I have consulted for has trouble keeping tabs on what APIs are being consumed across the enterprise, and I’m keen on helping understand what the best ways are to help them get their API houses in order. While there are many ways to trace out how APIs are being consumed across the enterprise, I want to start with some of the basics, or the low hanging when it came to API logging within the enterprise...

API Storytelling Within The Enterprise

28 July 2019
Storytelling is important. Storytelling within the enterprise is hard. Reaching folks on the open web is hard work to, but there is usually an audience that will eventually tune in, and over time you can develop and cultivate that audience. The tools you have at your disposal within the enterprise are much more prescribed and often times dictated–even controlled. I also find that they aren’t always as effective as they are made out to be, with the perception being one thing, and the reach, engagement, and noise being then much harder realities you face when trying to get a message out. Email might seem like a good idea, and is definitely a critical tool when reaching specific individuals or groups, but as a general company wide thing, it quickly becomes exponentially ineffective with each person you add on as CC...

APIs and Browser Bookmarklets

24 July 2019
I have quite a few API driven bookmarklets I use to profile APIs. I recently quit using Google Chrome, so I needed to migrate all of them to Firefox. I saw this work as an opportunity to better define and organize them, as they had accumulated over the years without any sort of strategy. When I need some new functionality in my browser I would create a new API, and craft a bookmarklet that would accomplish whatever I needed. I wish I had more browser add-on development skills, something I regular try to invest in, but I find that bookmarklets are the next best thing when it comes to browser and API interactions. There are a number of tasks I am looking to accomplish when I’m browsing the web pages of an API provider...

Absolutism Around API Tools Increases Friction And Failure

24 July 2019
I know you believe your tools are the best. I mean, from your vantage point, they are. I also know that when you are building a new API tool, your investors want you to position your tooling as the best. The one solution to rule them all. They want you to work hard to make your tools the best, but also make sure and demonize other tooling as being inferior, out of date, and something the dinosaurs use. I know this absolute belief in your tooling feels good and right, but you are actually creating friction for your users, and potentially failure or at least conflict within their teams. Absolutism, along with divide and conquer strategies for evangelizing API tooling works for great short term financial strategies, but doesn’t do much to help us on the ground actually developing, managing, and sustaining APIs...

The Higher Level Business Politics That I Am Not Good At Seeing In The API Space

23 July 2019
I have built successful startups. I’m good at the technology of delivering new solutions. I am decent at understanding and delivering much of business side of bringing new technological solutions to market. What I’m not good at is the higher level business politics that occur. These are the invisible forces behind businesses that I’m good at seeing, playing in, and almost always catch me off guard, too late, or just simply piss me off that they are going on behind the scenes. Unfortunately it is in this realm where most of the money is to be made doing APIs, resulting in me being written out of numerous successful API efforts, because I’m not up to speed on what is going on. Startups are great vehicles for higher level economic strategies...

API Provider And Consumer Developer Portals

23 July 2019
I’ve been studying API developer portals for almost a decade. I’ve visited the landing pages, portals, websites, and other incarnations from thousands of API providers. I have an intimate understanding of what is needed for API providers to attract, support, and empower API consumers. One area I’m deficient in, and I also think it reflects a wider deficiency in the API space, is regarding how to you make an API portal service both API providers and API consumers. Providing a single portal within the enterprise where everyone can come and understand how to deliver or consume an API. There are plenty of examples out there now when it comes to publishing an API portal for your consumers, but only a few that show you how to publish an API...

The Role Having Awareness Of Your API Traffic Plays In API Security

22 July 2019
One of the biggest reasons we adopt new technology, and justify the development of new technology, is we do not want to do the heavy lifting when it comes to what we already have in place. A common illness when it comes to API security that I’ve been battling since 2015 is that you will have API security addressed once you adopted an API management solution. Your APIs require API keys, and thus they are secure. No further work necessary. The unwillingness or lack of knowledge regarding what is needed next, leaves a vacuum for new technology providers to come in and sell you the solution for what is next, when you should be doing more work to use the tools you already have. When it comes to API management, most vendors sold it as purely a security solution, and when companies implement it they become secure...

Happy Path API Testing Bias

22 July 2019
I see a lot of happy path bias when it comes to the development of APIs, but specifically when it comes to crafting testing to ensure APIs are delivering as expected. Happy path is a term used in testing to describe the desired outputs a developer and product owner is looking for. Making the not so happy path being about testing for outcomes that a developer and product owner is not wanting to occur. When it comes to API development most developers and product owners are only interested in the happy path, and will almost always cut corners, minimize the investment in, or completely lack an imagination when it comes to less than happy path API testing. There are many reasons why someone will have a bias towards the happy path when developing an API...

What Makes You Think Your GraphQL Consumers Will Want To Do The Work

18 July 2019
Data work is grueling work. I’ve been working with databases since my first job developing student information databases in 1988 (don’t tell my wife). I’ve worked with Cobol, Foxpro, SQL Server, Filemaker, Access, MySQL, PostGres, and now Aurora databases over the last 30 years. I like data. I can even trick myself into doing massive data and schema refinement tasks on a regular basis. It is still grueling work that I rarely look forward to doing. Every company I’ve worked for has a big data problem. Data is not easy work, and the more data you accumulate, the more this work grows out of control. Getting teams of people to agree upon what needs to happen when it comes to schema and data storage, and actually execute upon the work in a timely, cost effective, and efficient way is almost always an impossible task...

What Is An Application?

18 July 2019
I have struggled asking this question in many discussions I’ve had around the world, at technology conferences, on consulting projects, and in the back rooms of dimly lit bars. What is an application? You get ten different answers if you ask this question to ten different people. I’d say the most common response is to reference the applications on a mobile device. These are the relevant. Most accessible. The most active and visible form of application in our modern life. Older programmers see them as desktop applications, where younger programmers see them as web applications, with varying grades of server applications in between. If you operate at the network layer, you’ve undoubtedly bastardized the term to mean several different things...

Paying for API Access

17 July 2019
APIs that I can’t pay for more access grinds my gears. I am looking at you GitHub, Twitter, Facebook, and a few others. I spend $250.00 to $1500.00 a month on my Amazon bill, depending on what I’m looking to get done. I know I’m not the target audience for all of these platforms, but I’m guessing there is a lot more money on the table than is being acknowledged. I’m guessing that the reason companies don’t cater to this, is that there are larger buckets of money involved in what they are chasing behind the scenes. Regardless, there isn’t enough money coming my way to keep my mouth shut, so I will keep bitching about this one alongside the inaccessible pricing tiers startups like to employ as well...

The Many Ways In Which APIs Are Taken Away

17 July 2019
APIs are notorious for going away. There are so many APIs that disappear I really stopped tracking on it as a data point. I used keep track of APIs that were shuttered so that I could play a role in the waves of disgruntled pitchfork mobs rising up in their wake–it used to be a great way to build up your Hacker News points! But, after riding the wave a couple hundred waves of APIs shuttering, you begin to not really not give a shit anymore—-growing numb to it all. API deprecation grew so frequent, I wondered why anyone would make the claim that once you start an API you have to maintain it forever. Nope, you can shut down anytime. Clearly. In the real world, APIs going away is a fact of life, but rarely a boolean value, or black and white...

Hoping For More Investment In API Design Tooling

16 July 2019
I was conducting an accounting of my API design toolbox, and realized it hasn’t changed much lately. It is still a very manual suite of tooling, and sometimes services, that help me craft my APIs. There are some areas I am actively investing in when it comes to API design, but honestly there really isn’t that much new out there to use. To help me remember how we got here, I wanted to take a quick walk through the history of API design, and check in on what is currently available when it comes to investing in your API design process. API design has historically meant REST. Many folks still see it this way. While there has been plenty of books and articles on API design for over a decade, I attribute the birth of API design to Jakub and Z at Apiary (https://apiary...

Imperative, Declarative, and Workflow APIs

16 July 2019
At every turn in my API work I come across folks who claim that declarative APIs solutions are superior to imperative ones. They want comprehensive, single implementation, do it all their way approaches, over granular, multiple implementation API calls that are well defined by the platform. Declarative calls allow you to define a single JSON or YAML declaration that can then be consumed to accomplish many things, abstracting away the complexity of doing those many things, and just getting it done. Imperative API interfaces require many individual API calls to tweak each and every knob or dial on the system, but is something that is often viewed as more cumbersome from a seasoned integrator, but for newer, and lower level integrators a well designed imperative API can be an important lifeline...

What Is An API Contract?

15 July 2019
I am big on regularly interrogating what I mean when I use certain phrases. I’ve caught myself repeating and reusing many hollow, empty, and meaningless phrases over my decade as the API Evangelist. One of these phrases is, “an API contract”. I use it a lot. I hear it a lot. What exactly do we mean by it? What is an API contract, and how is it different or similar to our beliefs and understanding around other types of contracts? Is it truth, or is just a way to convince people that what we are doing is just as legitimate as what came before? Maybe it is even more legitimate, like in a blockchain kind of way? It is an irreversible, unbreakable, digital contract think bro! If I was to break down what I mean when I say API contract, I’d start with being able to establish to a shared articulation of what an API does...

My Primary API Search Engines

12 July 2019
I am building out several prototypes for the moving parts of an API search engine I want to build, pushing my usage of APIs.json and OpenAPI, but also trying to improve how I define, store, index, and retrieve valuable data about thousands of APIs through a simple search interface. I’m breaking out the actual indexing and search into their own areas, with rating system being another separate dimension, but even before I get there I have to actually develop the primary engines for my search prototypes, feeding the indexes with fresh signals of where APIs exist across the online landscape. There isn’t an adequate search engine out there, so I’m determined to jumpstart the conversation with an API search engine of my own...

Taking A Fresh Look At The Nuance Of API Search

11 July 2019
I have a mess of APIs.json and OpenAPI definitions I need to make sense of. Something that I could easily fire up an ElasticSearch instance, point at my API “data lake”, and begin defining facets and angles for making sense of what is in there. I’ve done this with other datasets, but I think this round I’m going to go a more manual route. Take my time to actually understand the nuance of API search over other types of search, take a fresh look at how I define and store API definitions, but also how I search across a large volume of data to find exactly the API I am looking for. I may end up going back to a more industrial grade solution in the end, but I am guessing I will at least learn a lot along the way...

Navigating API Rate Limit Differences Between Platforms

10 July 2019
I always find an API providers business model to be very telling about the company’s overall strategy when it comes to APIs. I’m currently navigating the difference between two big API providers, trying to balance my needs spread across very different approaches to offering up API resources. I’m working to evolve and refine my API search algorithms and I find myself having to do a significant amount of work due to the differences between GitHub and Microsoft Search. Ironically, they are both owned by the same company, but we all know their business models are seeking alignment as we speak, and I suspect my challenges with GitHub API is probably a result of this alignment...

The JSON Schema Tooling In My Life

10 July 2019
I am always pushing for more schema order in my life. I spend way too much time talking about APIs, when a significant portion of the API foundation is schema. I don’t have as many tools to help me make sense of my schema, and to improve them as definitions of meaningful objects. I don’t have the ability to properly manage and contain the growing number of schema objects that pop up in my world on a daily basis, and this is a problem. There is no reason I should be making schema objects available to other consumers if I do not have a full handle on what schema objects exist, let alone a full awareness of everything that has been defined when it comes to the role that each schema object plays in my operations...

The Details Of My API Rating Formula

09 July 2019
Last week I put some thoughts down about the basics of my API rating system. This week I want to go through each of those basics, and try to flesh out the details of how I would gather the actual data needed to rank API providers. This is a task I’ve been through with several different companies, only to be abandoned, and then operated on my own for about three years, only to abandon once I ran low on resources. I’m working to invest more cycles into actually defining my API rating in a transparent and organic way, then applying it in a way that allows me to continue evolving, while also using to make sense of the APIs I am rapidly indexing. First, I want to look at the API-centric elements I will be considering when looking at a company, organization, institution, government agency, or other entity, and trying to establish some sort of simple rating for how well they are doing APIs...

Thinking Differently When Approaching OpenAPI Diffs And Considering How To Layer Each Potential Change

08 July 2019
I have a lot of OpenAPI definitions, covering about 2,000 separate entities. For each entity, I often have multiple OpenAPIs, and I am finding more all the time. One significant challenge I have in all of this centers around establishing a master “truth” OpenAPI, or series of definitive OpenAPIs for each entity. I can never be sure that I have a complete definition of any given API, so I want to keep vacuuming up any OpenAPI, Swagger, Postman, or other artifact I can, and compare it with the “truth” copy” I have on indexed. Perpetually layering the additions and changes I come across while scouring the Internet for signs of API life. This perpetual update of API definitions in my index isn’t easy, and any tool that I develop to assist me will be in need constant refinement and evolution to be able to make sense of the API fragments I’m finding across the web...

Why The Open Data Movement Has Not Delivered As Expected

05 July 2019
I was having a discussion with my friends working on API policy in Europe about API discovery, and the topic of failed open data portals came up. Something that is a regular recurring undercurrent I have to navigate in the world of APIs. Open data is a subset of the API movement, and something I have first-hand experience in, building many open data portals, contributing to city, county, state, and federal open data efforts, and most notably riding the open data wave into the White House and working on open data efforts for the Obama administration. Today, there are plenty of open data portals. The growth in the number of portals hasn’t decreased, but I’d say the popularity, utility, and publicity around open data efforts has not lived up to the hype...

API Interoperability is a Myth

03 July 2019
There are a number of concepts we cling to in the world of APIs. I’ve been guilting of inventing, popularizing, and spreading many myths in my almost decade as the API Evangelist. One of them that I’d like to debunk and be more realistic about is when it comes to API interoperability. When you are focused on just the technology of APIs, as well as maybe the low-level business of APIs, you are an API interoperability believer. Of course everyone wants API interoperability, and that all APIs should work seamlessly together. However, if you at all begin operating at the higher levels of the business of APIs, and spend any amount of time studying the politics of why and how we do APIs at scale, you will understand that API interoperability is a myth...

Your API and Schema Is That Complex Because You Have Not Done The Hard Work To Simplify

02 July 2019
I find myself looking at a number of my more complex API designs, and saying to myself, “this isn’t complicated because it is hard, it is complicated because I did not spend the time required to simplify it appropriately”. There are many factors contributing to this reality, but I find that more often than not it is because I’m over-engineering something, and I am caught up in the moment focusing on a purely computation approach, and not considering the wider human, business, and other less binary aspects of delivering APIs. While I am definitely my own worst enemy in many API deliver scenarios, I’d say there are a wide range of factors that are influencing how well, or poorly that I design my API resources, with just a handful of them being: Domain - I just do not have the domain knowledge required to get the job done properly...

The Basics of My API Rating Formula

01 July 2019
I have been working on various approaches to rating APIs since about 2012. I have different types of algorithms, even having invested in operating one from about 2013 through 2016, which I used to rank my daily intake of API news. Helping me define what the cream on top of each industry being impacted by APIs, while also not losing site of interesting newcomers to the space. I have also had numerous companies and VCs approach me about establishing a formal API rating system—many of whom concluded they could do fairly easily and went off to try, then failed, and gave up. Rating the quality of APIs is subjective and very hard. When it comes to rating APIs I have a number of algorithms to help me, but I wanted to step back and think of it from a more simpler human vantage point, and after establishing a new overall relationship with the API industry...

The Complexity of API Discovery

01 July 2019
I can’t get API discovery out of my mind. Partly because I am investing significant cycles in this area at work, but it is also something have been thinking about for so long, that it is difficult to move on. It remains one of the most complex, challenging, and un-addressed aspects of the way the web is working (or not working) online today. I feel pretty strongly that there hasn’t been investment in the area of API discovery because most technology companies providing and consuming APIs prefer things be un-discoverable, for a variety of conscious and un-conscious reasons behind these belief systems.
 What API Discovery Means? Depends On Who You Are… One of the reasons that API discovery does not evolve in any significant ways is because there is not any real clarity on what API discovery is...

Why Schema.org Does Not See More Adoption Across The API Landscape

25 June 2019
I’m a big fan of Schema.org. A while back I generated an OpenAPI 2.0 (fka Swagger) definition for each one and published to GitHub. I’m currently cleaning up the project, publishing them as OpenAPI 3.0 files, and relaunching the site around it. As I was doing this work, I found myself thinking more about why Schema.org isn’t the goto schema solution for all API providers. It is a challenge that is multi-layered like an onion, and probably just as stinky, and will no doubt leave you crying. First, I think tooling makes a big difference when it comes to why API providers haven’t adopted Schema.org by default across their APIs. If more API design and development tooling would allow for the creation of new APIs using Schema...

Avoiding Complexity and Just Deploying YAML, JSON, and CSV APIs Using GitHub or GitLab

24 June 2019
I find that a significant portion of I should be doing when defining, designing, developing, and delivering an API is all of avoiding complexity. Every step away along the API journey I am faced with opportunities to introduce complexity, forcing me to constantly question and say no to architectural design decisions. Even after crafting some pretty crafty APIs in my day, I keep coming back to JSON or YAML within Git, as the most sensible API architectural decision I can make. Git, with JSON and YAML stored within a repository, fronted with a Jekyll front-end does much of what I need. The challenge with selling this concept to others is that it is a static publish approach to APIs, instead of a dynamic pull of relevant data...

Organizing My APIs Using OpenAPI Tags

19 June 2019
I like my OpenAPI tags. Honestly, I like tags in general. Almost every API resource I design ends up having some sort of tagging layer. Too help me organize my world, I have a centralized tagging vocabulary that I use across my JSON Schema, OpenAPI, and AsyncAPI, to help me group, organize, filter, publish, and maintain my catalog of API and schema resources. The tag object for the OpenAPI specification is pretty basic, allowing you to add tags for an entire API contract, as well as apply them to each individual API method. Tooling, such as API documentation uses these tags to group your API resources, allowing you to break down your resources into logical bounded contexts. It is a pretty basic way of defining tags, that can go a long ways depending on how creative you want to get...

Doing The Hard Work To Define APIs

17 June 2019
Two years later, I am still working to define the API driven marketplace that is my digital self. Understanding how I generate revenue from my brand (vomits in mouth a little bit), but also fight off the surveillance capitalists from mining and extracting value from my digital existence. It takes a lot of hard work to define the APIs you depend on to do business, and quantify the digital bits that you are transacting on the open web, amongst partners, and unknowingly with 3rd parties. As an individual, I find this to be a full time job, and within the enterprise, it is something that everyone will have to own a piece of, which in reality, is something that is easier said than done. Convincing enterprise leadership of the need to be aware of every enterprise capability being defined at the network, system, or application level is a challenge, but doable...

There Is No Single Right Way To Do APIs

16 June 2019
My time working in the API sector has been filled with a lot of lessons. I researched hard, paid attention, and found a number of surprising realities emerge across the API landscape. The majority of surprises have been in the shadows caused by my computational belief scaffolding I’ve been erecting since the early 1980s. A world where there has to be absolutes, known knowns, things are black and white, or more appropriately 1 or 0. If I studied all APIs, I’d find some sort of formula for doing APIs that is superior to everyone else’s approach to doing APIs. I was the API Evangelist man–I could nail down the one right way to do APIs. (Did I mention that I’m a white male autodidact?) I was wrong...

API Definitions Are Important

12 June 2019
I found myself scrolling down the home page of API Evangelist and thinking about what topic(s) I thought were still the most relevant in my mind after not writing about APIs for the last six months. Hands down it is API definitions. These machine and human readable artifacts are the single most important thing for me when it comes to APIs I’m building, and putting to work for me. Having mature, machine readable API definitions for all API that you depend on, is essential. It also takes a lot of hard work to make happen. It is why I went API define first a long time ago, defining my APIs before I ever get to work designing, mocking, developing, and deploying my APIs. Right now, I’m heavily dependent on my: JSON Schema - Essential for defining all objects being used across API contracts...

API Evangelist Is Open For Business

10 June 2019
After six months of silence I've decided to fire API Evangelist back up again. I finally reached a place where I feel like I can separate out the things that caused me to step back in the first place. Mostly, I have a paycheck now, some health insurance, and I don't have to pretend I give a shit about APIs, startups, venture capital, and the enterprise. I'm being paid well to do an API job. I can pay my rent. I can go to the doctor when my health takes a hit. My basic needs are met. Beyond that, I'm really over having to care about building an API community, making change with APIs, and counteracting all of the negative effects of APIs in the wild. I can focus on exactly what interests me about technology, and contribute to the 3% of the API universe that isn't doing yawnworthy, half-assed, or straight up shady shit...

2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 | 2019 | Archive