July 12th, 2012

Are Open APIs Too Open for Big Business?

Written by
 

Twitter and Facebook APIsI’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. At Layer 7, our SecureSpan API Proxy gives enterprise customers the tools they need to maintain control over how content and services are used, allowing publishers to lock down APIs as much as they want.

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. That’s why we also offer the Layer API Portal, which is designed to facilitate developer community outreach and secure developer onboarding.

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.com 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.

July 10th, 2012

Hey Twitter: API Management = Developer Management

Twitter APIQuick question for you: What matters most, the client or the server?

Answer: Neither —  they are really only useful as a whole. A client without a server is usually little more than an non-functional wire frame and a server without a client is simply unrealized potential. Bring them together though and you have something of lasting value. So, neither matters more and each actually matters a lot less than half.

In the API world, this is an easy point to miss. The server side always wields disproportionate power by virtue of controlling the API to its services and this can easily foster an arrogance about the server’s place in the world. This effect is nicely illustrated by Twitter’s recent missteps around developer management.

The problems for Twitter all began with a blog entry. Blogs are the mouthpiece of the platform. Tucked away within an interesting entry about Twitter Cards and the potential to run applications within tweets (something that is genuinely exciting), can be found a restatement of an early warning to developers:

“(D)evelopers should not ‘build client apps that mimic or reproduce the mainstream Twitter consumer client experience.’”

Ominous stuff indeed. This was quickly picked up on by Nick Bilton writing in the New York Times Bits blog, who pointed out that the real problem is that Twitter just isn’t very good at writing client-side apps that leverage its own API. Stifling competition by leveraging the API power card can only alienate developers — and by extension the public, who are left with a single vendor solution. Suddenly, it feels like the 1980s all over again.

This ignited a firestorm of concern that was well summarized by Adam Green on ProgrammableWeb. Green acknowledged that API change is inevitable but pointed out that this is something that can be managed effectively — which is not what Twitter is doing right now.

The irony of the whole thing is that, in the past, by exercising its power position, Twitter has actually made great contributions to the API community. In mid 2010, Twitter cut off basic authentication to APIs in favor of OAuth, a drop-dead event that became known as the OAuthcalypse. Hyperbole aside, in terms of actual impact on the populace, this cut over made even Y2K look like the end of days. Given a tractable challenge, developers cope, which is really Green’s point.

What is important to realize is that API Management isn’t technical but social. Win the community over and they will move mountains. Piss them off and they will leave in droves for the next paying gig.

The thing I always remind people is that as a trend, APIs are not about technology; they are a strategy. Truth is, the technology is pretty easy — and that’s the real secret to API’s success. You see, the communications are never the thing; the app is the thing (and that is what WS-* missed). Maintaining simplicity and a low barrier to entry counts for everything because it means you can get on with building real apps.

Now, I can give you the very best infrastructure and tools to facilitate API community. But how you manage this community… Well, that is where the real work begins and — in the end — it’s all a lot less deterministic than we technologists like to admit. People are hard to manage but communities are even harder.

If there is a lesson here, it is that APIs are really about potential and that potential can only be realized when you have two sides — client and server — fully engaged. Mess this one up and you’re left with just a bunch of unused interfaces.

June 7th, 2012

Platform Comes to Washington

Digital GovernmentEveryone wants his or her government to be better. We want more services, better services and we want them delivered cheaper. Politicians come and go, policies change, new budgets are tabled but in the end we are left with a haunting and largely unanswerable question: Are things better or worse than they were before?

One thing that is encouraging and has the potential to trigger disruptive change to the delivery of government services in the US is the recent publication Digital Government: Building a 21st-Century Platform to Better Serve the American People. The word to note here is platform –  it seems that government has taken a page from Facebook, Twitter and the others and embraced the idea that efficient information delivery is not about a carefully-rendered Web page but instead is really a logical consequence of developing an open platform.

