[Caveat: this is focused on HTTP-based, or REST APIs]
In the software world, we often refer to building ‘extensible’ designs. In essence, this means that we can build a system that is light and nimble, capable of changing and growing over time.
In the world of API design, we can’t always make rapid changes. Many API clients become dependent on existing functionality.
Think about this from the perspective of sustainability:
How long can we keep and grow this design?
How long before we have to start over on another version?
Continue reading “How to design APIs that last” »
When I look around the little village of API specialists within the tech world, there are an increasing number, in the last year, with the title “API Product Manager”. Keep in mind that just a few years ago, this job title didn’t exist. There are so many other roles involved in what it takes to lead the build-out of high quality APIs. In my experience, the de facto product owner (title or not) for APIs needs to represent an amalgamation of roles to be the most effective.
The roles listed here are my perspective on what it takes. However, I’d consider this a survey of sorts, and I’d encourage you to leave comments about your perspective.
Continue reading “Who are the best API Product Managers?” »
In the late 20th century, scientists began to flirt with proof that there is dark matter in our universe. As we learned that as much as 96% of the mass of the universe is represented by something we cannot observe, we’re entering a new era of understanding about the nature of matter. However, the struggle in this field is that we only have a measurable knowledge that these things exist, and educated guesses about how much of the universe is comprised of this yet undescribed material.
Integrated software systems using few standards beyond HTTP, better known as Web APIs, now seem to have something in common with dark matter. There are far more organizations building private, or internal-only, APIs as opposed to public API programs. As an industry, this perspective can not be overlooked, and has the potential to change the way we think about developing APIs.
Image credit: http://cosmicweb.uchicago.edu/filaments.html
Continue reading “Dark Matter in the API Universe” »
A brilliant, undiscovered app developer just logged into the front page for your API program (please don’t tell me you just emailed a PDF), and made their first successful call. They’re frustrated, feeling like they don’t understand what just happened, and generally just exhausted.
Hopes of impressing colleagues with a quick demo espousing the ease of adoption have been dashed. They are eagerly digging through your content trying to find a way to explain the value of what your API brings to his company.
…you might be about to lose out on the most serendipitous moment in your companies’ future. Developers you have never met might have the potential to change your future…but only if it’s easy to get started.
Continue reading “Why no one wants to use your API” »
Globalizing APIs is hard. I’ve posted before about some of the pitfalls of dates and times in APIs in The 5 Laws of API Dates and Times, as well as content and currency localization in How to Localize Your API .
One area that I did not get into was how timezones can play a role when a specific time and location are in play.
Simply put: you cannot tell what the UTC offset of a given date+time will be, unless you know precisely where and when it will be. As such, this becomes the defining line for when we should supply timezones.
Continue reading “When API time zones make the difference” »