Prototyping APIs

I’ve started work on a tool to help web API designers build rapid prototypes for their APIs. Up until now, I’ve been prototyping APIs on whiteboards, or by building an API endpoint. But, I’d rather have a tool that lets me build an interface really quickly without getting bogged down in details of implementation. I’d like something that lets me focus exclusively on the interface. I couldn’t find anything online, so I decided to give it a go myself.

I’m starting with these principles in mind for the UI:
* No coding
* Static data only
* Support for both RPC and hypermedia APIs (and possibly WS/SOAP)

I bounced the idea off my colleague Mike Amundsen and he was equally excited and had some great suggestions of his own.  So lets see where this goes…. next step, naming the project and getting it in Github.


Improving the Developer Experience

Sometimes 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 one which only a few take to heart and apply to their API architecture.

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

Are Open APIs Too Open for Big Business?

(Reprinted from my blog entry at Layer 7 dated July 12, 2012)

I’ll admit it.. I’m a “big enterprise” guy. I’ve either worked for or worked with very large enterprise organizations for most of my career and I’ve seen these companies struggle with the challenge of incorporating ideas that are spawned from the collective brain trust of the theorists, coders and entrepreneurs that exist in the chaos outside the enterprise’s doors.

It took time and some adaptation for concepts like open source software, social media integration and viral marketing to become part of the enterprise world and I believe that opening up Web APIs will require a similar shift in mindset to work on the enterprise stage. The biggest ships take the longest to turn but modern businesses (even the most risk-averse) must be open to leveraging new technologies and architectural philosophies in order to avoid being left behind.

The buzz around Web APIs has definitely piqued the interest of big business and large enterprises have dipped their toes into its waters with the release of a few compelling APIs over the last year. But, along with the excitement generated from opening new consumer channels and new avenues for innovation, there is still a prevailing sense of danger associated with the API movement.

For many enterprises, there is a fear that publishing APIs means giving up control of their services and data to an army of anonymous 16 year-old mobile developers. After all, who wants their carefully crafted brands and products to end up at the mercy of the masses? We’ve seen marketing experiments with “crowd sourcing” produce some interesting results in the past, so there is reason to be cautious when opening up the doors for collaboration in any form.

Of course, the good news is that the challenge of controlling APIs can be elegantly addressed with a strong API Management system.   However, publishers will also need to ensure that they provide enough accessibility to their API libraries or they will run the risk of exposing wonderful APIs that sit unused, waiting for developers to utilize them. APIs are only useful when they are used and a closed-door policy will not encourage anyone to sign up.

Making APIs attractive to the developer community is the key to increasing usage and it is becoming clear that developers want stability and control in the APIs they use. For example, Twitter’s continued restrictions on API usage and Facebook’s closure of the face recognition API have created a small wave of backlash amongst their developer communities. While it’s not enough of a storm to make much of a dent in the uptake of Twitter or Facebook APIs, application developers are realizing that building their apps based on APIs from which they may lose access is ultimately a losing proposition.

This is good news for larger enterprises as it signals a growing level of maturity in the API market and the need for stable, fairly-priced APIs that can support apps in the longer term. A set of well-designed, secure APIs with a well thought out revenue model is exactly the right fit for the large enterprise world.

So, are open APIs too open for enterprises? Probably. But enterprises will need to adapt or risk being unable to reach their customers as the device revolution continues at its explosive pace. Conversely, launching a poorly-designed API library just to get it out there can be an equally devastating misstep. Organizations need to think carefully and plan their API strategies in order to find the perfect balance between control and accessibility.

It isn’t easy for enterprises to embrace open APIs but when the risks are managed properly with a well-built API Gateway, developer portal and API strategy, the rewards can be immense.