Posted on

The API Game: ”Didn’t We Already Do That?”

How should we be playing this API game?

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 means it will not work ever again. When you are operating 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.

Posted on

Absolutism Around API Tools Increases Friction And Failure

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 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.

Posted on

The Complexity of API Discovery

The Complexity of API Discovery

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 I 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 an investment in the area of API discovery because most technology companies providing and consuming APIs prefer things to be un-discoverable, for a variety of conscious and unconscious reasons behind these belief systems.

What Does API Discovery Mean? Depends on Who You Are...

One of the reasons that API discovery does not evolve in any significant way is because there is not any real clarity on what API discovery is. Depending on who you are and what your role in the technology sector is, you'll define API discovery in a variety of ways. There are a handful of key actors that contribute to the complexity of defining and optimizing in the area of API discovery.

Posted on

Why the Open Data Movement Has Not Delivered as Expected

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 have not lived up to the hype. Why is this? I think there are many dimensions to this discussion, and few clear answers when it comes to peeling back the layers of this onion, something that always makes me tear up.

Posted on

API Management Is About Measuring Value Exchange

APIs are all about measuring the value exchange that occurs between internal groups, with partners, and occasionally with the public when it makes sense. API management is where you start this conversation and has been used for a decade to measure, limit, and quantify the value being exchanged at the API level. Now that API management has been baked into the cloud, we are starting to see the approach being scaled to deliver at a marketplace level. With over ten years of experience with delivering, quantifying, metering, and billing at the API level, Amazon is the best example of this monetization approach in action, with two distinct ways of quantifying the business of APIs.

AWS Marketplace Metering Service — SaaS-style billing model that provides a consumption monetization model in which customers are charged only for the number of resources they use — the best-known cloud model.

Posted on

YAML API Management Artifacts From AWS API Gateway

I’ve always been a big supporter of creating machine-readable artifacts that help define the API lifecycle. While individual artifacts can originate and govern specific stops along the API lifecycle, they can also bring value when applied across other stops along the API lifecycle, and most importantly when it comes time to govern everything. The definition and evolution of individual API lifecycle artifacts is the central premise of my API discovery format APIs.json–which depends on there being machine readable elements within the index of each collection of APIs being documented, helping us map out the entire API lifecycle.

OpenAPI provides us with machine-readable details about the surface area of our API which can be used throughout the API lifecycle, but it lacks other details about the surface area of our API operations. So when I do come across interesting approaches to extending the OpenAPI specification which are also injecting a machine readable artifact into the OpenAPI that support other stops along the API lifecycle, I like to showcase what they are doing. I’ve become very fond of one within the OpenAPI export of any AWS API Gateway deployed API I’m working with, which provides some valuable details that can be used as part of both the deployment and management stops along the API lifecycle:

Posted on

Webhooks In Our API Design Toolbox

Another tool in our API Design Toolbox...

We talk a lot about how webhooks are the 101 of event-driven infrastructure. Webhooks are where API providers begin when it comes to developing an awareness of the most important events that are occurring across their platforms. It is how they begin putting event-driven infrastructure to work to help reduce polling on their API infrastructure. As part of our regular work to map out the event-driven landscape, we've organized a handful of the most common webhook building blocks we've come across.