June 19th, 2013

When Good API Design is a Waste of Time

The idea that good design is essential to building great products and services has become a truism in our industry.  Most of us intuitively understand the idea that expending effort on the design of our code, system architecture and APIs will payoff after implementation.  I’m certainly a big believer in the power of good design for the API space, but I wanted to explore a situation where a design focus might not be necessary.

Consider the case of a small business offering a cloud-based service product for a niche market.  If this business chose to invest in a well-designed, developer-centric API, at a minimum they could expect:

  • A reduced learning curve for developers consuming the interface
  • A reduction in troubleshooting time
  • Increased interest from their developer community

For most audiences, these are goals worth achieving.  Indeed, this is why we emphasize good design for APIs in the first place – the benefits fit remarkably well with the main reasons for embarking on an API strategy: reduced cost and increased adoption.

But, in my conversations with connectivity professionals from larger organizations, it is apparent that not all service vendors see the value in investing in this type of design effort.  Developers and architects are bursting with  tales of forced integration with service providers who have simply thrown an ugly or barely functioning interface on top of  core component.  It is in these scenarios that we hear about laughable attempts at implement whichever API styles and features are in fashion.  ’REST’ and ‘security’ become sales-worthy buzzwords that don’t live up to their promise when developers get their hands on the actual interface when real project work commences.

In the majority of these cases, technical teams have very little say during the procurement process of outsourced and cloud-based services.  In effect, these API providers don’t need to design for their developer audience because they aren’t critical to succeeding.  For many years a sound strategy for selling cloud-based products has been to sidestep technical teams and engage directly with the business.  It’s frustrating that technology teams are often still left with the responsibility for reducing integration costs regardless of the lack of sophistication in the APIs that they are tasked with connecting to.

Thankfully, the wealth of knowledge and connectivity products in the enterprise space allows these teams to reduce the impact of bad design on the overall project and organization.  Components such as API proxies can be used not only to build a facade for APIs that are being exposed, but also to provide abstraction for services that are being consumed.  In essence, the design burden can shift from the service provider, to the enterprise developer who wraps a poorly designed interface in a more consumable, developer-friendly API for the rest of the organization to use.

As a whole, the scenario makes sense.  Well designed products are based in part a designer’s empathy for their users.  Good design involves perceiving a product from a user’s view point along with an understanding of the impact that design decisions will have on the user base.  However, an organization that builds an API as an afterthought for developers, who are only viewed as a means to an end, will likely produce a poor API.

Ultimately, building a technology business based on developer apathy is a bad idea.  The industry shift towards API product based integration is empowering technology teams at all levels and services that continue to ignore the needs of their developers will eventually be ousted from the market.  In short, good design is only a waste of time when you don’t care about your users.  If  in fact you do care about the developers who will be using your API product, then you need to invest in designing your API with their point of view in mind.

March 22nd, 2013

Enterprise Mobility & BYOD – Live Interactive Q&A

BYOD Tech TalkCalling all Enterprise Architects, Application Architects and Senior Developers! For our next API Tech Talk, we’ll be discussing Enterprise Mobility & BYOD live on March 26 at 9am PST. My special guests will be Layer 7 VP of Client Services Matt McLarty and Product Manager for Mobile Leif Bildoy.

The BYOD movement seems to be changing the hardware landscape permanently and it’s showing no signs of slowing down. Naturally, this presents both opportunities and challenges. Security managers within the enterprise have less control then ever. “Anywhere access” has blurred the lines of what used to be called the corporate network perimeter.

So what are CIOs and CTOs specifically worried about with BYOD? Well for one, mobile devices can easily go missing while containing sensitive data and employers often cannot even assess the impact of data security breaches from compromised devices. But locking down employees’ personal devices is generally not an option.

So how can enterprises re-assert control over their data assets while still allowing employees to use their own smartphones as they choose? We’ll be discussing this and other questions during out live, interactive Q&A. So, be sure to clear your calendar and join in the discussion on March 26 at 9am PST.

Here’s How to Join the Discussion
Make sure you click Add to Calendar to get the event details and a reminder in your calendar. Then, on the day of the event, click here to join:

To ask questions, you can:

March 8th, 2013

Nation Building in the Age of APIs

I’ve been working with a number of companies lately on their API strategies.  People seem to recognize that having an API is modern day necessity, but they’re not sure how to get started.  Since APIs are viewed as a technical innovations, responsibility for rolling them out is frequently handed to IT groups.

Clearly, there is business value to be attained by companies who utilize an API, and an accessible web API is a requirement for modern corporations.  For companies looking to launch an API, there is a temptation to focus on the technological aspects of implementation.  Good API design, architecture, and infrastructure are vital to the success of a company’s API, but there are other areas to address first.  I am currently reading the book “Why Nations Fail”, and recently read “Thinking Fast and Slow” by Daniel Kahneman.  Although the former is a geopolitical study whereas the latter focuses on the human mind, both share an identical observation that is the foundation of their arguments: a great amount of economic study is flawed because it fails to account for human behavior and tendencies.  I feel the same way about technology.

