I’m writing this first entry at about 30,000 feet on my way back from Red Hat’s North American Partner Conference in San Diego, California. It’s rather appropriate to be typing this out at that altitude, as that is the way I felt for the entire conference after having the opportunity to meet with some amazing ISV, Systems Integrator, VAR and Solution Builder partners who have been building some incredibly powerful solutions using Red Hat technologies. The consistent theme across all of these conversations was making sure that the developers within these organizations had a deep relationship with Red Hat, an understanding of our technology and architecture roadmap as well as the chance to provide more input into how we can all work together.
Continue reading Welcome to the Red Hat developer blog!
This is part four in our “Golden Rules for Great APIs” series (see links at the end of the article), and it tackles a subject which is very easy to pay lip service to but very difficult to deliver on:
Continue reading Building great APIs, part IV: Great developer support
Last week’s “Building Great APIs” article covered two of John Musser and Adam Duvander’s 5 Key Elements of great APIs: providing value and having a business model. In this post, we’ll tackle the next topic:
- Make it simple, flexible, and easily adopted.
The three statements seem obvious until you begin to unpick what they mean–and they might even seem contradictory. Making an API simple seems like a noble goal but it can easily be thwarted by complex edge use cases, existing legacy code and a tendency on the part of some API designers to expose underlying data models in raw form. Flexibility often breeds complexity as the API becomes overloaded to meet many use cases. We’ll take each topic in turn and finish up with an all-important metric: TTFHW (Time To First Hello World).
Continue reading “Building great APIs, part II: Simplicity, flexibility, and TTFHW”
Back in July, John Musser wrote an excellent post over at ProgrammableWeb on what it takes to build great APIs (also check out his OSCON slides on Slideshare). John boils what’s needed down to five key elements—value, plan and business model, flexibility, good management, and great support.
Together with perhaps just one more–stability (an unreliable API is as good as unusable)–these points arguably should represent an “API Gold Standard” for almost any API program. Getting these right goes a long way to running a great API program and we advise anybody running an API to think about them.
Continue reading “Building great APIs, part I: The gold standard”