September 13th, 2013

Nordic APIs

Nordic APIsIt looks like the remainder of September will provide a bounty of learning opportunities for those of you interested in diving deeper into API design.  To start with, Mike Amundsen and I will be continuing our Layer 7 API Academy workshop tour in Montreal and Calgary. In addition to our API Academy events, Mike will be hosting his annual conference related to all things REST with RESTFest 2013. I had the pleasure of attending last year and I highly recommend going if you are interested in thought-provoking conversation and ideas in the hypermedia domain.

On the other side of the ocean and closer to home for me is next week’s Nordic APIs conference in Stockholm (September 18-19).  I’ve been to a few of the smaller API design conferences that the Nordic APIs team has put on and I can say without a doubt that this will be a conference worth attending.  They’ve always done a great job of putting together sessions that will appeal to developers on the leading edge of API design as well as those who are looking for practical solutions.

I’ll be delivering a keynote presentation on a developer experience (DX) oriented design approach for APIs. My colleague Holger Reinhardt will be talking about the Internet of Things and Aran White will be delivering a demonstration of the Layer 7 product line. Of course, the great value in events like this comes from the serendipitous conversations that take place outside the agenda and Holger, Aran and I are really looking forward to swapping war stories with Nordic API attendees.

While I’m sad that I won’t be able to join Mike at RESTFest this year, I’m overjoyed at the reason I can’t go. I’m continually amazed at how much the European API design community has grown and watching the Nordic event grow from a few small events into a major conference has been eye opening. Not too long ago, it was difficult to find API design events to attend but now we are spoiled for choice. It’s a great indication of the continued interest in and growth of Web-based APIs.

August 30th, 2013

Kobo Says Goodbye to the Goodreads API

Written by
 

Kodo/GoodreadsAn API-related news item that caught my interest earlier today speaks volumes about the nature of the burgeoning API market. Kobo  (a seller of eBook readers), has decided to stop using the open book recommendation and review API provided by Goodreads. The reason?  The social site for avid readers was acquired a few months ago by Amazon, which just happens to lead the eBook reader market with its Kindle product.

Acquisitions impacting business partnerships isn’t a new concept. But this event is significant because it highlights a few truths in the Web API space…

APIs Can Change Hands
At one time, Kobo was using a public API offered by a company that had developed a review and recommendation engine that was a serious competitor to Amazon’s.  But – post-acquisition – Kobo found itself in the awkward position of doing business with its main competitor. Not a deal-breaker in itself but it shifted the relationship enough that Kobo had to walk away.

APIs Need to be Mutually Beneficial
Doing business with a competitor is a normal part of most large operations and when your competitor casts as massive a shadow as Amazon does, it becomes almost unavoidable. But public API consumers like Kobo can find themselves in the unenviable position of not having any leverage when consuming a free API. To support a long-lasting business relationship, it is important that both sides benefit from the contract. Kobo’s benefit was obvious – offering readers a high-quality recommendation and review interface translated to a richer user experience and increased sales potential.

So, what did Goodreads get out of the arrangement? From the site’s public terms of service, it appears that marketability and branding were big drivers, as API consumers must display Goodreads branding and links to comply. Kobo may have made a special commercial arrangement with the Goodreads site in order to use its API commercially but it is unlikely to have been one that would have benefited Amazon enough to make it worth supporting a competitor. Once Amazon purchased the Goodreads company and its data, the balance of benefit shifted towards Kobo.

API Providers Can Lose Customers
What I find most fascinating about this story is the fact that Kobo stopped using the Goodreads API before Amazon forced it to. As far as I can tell, the terms haven’t changed significantly, the data is still available and Amazon has stated that it plans to keep the API open for Kobo. Despite all this, Kobo made a decision to walk away. Perhaps taking a hit on features now made more sense than being at the mercy of one of its biggest competitors. For API providers, it is a reminder that your consumers aren’t forced to continue using your APIs. In the future, providers may find that keeping consumers happy becomes just as important as finding them in the first place.

API Consumers Need to Consider the Worst
After Amazon acquired Goodreads, some apprehensive users sought out
alternative sites. While some of these reading sites offer APIs, it appears Kobo has decided to harvest data on its own, having recently announced its entrance into the social reading arena. Putting aside the chances of success, this strategic move highlights the need for businesses to plan for data and service disruption. It means considering the potential impact of having the API you’ve built a business on disappear, even if temporarily. As any lawyer will tell you, planning for divorce before you get married is just common sense.

This decision may be a turning point for one of the companies in this story but that isn’t why I found it interesting. Instead, it is a stark reminder that market forces can have a great impact on the APIs we are learning to rely upon. We often focus on the technical and design aspects of Web APIs but we mustn’t forget that they exist within a dynamic market and both providers and consumers need to be vigilant about handling change.

August 29th, 2013

Steering Safely into the Open Enterprise

Tesla Model SI recently wrote an article for Wired, which discussed the importance of thinking about security at every stage of your application lifecycle.  This is especially important as we enter the new era of open enterprise IT. The explosive growth of mobile computing has shifted the enterprise perimeter and traditional access control mechanisms are no longer sufficient. This is even more relevant when thinking about the Internet of Things (IoT) and its rapidly evolving ecosystem.

George Reese of Dell recently published an article that discusses the Tesla Model S REST API.  This API enables some remote control features on the car and is primarily used by Tesla’s available smartphone apps. Great stuff, showing how mobile meets IOT meets API. The problem is that the focus of the article is all on its potential security vulnerabilities. Where the Tesla developers should be lauded for driving this type of innovation, they are instead scolded for addressing security poorly.

