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 26th, 2013

Layer 7 Mobile Access Gateway 2.0

Mobile Access Gateway 2.0Today, Layer 7 introduced version 2.0 of the Mobile Access Gateway, the company’s top-of-the-line API Gateway. The Mobile Access Gateway is designed to help enterprises solve the critical mobile-specific identity, security, adaptation, optimization and integration challenges they face while developing mobile apps or opening APIs to app developers. In the new version, we have added enhancements for implementing Single Sign-On (SSO) to native enterprise apps via a Mobile SDK for Android and iOS.

Too many times, we have seen the effect of bad security practices. My colleague Matt McLarty eloquently discusses the gulf between developers on one hand and enterprise security teams on the other in this Wired article on Tumblr’s security woes. Because these two groups have different objectives, it becomes hard to get a common understanding of how you can secure the enterprise while enabling app developers to build new productivity-enhancing apps. While nobody really wants to be the fall guy who lets a flaw take down a business, we can be sure Tumblr isn’t the last stumble we are going to see.

To prevent you being the next Stumblr, we have taken a closer look at the technologies and practices for authentication of users and apps. No one of these seemed to be adequate alone and – while acknowledging the value of leveraging existing technologies –  we realized that a new approach was needed.

For mobile app security, there are three important entities that need to be addressed: users, apps and devices. Devices are the focus of the MDM solutions many enterprises are adopting and although these solutions are good at securing data at rest they fail to address the other two entities adequately.

Because today’s enterprise apps use APIs to consume data and application functionality that is located behind the company firewall or in the cloud, API security is vital to the success of any enterprise-level Mobile Access program. Therefore, APIs must be adequately secured and access to API-based resources must be controlled via fine-grained policies that can be implemented at the user, app or device level. To achieve this, the organization must be able to deal with all three entities.

Based on this, we have proposed a new protocol that leverages existing technologies. We leverage PKI for identifying devices through certificates, OAuth 2.0 is used to grant apps access tokens and finally OpenID Connect is used to grant user tokens. This new approach, described in our white paper Identity in Mobile Security,  provides SSO for native apps and makes sure the handshake is done with a purpose – to set up mutual SSL for secure API consumption.

Furthermore, this framework is adaptable to changing requirements because new modules can replace or add to existing protocols. For example, when an organization has used an MDM solution to provision devices, the protocol could leverage this instead of generating new certificates. Equally, in some high-security environments, the protocol should be able to leverage certificates embedded in third-party hardware.

To simplify the job for app developers, the Mobile Access Gateway now ships with a Mobile SDK featuring libraries that implement the client side of the handshake. The developer will only have to call a single API on the device with a URL path for the resource as its parameter. If the device is not yet registered or there are no valid tokens, the client will do the necessary handshake to get these artifacts in place. This way, app developers can leverage cryptographic security in an easy-to-use manner, giving users and security architects peace of mind.

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.