Every paradigm shift in technology has been driven by both innovation—the new technology itself—and application—how that technology can be used.  In other words, there is a machine side and a people side to every technology change.  The technologists responsible for implementing these changes often bias towards their comfort zone—the machine side—and overlook the people side.  This has led to frustration for companies who invest significantly in new technology only to miss the intended benefits of the change.  For APIs, the people side of the change is especially important.  In fact, the social nature of the API world means there are even more groups of people to consider.  Ultimately, the success of a company’s API will depend on the creation of a diverse community for that API—end users, partners, developers, and more—as well as the adoption of a business model that allows the API to contribute to the company’s bottom line.  Taking the community and the economics together, this means you will need to build a nation for your API.

Some of the biggest companies on the web have taken this approach with their APIs, and I recently explored some of their winning tactics in this VentureBeat article.  Please have a read and let me know your thoughts, and perhaps your own API lessons

March 8th, 2013

Compromised Twitter OAuth Keys

oauth twitter hackSo Twitter’s OAuth keys have leaked.

What does that mean? Don’t panic. The consequences of a client application’s key being compromised is as serious as user credentials being compromised.

The risk associated with this breach is that a malicious application tricking you into participating in an OAuth handshake (phishing) could access the twitter API on your behalf.

Attackers might come up with clever ways to exploit this leak. In the meantime, avoid using twitter through any application other than the twitter application itself.

OAuth distinguishes between confidential and public clients.

Applications that you can publicly download on your own device (mobile or not) fall in the public category because they are subject to their embedded secret being reverse engineered as probably happened in this case. This incident is a good illustration of the fact that client secrets should not form the basis of a secure session in public clients like mobile applications because, well, those secrets are easily discovered.

Twitter may create new keys for their application and look for ways to better obfuscate them but it’s only a matter of time before these new secrets are also compromised.

As I discussed at Cloud Security Alliance and in our last Tech Talk, authentication involving redirection between applications on mobile device has its risks.

There are ways to completely secure this between applications of a same domain but solving this across 3rd party mobile apps, in a fool-proof way requires either something like a multi-factor authentication or the provisioning of client secrets post-application download which is often not practical.

Either way, API and application providers would do well not relying on pseudo-secrets embedded in publicly available applications as the basis of any security.

In the case of client applications issued by the same provider as the API they consume (e.g. the official twitter app), the password grant type make a lot more sense to me and provides a better UX.

 

January 25th, 2013

Considerations for Private APIs

Written by
 

Considerations for Private APIsIn the past, we’ve talked about the nature of private APIs (those interfaces that are built primarily to serve an organization’s own projects rather than to fulfill the needs of others).  But what are the specific challenges and architectural decisions that need to be made when implementing a private API?

First and foremost, an API can’t be considered private if it is open for widespread public use, right?  A simple way of keeping an API private is to host the interface on a public network without explicitly advertising or documenting its existence.  This can work well initially but may lead to problems in the future. If your service is valuable enough that others want to get their hands on it, even an undocumented, unsupported, private API can easily end up becoming a depended-upon API for application developers, resulting in an outcry when the API publisher has the audacity to modify or retire its own service.

A better approach is to provide access control at run-time and restrict usage of your API to a few known parties. There are a great number of methods for protecting access to internal resources but the best ones are those that achieve a balance between ease of implementation and resistance to infiltration. Security at all costs can greatly increase the complexity of an interface and – in turn – the time required to complete the projects that depend on it. Instead, we need to implement access control that is practical. Thankfully, security protocols like SSL, HTTP Basic authentication and OAuth 2 are great for providing the basic level of access control needed to make it difficult for outsiders to use a private API. Bear in mind that there is much more to API security than simply validating identity but this is the minimum level needed to ensure a degree of privacy.

Although a private API’s developers are generally known to the publisher, the best private APIs utilize API portal components to provide self-service registrations and integration to their private developer communities. This can greatly reduce the friction involved in getting API integration-based projects started and reduce the overall project costs for B2B and mobile-based initiatives. In fact, many of the lessons of simplified design, documentation and administration learned from the public API world can be directly applied to private API management. While the ultimate goal may be different (driving efficient API usage for private APIs rather than far-reaching adoption of open APIs), the ways of getting there are largely the same.

A unique characteristic of private APIs is the need to manage groups of developers. Unlike the public API space, private API publishers will often define out of band contract terms before offering up a quick self-service integration mechanism for that team. This type of group-based role definition is particularly common in integration projects that occur between organizations and can stretch the limits of API portal software that has been built primarily for open API use. Ideally, an API portal should at least be capable of managing developers within groups, communities or organizational affiliations as part of the self-service registration process. Even better, the portal could  provide capabilities for managing whole communities as separate domains within the same infrastructure.

Designing a private API certainly requires a different perspective but the good news is that much of the knowledge around public API design can be directly applied to interfaces you want to keep secret. Of course, building the management and security capabilities required to expose the API to your trusted parties can be daunting but that is why a great API management portal and gateway combination can save the day.