I think this is a great example of where thinking about security all through the lifecycle would have saved the developers some embarrassment. Here are some things for them to think about with the next app or API:

  • Are there other clients besides smartphone apps that I want to access my API?
  • Are there other clients besides smartphone apps that I don’t want to access my API?
  • Are there proven standards or protocols I can use to provide access control?
  • Are there proven tools out there that can help me deliver the solution more quickly?
  • Is there a way for me to revoke a client’s access after it has been granted?

The Tesla team chose to take an unproven path with their authentication solution.  “Security by obscurity” used to be a popular approach but it doesn’t cut it in the open enterprise. In open computing, open and popular protocols like OAuth are the most secure mechanisms to use.  That may seem counter-intuitive but these protocols provide the richest set of implementation tools and breadth of use cases. This allows app developers to focus on their areas of expertise – like automotive innovation – and rely on the security experts for protection.

At Layer 7, our products and services help companies build the foundation for the open enterprise.  Our new Mobile Access Gateway release provides a variety of security capabilities, including smartphone access control and token revocation. Our API Academy helps clients design sustainable APIs that address all aspects of the API lifecycle, including the most practical and comprehensive security protections.

August 20th, 2013

APIs & Hackathons Solve the Innovator’s Dilemma

HackathonEach and every large enterprise began as a brand-new venture created by a few co-founders. The team was small, nimble and innovative enough to carve out a market leadership position through execution and differentiation. As the company grew from a few co-founders to 500 employees, 5,000 employees or 50,000 employees, its pace of delivering innovation slowed. Large companies such as Apple, Intuit and Facebook have continued to prove that this innovator’s dilemma is avoidable. For the rest of the Fortune 1000 – companies that don’t necessarily have access to the Silicon Valley magic – the trend in recent years has been to launch “innovation labs”.

One of the earliest examples of this was Bell Labs at Lucent, with many other enterprises now following suit, such as:

The question is: How will a small team within a large enterprise drive a cultural shift towards innovation and not get stifled by the old guard, which is simply stuck in old habits and processes? The solutions these innovation labs are bringing back to top executives almost invariably involve APIs and hackathons.

The first step is unlocking data via APIs. When a team of innovators at a large company is trying to achieve something disruptive and market-changing, the team members will need access to data from across the company. If they cannot get access, they will be delayed, get demoralized and often just give up and move on. When a company centralizes its APIs across all backend systems, it enables employees, partners and even external developers to build and innovate.

The companies with innovation labs mentioned above have also set up robust API platforms to enable innovation. Some APIs are only available to employees, some to partner companies and others are open to all software developers. The key concept is that they have removed the deadbolt locks on their data and replaced them with APIs that intelligently free those resources, auto-provisioning access based on who, how and what access is needed.

Opening up APIs enables innovation culture, increasing the pace of product design, creation and execution. Once these technology enablers are in place, enterprises can run internal and external hackathons to make developers aware of and inspired by what is now possible. These fast-paced competitions set goals to take creative ideas and turn them into prototypes or minimum viable products.

Hackathons are designed to help developers quickly try out new ideas and get instant feedback. This is similar to the iterative product development methodology described by Eric Reis in his book Lean Startup.  Some enterprises call it the migration from a linear process such as “waterfall” to more agile “scrum” or “customer-driven development” processes. Similarly, “DevOps” has been used to describe increased collaboration and communication between software development teams and IT operation teams.

This is how smart enterprises now solve the innovator’s dilemma. Product lines are reinvigorated and employees are inspired to be more entrepreneurial and productive.  Customers are getting products that take advantage of new technologies. Enablement through APIs alongside action through hackathons solves the dilemma and seeds continuous and disruptive innovation.

August 16th, 2013

Designing Web APIs – A Candid Conversation

API Design WebinarIt was just over a year ago that we hosted our first API Workshop (for the record, it was July 2012 in Sydney Australia). Since then, I and my API Academy buddies Ronnie Mitra and Alex Gaber have had the privilege to meet and talk with hundreds of developers representing dozens of companies and organizations all over the world. It has been a very rewarding experience.

Along the way, we’ve learned a great deal, too. We’ve heard about creative ways people are leveraging the Web to build powerful APIs. We’ve seen great examples of real-world APIs and learned the practices and pitfalls encountered while maintaining and growing these APIs over time. We’ve even had the opportunity to observe and participate in the process of designing and architecting systems in order to foster creative innovation and long-term stability for the APIs.

In the past year, we’ve collected many examples of best practices and distilled common advice from a range of sources. We’ve also created free API events, conducted dozens of hackathons, webinars, one-day workshops and multi-day API boot camps as ways to share what we’ve learned and help others build upon that advice when creating their own Web APIs. And at every event along the way, we’ve met more innovative people doing great things in the Web API space.

As a way to look back and compare notes, Ronnie and I will be hosting a webinar (Designing Web APIs – A Candid Conversation) on August 22 at 9AM PDT. We’ll look back at what we’ve seen on our travels and talk candidly about such topics as SOAP, SOA, REST, lifecycle management and more. It’s going to be a fun hour of both reminiscing and looking forward to this fall’s workshop series and the future of APIs in general.

Also this August, we’re taking a break from offering public events and using the time to compare notes, assess the advice and examples we’ve gathered and improve our content for the upcoming fall season. Ronnie, Alex and I (and many others here) will be spending many hours this month creating new guidance documents, articles and presentations/videos – all in the effort to share what we’ve learned and help others make a difference within their own organizations.

I hope you’ll join us on August 22 for our Webinar and I hope you’ll keep an eye on our workshop schedule for upcoming events near you. Even if you’ve participated in our open workshops before, you’ll want to come back for the new series. We’re adding new topics, brushing up existing material with new guidance from the field and adding new features to the events.