I confess to some dread on my first encounter with this report. These publications are usually disheartening products of weaselly management consultant speak refined through the cloudy lens of a professional bureaucrat (“we will be more agile”). But in this instance, the reverse was true: this report is accessible and surprisingly insightful. The authors understand that Mobile+Cloud+Web API+decentralized identity is an equation of highly interrelated parts that, in summation, is the catalyst for the new Internet renaissance. The work is not without its platitudes but even these it bolsters with a pragmatic road map identifying actions, parties responsible and (gasp) even deadlines. It’s actually better than most business plans I’ve read.

Consider this paragraph clarifying just what the report means when it calls for an information-centric approach to architecture:

An information-centric approach decouples information from its presentation. It means beginning with the data or content, describing that information clearly, and then exposing it to other computers in a machine-readable format—commonly known as providing web APIs. In describing the information, we need to ensure it has sound taxonomy (making it searchable) and adequate metadata (making it authoritative). Once the structure of the information is sound, various mechanisms can be built to present it to customers (e g websites, mobile applications, and internal tools) or raw data can be released directly to developers and entrepreneurs outside the organization. This approach to opening data and content means organizations can consume the same web APIs to conduct their day-to-day business and operations as they do to provide services to their customers.

See what I mean? It’s well done.

The overall goal is to outline an information delivery strategy that is fundamentally device agnostic. Its authors fully recognize the growing importance of mobility and concede that mobility means much more than the mobile platforms — iOS and Android, among others — that have commandeered the word today. Tomorrow’s mobility will describe a significant shift in the interaction pattern between producers and consumers of information. Mobility is not a technological instance in time (and in particular, today).

But what really distinguishes this report from being just a well-researched paper echoing the zeitgeist of computing’s cool kids is how prescriptive it is in declaring how government will achieve these goals. The demand that agencies adopt Web APIs is a move that echos Jeff Bezos’ directives a decade ago within eBay (as relayed in Steve Yegge’s now infamous rant):

  1. All teams will henceforth expose their data and functionality through service interfaces.

It was visionary advice then and it is even more valid now. It recognizes that the commercial successes attributed to the Web API approach suggest that just maybe we have finally hit upon a truth in how system integration should occur.

Of course, memos are easy to ignore — unless they demand concrete actions within limited time frames. Here, the time frames are aggressive (and that’s a good thing). Within six months, the Office of Management & Budget must “Issue government-wide open data, content, and web API policy and identify standards and best practices for improved interoperability.” Within 12 months, each government agency must “Ensure all new IT systems follow the open data, content, and web API policy and operationalize agency gov/developer pages” and also “optimize at least two existing priority customer-facing services for mobile use and publish a plan for improving additional existing services.”

If the recent allegations regarding the origins of the Stuxnet worm are accurate, then the President clearly understands the strategic potential of the modern Internet. I would say this report is a sign his administration also clearly understands the transformational potential of APIs and mobility, when applied to government.

June 1st, 2012

The Oracle-Versus-Google Verdict Comes Down

Written by
 

Oracle-Google VerdictWhew! That loud sigh of relief you hear reverberating from Silicon Valley is a reaction to yesterday’s Oracle-Google ruling, which declared that APIs are not protected by copyright. While this case could be far from over – Oracle may appeal and force another $50 million round of litigation – a knowledgeable judge and a well-argued 41-page decision will likely make for a strong precedent.

In the few weeks, since I last discussed this case, I’ve gotten a lot of feedback. While some techies provided commentary supporting Google’s position, more responses came in the form of questions about APIs themselves. Are programming language APIs different from Web, Cloud or other APIs? Does Oracle deserve special consideration due to the time and effort invested? Can one API be “better” than another?

Language APIs certainly appear to be different from Web APIs. They are bound to language syntax and define local functions, which are then compiled or interpreted into bytecode and executed on a low-level platform. Web APIs, on the other hand, are generally language-independent and use basic networking protocols to execute remote services often hosted by an external party.

However, there is an important common bond defined in the acronym itself. Each API is defining an interface to some actual functionality or data. To use a travel metaphor, APIs are not a destination – they are the directions to that destination. Whether it’s a Java class definition, an Amazon S3 storage operation or a Netflix catalog request, an API describes how to do something, get something, calculate something etc.

