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.

April 27th, 2012

Tech Talk Tuesday: Developer Management

API Developer Management

Time for another Tech Talk Folks. API developer management. During this interactive one-hour event, we’ll be discussing how enterprises can attract, engage and manage developers for their open APIs.

Open APIs allow enterprises to build communities of third-party developers around their applications and data. But many enterprises struggle to ensure developers actually use these APIs to build apps that deliver real value.

On Tuesday May 1 (add to your calendar) we’ll be offering real-world developer management strategies that will help you get maximum benefit from your APIs.

So be sure to come to the Layer 7 Facebook page at 9am PDT.

How to Attend:

Just visit the Layer 7 Facebook page at 9am PDT on May 1 and click the Livestream icon.

Don’t have Facebook? Simply click here to watch directly through Livestream.

Submit questions on Facebook or use the Twitter hash-tag #layer7live

How to Submit Questions:

On Facebook

•    Click on the Livestream PLAY button to join the stream
•    Click the red “Check in to Chat” button to submit questions

On Twitter
•    Tweet questions with the hashtag #layer7live

Guest Expert: Dana Crane

As Product Manager for Layer 7′s API Portal, Dana Crane sets the direction of the company’s newest product.
His involvement in creating this product has given him deep insight into what it takes to build active developer communities around open APIs.
Dana holds a BSc from the University of Toronto and a diploma in hard knocks from the Internet boom.

Add to Your Calendar

April 13th, 2012

Tech Talk Tuesday: Caching & API Optimization

Written by
 

Geoff Duck Tech Talk TuesdayHere we go again – time for another Tech Talk Tuesday. It’s live, unscripted, interactive and it’s going to be awesome – especially if you love to talk Caching & API Optimization.

We’ve simplified SOAP to REST, we’ve explained OAuth and now, during this interactive one-hour event, we’ll be discussing how open API publishers can optimize the delivery and performance of their APIs using techniques like caching. But it’s a live event, so you never know what might happen, with questions coming fast and from all over the globe.

If you haven’t joined us in the past – take a look at these episodes here on our official Layer 7 YouTube page. They’ll give you a good idea of what Tech Talk Tuesday is all about.

Our special guest this week is Geoff Duck, a Senior Developer and innovative superstar at Layer 7. He’s smart, good looking and thinks fast on his feet. He regularly works with Layer 7 customers, helping them implement API management and SOA governance best practices – so here‘s your chance to interact live with one of our top developers.

We look forward to seeing you there. Get your questions ready and then, on Tuesday (at 9am PST), simply go to our Facebook page, click the Livestream tab and hit play. It’s super easy.

See you Tuesday!

April 10th, 2012

Faking the Cloud in API Management

API Management - Infrastructure Versus SaaSThe CEO of competitor API management provider Mashery recently mentioned a post I wrote discussing tradeoffs of infrastructure-based versus service-based solutions when it comes to API management. Unintentionally, my original post has apparently hit a nerve.

Oren suggests that a “true” Cloud solution can only be SaaS-based. While Amazon Web Services, among others, may take umbrage at that definition, I am also a little confused by Oren’s statement since, by most definitions Mashery, is not a SaaS. Typically, a SaaS provides self-enrollment and self-service aspects. Mashery may let you manage your APIs in the Cloud like Layer 7 or Apigee but it doesn’t do this without help from engagement consultants. In that way, they are more akin to IBM than Salesforce.

In the end, our customers don’t get too caught up in Cloud semantics. Some of our customers want to own a solution, others “rent”. Some want a solution in a data-center, others in a public Cloud. We understand that different deployment models are needed to accommodate different needs. If a Cloud deployment is what you are after, try several vendors, verify what you get and compare each solution’s strengths.