December 10th, 2012

API Design Tutorial: The Interaction Model

API  Academy - The Interaction ModelAPI design can be daunting. With so many decisions to make and so many differing opinions available on interface design, it’s easy to feel frustrated by the process.  Even worse, it’s possible to follow bad advice and end up designing an API that developers hate using.

That’s why we at the API Academy stress the importance of making rational decisions rather than irrationally selecting design patterns based on emotion or trends.  We want you to choose your design elements rather than picking them from the latest set of formats or technologies that you’ve heard about.

And that’s why we’re working on a series of tutorial videos, as my colleague Mike Amundsen recently announced. The first of these videos, titled The API Interaction Model – An Introduction, provides an overview of  a design process that will help you consider your user’s perspective in order to make effective design choices later. The ideas I discuss in this video are rooted in user-centered design processes that have been very effective in the software and product design worlds.

If you’re currently designing an API, invest five minutes and watch the video.  It should be time well spent.

November 20th, 2012

Behind Closed Doors: The World of Private APIs

Private APIsAttend any Web API presentation and you are likely to see a graph like this one, demonstrating the growth of  publicly-available Web APIs. Speakers (including me) love using these graphs for good reason: they succinctly capture the explosive growth of APIs that has taken place over the last two years.

It’s a great story but it’s really only half the story. Web API experts regularly acknowledge the existence of a “private” or “closed” API market. In fact, many of us believe that if the number of private APIs in use could be cataloged it would dwarf the 7,000 or so APIs that are published on the ProgrammableWeb site.

As with many of the terms in the API world, there isn’t a concrete definition of  “private API”. In general, a private API has these characteristics:

  1. It provides a language-independent interface that is made available via Web protocols.
  2. It’s access is limited to a specific set of known developers or organizations.
  3. It is not marketed to the general public nor is its documentation made publicly available.

Further to this, we can divide private APIs into three major buckets:

  1. Internal APIs that exist within the organization’s borders (for example, SOAP-based interfaces within an internal Service Oriented Architecture).
  2. Business-to-business (B2B) APIs that enable organizations to integrate with external companies.
  3. Backend APIs that drive mobile, Web and device-based applications.

With this definition we can see that there are a great many integrations that must already exist. Enterprises have been building SOAP and B2B-based connectivity for years and have accumulated healthy inventories of private APIs.

In addition, the headlong rush towards the world of mobile is driving the creation of new externally-facing APIs to help corporations reach their customers. As I’ve talked about before, many organizations wish to retain control over the development of these applications and they can do this with private APIs.

If IT teams have been building these types of in-house connectivity solutions for so many years, there shouldn’t be much room left for innovation or improvement, right?

Not quite. Unlike those who build private APIs, public API designers are motivated by the need for their interfaces to be chosen out of the mass of APIs that are available to their prospective users.  This difference in motivation has created a massive impact on how public APIs are designed and managed. Architects responsible for private APIs have a great opportunity to learn from the public API world by adopting design strategies devised to drive adoption, in a controlled manner.

A good reason to take a developer-centered approach to private API design is the development cost associated with building applications that utilize the interface.  A well-designed private API can reduce the project costs for application development as well as for maintenance and upkeep of the integration.  Good design isn’t easy but it pays off – even when the audience is limited.

Many enterprises are implementing a “private for now and public later” API strategy.  It is a great idea but that doesn’t mean architects shouldn’t strive to incorporate great API design and a solid management solution.

In my next post, I’ll dive into private APIs in more detail and talk about some of the specific challenges that arise when building closed interfaces and how these challenges can be addressed with management solutions.

October 24th, 2012

Improving the API Developer Experience

Developer ExperienceSometimes design concepts are obvious. We know they are implicitly understood and don’t require drawn-out explanations. But sometimes these implicitly-understood concepts aren’t executed in real life because they haven’t been explicitly defined. I’ve come to the realization that designing APIs with the developer in mind is one of those ideas that often has an audience nodding their heads but which only a few take to heart and apply to their API architectures.