Because an API is simply a method for accessing an application (the implementation of which is protected under the law), there are many ways to describe the interface, some “better” than others. And Sun Microsystems (later purchased by Oracle) did put time and effort into its creation of a highly-structured Java API.

But structure and complexity are not necessarily the hallmarks of a superior API, as we’ve seen with the move from SOAP Web services to REST-based APIs over the past few years. In fact, generic self-describing APIs simple enough to be navigated without documentation by man or machine are now considered the pinnacle of success, at least according to the Richardson Maturity Model.

When it comes to whether or not APIs can be copyrighted, I happen to be in favor of the ruling as it stands, if only to avert disaster in the IT industry. By taking a strong stand on the issue (even with caveats around extending this ruling to other case law), the judge has possibly prevented a whole new round of lawsuits that could have rivaled the still-ongoing Apple/Samsung/Google patent wars. The last thing the tech world needs is more distractions from all of the fantastic innovation taking place today.

So for now, we can continue to focus on how to secure and govern the applications and data being exposed via APIs. Access to that functionality is the true value of an API and needs to be protected by both technology and the law.

(See Groklaw’s review of the decision for more trial details.)

May 18th, 2012

The Secret Lives of REST APIs

Written by
 

Netflix APIThe recent enterprise acceptance of lightweight REST-based protocols for exposing data and application assets as APIs has been due, in large part, to the simplicity of the resulting interfaces. This simplicity means there is little barrier to entry for developers wishing to consume these APIs in applications built for mobile, Web, desktop, Cloud and gaming platforms. However, as this article from Netflix’s Daniel Jacobson reveals, simplicity can’t be the only goal when designing an API. Flexibility, scalability, optimization, orchestration and adaptation are just a few of the features required in a successful API infrastructure.

At Layer 7, our enterprise customers build incredibly elegant API platforms using our API management technology. Our solutions recognize that one size does not fit all and we provide the tools to adapt to changing requirements without re-architecting new APIs from scratch. Though we certainly support the simple “large number of known and unknown developers” use case Jacobson describes – with robust, scalable technology deployed on a wide variety of hardware, virtual, software and Cloud platforms – we can also address the specific concerns raised by the variety of devices and environments in Netflix’s ecosystem.

Message size, structure and delivery constraints due to device variation represent a large part of the problem. Layer 7 Gateways support the relevant formats and transports and can perform message transformation and protocol mediation on the fly. Policy-based configuration enables custom “virtual” APIs tailored to each device, community of developers or calling application. These format and behavioral changes can be explicit or can be triggered by user identity, app permissions, message content or transaction metadata. Even more complex mediations, such as REST exposure of internal SOAP-based assets, are simple to configure and help to reduce re-implementation costs.

Interaction models can also be optimized and tailored to the calling platform. Composition of comprehensive document-based APIs from multiple backend calls can reduce chatty client interactions. Conversely, small messages from memory-constrained devices can be aggregated into larger, less frequent backend calls. Mobile traffic can be optimized using persistent HTTP(S) connections and over-the-wire compression. And content can be cached at any level of granularity, using an in-memory cache like Terracotta, to reduce the number of calls to the application backend.

As director of one of the world’s most broadly adopted public APIs, Jacobson’s most profound observation is that “public APIs are waning in popularity and business opportunity and… the internal use case is the wave of the future.” API infrastructure needs to support everyone – open API developers, internal coders, contracted development teams and partner groups – especially as mobile workforce enablement and BYOD gain popularity. Layer 7 solutions allow enterprises to make that distinction clear through public vs. private APIs, configurable classes of service and role-based access control.

Jacobson mentions several piecemeal solutions that he and others have attempted to compile into a working platform but notes that those approaches still fall short. Providing an enterprise-grade REST API is no simple feat and it’s great that the truth of the matter is starting to come out. The benefits of a successful API strategy are numerous and well-documented. Layer 7 is the only vendor providing an API management solution that incorporates all the basic necessary functionality and much, much more.