We in the API design world have a great opportunity to learn from our brethren in the product design world. The user-centered design approach for products has paid great dividends for those who can understand and apply the idea to their interfaces. The goal is almost stupid in simplicity – design products that your users will enjoy. But, as always, the challenge is in translating a simple concept into real strategies, methodologies and practices that do not lose that fundamental goal while staying applicable to unique marketplaces.

In our world of API design, most of us understand that machine-to-machine integration still involves a human – the developer who develops the client code. That developer – the one who makes or breaks us by deciding to use an API – is our user. While product designers talk about improving user experience, we talk about improving the developer experience.

But how does this actually happen? What do we specifically need to do in order to create APIs that are enjoyable to use? Indeed, what does enjoyable even mean in this context? This developer/API publisher relationship is a unique one and the product-based, user-centered design and human/computer interaction models cannot just be airlifted in. They need to be massaged and transformed so they are applicable to the Web API world, without losing the potential value inherent in a user-focused design.

I hope to explore these ideas over the coming months and come up with recommendations for how we can build API solutions that deliver on the promise of improved developer experience (or DX). I’ll dive deeper into the world of user-centered design and discuss methods for translating these concepts from the world of product design into our API design domain.

October 15th, 2012

API Workshops in Europe

Paris API WorkshopI had a great time presenting on API design and management trends at our London API Workshop a few weeks back. James Governor from RedMonk delivered an exciting talk on APIs, the need for API Management and some stark truths, like the fact that Java is still at the top of the programming pile. All of the trend talk and analysis was followed by a great real-world example when MoneySupermarket.com’s Cornelius Burger described his organization’s journey implementing the MoneySupermarket API with a SecureSpan API Proxy. We had excellent feedback on the event, so I know I wasn’t the only one who learned a lot from our speakers.

I was particularly impressed by the range of industries and organizations that were represented in the audience. We had developers from large enterprise shops, specialized Internet-focused start-ups and even a few entrepreneurs just getting started. I think this range of interest is indicative of the value of Web APIs for all and bodes well for a continued investment in designing great APIs, rather than just chucking them out into the ether.

Next up on the tour is our Paris API Workshop taking place tomorrow (Tuesday, October 16).  As always, we have a great set of speakers lined up, with Martin Duval from bluenove talking about building developer outreach programs and Benoit Herard from Orange Labs discussing their API launch. France has a  great start-up culture and a reputation for enterprises like Orange driving innovation, so I’m expecting good conversation, some excellent API Management presentations and – if I’m lucky – some great wines.

September 17th, 2012

Web APIs are International

APIs are GlobalI had the great fortune of spending last week in India, helping a Layer 7 customer develop a Web API program from scratch. While it’s always exciting to walk into a greenfield situation and build something new, I was doubly excited to be doing this in India, where the concept of open APIs is still fairly new.

Over the last few years, we’ve seen explosive growth in open APIs across North America, lead of course by the avant garde Internet companies on the West Coast. The API Management industry has focused much of its attention on the US market but the Web API movement has definitely made its way to other markets and the push towards mobile and device-based applications is clearly having an influence on enterprise architectures.

Western Europe has had a strong influence on the API scene, with notable government and enterprise organizations diving wholeheartedly into the collaborative, developer-focused open API space. London, in particular, has developed a thriving technology scene with tons of hackathons, codeathons, meetups and start-up companies trying to change the world or at least get rich trying.

At the moment, the open API scene in India is still in its infancy and I’m looking forward to helping the concept blossom in whatever way that I can. As you may be aware, the number of mobile devices being used in India is mind-boggling and the ratio of mobile-use-to-desktop-computing is much higher than in North America or Western Europe.  This quantity of mobile client platforms, combined with the large number of motivated developers on the scene, makes this a very intriguing open API marketplace. I can’t disclose any details on the nature of the project yet… but I’m hoping to to have exciting news to share in the near future, so stay tuned.

I’ve spent most of the summer in North America, for a variety of reasons and I’m excited that I will finally be getting back home to the UK so I can re-engage with the European API and mobile scene. We have some great Layer 7 API workshops scheduled across Europe over the next few months and hopefully we will uncover a few new and noteworthy European API publishers while we are on tour.