January 8th, 2014

APIs Past, Present & Future – API Predictions 2014

2014 Predictions Tech TalkThe beginning of a new year is a great time to reflect back on the year that was and look ahead to the year that will be. Because 2013 was such an impressive year for API technology, I thought now would be a great time to assemble a panel of API experts and talk about The Past, Present & Future of APIs.

This will be our first API Tech Talk of 2014 and it’ll be a great chance for our audience to interact with the panel, ask questions, make comments and ultimately learn and think about the future of APIs.

At Layer 7, we’re proud to have thought leaders and top industry talent when it comes to API design, API security, the API economy and IoT. On the panel will be members of our API Academy: VP Client Services Matt McLarty; Principal API Architect, North America Mike Amundsen; Principal API Architect, Europe Ronnie Mitra; Product Architect Holger Reinhardt; Chief Architect Francois Lascelles. They will be joined by Layer 7′s Director of Product Management, Ross Garret.

So, we’ve brought together experts from a design/usability perspective, a business perspective, an integration perspective and – of course – an API security and management perspective.

Our customers – and enterprises in general – realize they can transform their businesses through APIs by leveraging their digital assets and taking advantage of all-pervasive trends like mobile, BYOD and IoT. Mobile apps are an integral part of daily life for most of us and smartphone use has become commonplace in the enterprise.  Mobile app developers need APIs to build the exciting applications we all love to use. And as the recent Snapchat security breach teaches us, security is a very important – but sometimes undervalued – aspect of API architecture.

APIs are driving the future of business and there are a lot of considerations when talking about API Management. The API itself needs to be designed well, the security needs to be tight to protect user data, it needs to be developer-friendly and on we go.

While  2013 may very well have been the year of the API, 2014 could be the year APIs go mainstream. So, join us on January 15 at 9am Pacific Time for a live discussion of The Past, Present & Future of APIs. You can tweet your questions or comments directly to @layer7 or you can use the #layer7live hashtag. You can also email your questions directly to us (techtalk@layer7tech.com).

I’m really looking forward to hosting this discussion and think you’ll get a great deal out of the discussion. We value your input and look forward to hearing from you on Jan 15.

December 23rd, 2013

Thanks to All Who’ve Been Good This Year

Layer 7 Holiday Promo 2013The year 2013 has been one heck of an adventure for me. My work with Layer 7, CA Technologies and the API Academy team (yes, we have many names!) has taken me around the world, allowed me to speak at several amazing conferences and provided the chance to interact with some remarkable organizations working on APIs for the Web and enterprise. Along the way, I’ve met many incredibly smart and generous people.

In the last year, I’ve worked with organizations striving to reinvent the role of the enterprise architect from a controlling force to an enabler – a person who ensures the development environment is a safe place to be creative; a person who provides help to product groups and development teams via research and guidance taken from a wide range of sources; someone who works to empower teams and cut down on unneeded ceremony and red tape. These are good people and they’ve been a pleasure to work with and learn from along the way.

I’ve also met many conference organizers and community leaders doing essentially the same thing from a different angle. Along the way, I’ve met people who are devoting huge chunks of time, effort and resources to creating events that improve communication, facilitate collaboration and foster success across a range of communities. It’s been really amazing to be a part of these events and to meet so many giving and open people working toward a common goal.

My experience online has been equally enlightening. In the last year, I’ve “met” many new and interesting people, discovered several helpful efforts and organizations. I am lucky that I can learn something new every day online from those I’d likely never meet in person, simply because we are physically far apart.

One experience in particular has marked 2013 for me. I had the honor to work closely with Leonard Richardson on a book project – RESTful Web APIs. It was Leonard’s idea to create the book and I was happy he invited me to help shape the message and content. I’ve learned a great deal from him and I can see the results of that work in online comments and reviews. I am pleased to be associated with Leonard’s talent and vision.

There’s a common thread through all these experiences: I’ve had the luck and privilege of meeting many “good” people this year. This blog post is my way to give a blanket shout out to everyone who challenged me, taught me, invited me, supported me and hosted me in so many ways in the last year. Thanks!

As another small way of saying thanks, we’re offering several free copies of the RESTful Web APIs book to some of those who’ve been “good” this year. All you need to do is add yourself to our “nice list” (go ahead, you know you deserve it). We’ll be giving away a couple dozen copies of the book soon after the holidays.

So, again, thanks to all for your help and support in 2013. And look out for us in 2014 – things are just getting started!

November 13th, 2013

QCon San Francisco 2013

QCon 2013This Thursday, I’ll be at QCon San Francisco to lead the RESTful Web APIs tutorial. This will be the second time QCon has hosted the full-day workshop and I’m very much looking forward to it. Most of the material I’ve prepared for this workshop is based on the book of the same name by Leonard Richardson and myself. That book was released in September of this year and we’ve been getting very positive feedback on it.

Participants in the workshop will learn how to design a hypermedia type, how to implement servers that safely and consistently expose business functionality using hypermedia and how to build client applications that understand the hypermedia messages and can interact with servers to create enjoyable user experiences.

Along the way several key principles will be explored, including:

  • Why a hypermedia-based message model is better than a code-based object model
  • How Web servers can expose operations as stateless resources instead of as function calls
  • How client applications can recognize and use hypermedia workflow to create quality user experiences
  • Why the hypermedia approach makes it easier to make small changes on the server without breaking existing client applications

The full-day session will also cover important technical aspects of implementing distributed applications over the Web. We will focus on identifying and managing the boundaries between services in order to increase both security and stability over the lifetime of the service. Attendees will get a chance to use existing services as a guide when creating their own and will even get a chance to introduce changes on the backend to see how their client applications can adapt and continue to function.

I always enjoy these extended workshops because it gives everyone (even myself) a chance to write real-life code for real-life services. I spend quite a bit of my time lecturing and advocating for increased reliance on adaptable distributed systems and it’s a rewarding experience. However, it’s also very energizing to work with people in a hands-on atmosphere where everyone is focused on getting things up and running in a working environment.

Of course, there will be lots of fun in the day, too. We have trivia breaks, I offer some handy prizes and we have plenty of time to relax and get to know each other. Overall, these full-day, hands-on workshops represent one of my favorite ways to spend a day with smart, talented people. And I’m grateful to the folks at QCon who make it all possible.

So, if you’re in San Francisco this Thursday and don’t have anything pressing to do, come on over to QCon and join us. Bring your laptop loaded with your favorite Web coding tools and your thinking cap. We’ve got a place all ready for you.

October 30th, 2013

Designing APIs for the Internet of Things (IoT)

API Design for IoTI’m looking forward to our next API Tech Talk for several reasons. First of all, on Oct 31 at 9am Pacific, we’ll be discussing some topics that are very hot in IT right now: the Internet of Things (IoT), API design and – more specifically – how to design APIs with IoT in mind.

Secondly, Holger Reinhardt will be our special guest expert. Holger was a Product Architect at Layer 7 before the company’s acquisition by CA technologies and now he’s Senior Principal, Business Unit Strategy, an expert on IoT and Big Data and all-around great guy.

I also happen to find the concept of IoT – all manner of devices and other “things” connected on the Internet – inherently fascinating . It might be an animal in a field with a biochip transponder or household appliances that alert the homeowner through a mobile application when it’s time for maintenance. Basically, any object that can be assigned an IP address and given the ability to transfer data over a network can be part of the massive Internet of Things. And all these mobile applications and connections across IoT are being designed using APIs.

Of course there are many questions raised by creating such a huge network of things. Security, for one, is a concern. Scale is another – how do you manage the massive amount of data being produced and how do you control access to it? How do you open up APIs to IoT in a secure, scalable way?

API design will be central to answering these questions and addressing these concerns. That’s why Holger will be using tomorrow’s Tech Talk to discuss best practices for designing APIs within the context of IoT. Holger will explore how the ubiquity of APIs in the IoT age will affect API design and answer any related questions you may have.

Here’s how to join in:

October 7th, 2013

SDKs or APIs: What’s the Right Choice for Your Developer Community?

SDK or APIWhen creating an application programming interface (API) for a service, one of the key decisions any program or product manager will face is how best to meet the needs of their prime target audience: developers. Faced with this decision, you want to make sure your API is easy to use and doesn’t represent a high barrier to entry for your specific developer audience.

Currently, the typical approach is to design an interface that leverages the most common protocol on the Web today: HTTP. This is often labeled a “RESTful” API (referring to Roy Fielding’s architectural model for the World Wide Web) and offered as a one-size-fits-all (OSFA) model for developers to use when building client applications for a service. But this is not always the best approach.

Properly understanding and implementing a raw HTTP interface may be too complex for some segments of your developer community – some of whom are really only interested in your service and not in spending time to build a killer HTTP application for that service. Additionally, a generic HTTP API might end up compromising key performance aspects of your service in order to work best for a wide range of developer communities (the OSFA problem). Even worse, an HTTP-based API may – in the end – result in unfocused client applications built by developers who know more about HTTP than your service.

What We Learned from SOAP
One of the powerful lessons learned from the SOAP community relates to the value of developer tooling. The SOAP Web Service Definition Language (WSDL) is a complex, difficult-to-read document that contains all the important details on building a compliant client application for a service. And developers have a hard time making sense of the document. To solve this problem, the SOAP community helped promote an “accommodation” for developers –  the “WSDL” button that is available on many code editors. By simply pressing this button and following a few prompts, developers can easily create API facades for servers or consume WSDL documents to build client applications. The WSDL accommodation makes SOAP programming not only easy, it adds to the usability of SOAP interfaces and lowers the bar for developers wanting to use services on the Web.

What We Lost with HTTP CRUD
The rise of JSON-style HTTP CRUD (Create-Read-Update-Delete) programming interfaces meant the loss of the WSDL accommodation. Developers were expected to hand-craft both the server and client interfaces without the aid of a unifying definition document like SOAP’s WSDL. To make up for this loss, server coding environments like Ruby on Rails introduced helper functions (e.g. “rails new”) designed to generate a great deal of the API facade required in order to publish a service on the Web. Developers could use this accommodation to simplify the interface details and allow them to focus on crafting the internal object and business modeling needed to make the service operational.

Client devs needed to create their own accommodations, too. That’s why we have client-side libraries like ember.js, backbone.js, angular.js and others. Like the developers building servers, client developers needed help handling the basic plumbing for HTTP-based applications, so they could focus on their own object models and business logic.

The bad news is, in this HTTP CRUD world, each and every service has its own unique set of URLs, objects (users, products etc.) and actions (approve, remove, edit, apply etc.). And each API looks like a snowflake among hundreds of other unique interfaces. For example, there are more than 500 unique APIs for supporting shopping services. This can raise the bar for developers and lower the usability of HTTP CRUD APIs.

Adapter APIs
Netflix set out to solve the OSFA problem in 2012 by embracing differences in its developer community and creating a set of targeted “adapter APIs”. These are custom interfaces optimized for selected developer communities. For example, Netflix offers one API for its XBox community and a slightly different API for its PS2 community. In fact, each major device has its own custom API.

What’s interesting about the Netflix approach is that the customized interface accommodations live on the server, not the client. In other words, Netflix has taken on the task of optimizing its interfaces for each community and hosting that optimization on its own servers. A client developer will still be using an HTTP API but it will be one tailored to a specific device – a server-side custom library.

Do SDKs Provide the Answer?
Another way to provide solid accommodations to your HTTP developers is to create software developer kits (SDKs) for your service. Essentially, SDKs provide the same accommodation that WSDL-generated client code does for SOAP interfaces. The good news is that well-designed and executed SDKs can lower the bar for developers and increase service usability.

Recently, Evernote announced that it was taking the SDK approach. One reason for this was Evernote’s decision to use the Apache Thrift message model. The Thrift approach serializes messages using a custom binary format and then ships them across the network using one of a handful of transport protocols (including direct TCP/IP). This is pretty low-level stuff and can easily intimidate some client developers – raising the barrier to entry for Evernote’s API – and this is where creating an SDK is a handy approach. Evernote has committed to building a wide range of language-specific SDKs that clients can download, install and use in their own code. This accommodation lowers the bar when using the Thrift model.

The bad news is that creating SDKs is often a recurring additional expense for your services team. Unlike the WSDL standard, which makes it possible to generate code for a wide range of programming languages from a single published definition file, SDKs usually need to be hand-built for each target programming environment. And selecting target programming languages can turn into a slippery slope. Which languages are most used by your current API consumers? What if the most-used language represents only 30% of your target audience? How many SDKs do you need to build and maintain before you reach a significant portion of your developer community?

The maintenance of SDKs can be substantial, too. How often do you release updates? Fix bugs? Provide new features? Each release can mean added cost to your developer community as they need to open up their own code, integrate the new SDK, run tests and finally re-release their apps to their own target communities. Unless carefully done, this can result in added churn and expense all around – including deployment and download costs for end users. And that can raise the barrier to entry and lower usability.

So What’s a PM to do?
When you start to think about the notion of creating accommodations for target audiences, you have a new metric for assessing the usability and value of your service interface. If you can design an API that is easy for your target audience to use, then you (and your developers) win. If your API is too complex for your audience or relies on a less-used technology, you likely need to include more direct accommodations for your developers.

In some cases, the audience will know how to use SOAP interfaces and will benefit from you offering a WSDL as their accommodation. In other cases, the target audience won’t want/need a SOAP interface and a well-crafted HTTP API (or possibly a set of targeted adapter APIs) will be the right choice. Finally, some target developers will want/need an SDK to handle the protocol details and allow them to focus on their own business logic.

In fact, sometimes the best bet is to offer more than just one of these options in order to reach all your target audiences. Your enterprise partners may prefer a SOAP interface, your mobile devs may prefer a well-design HTTP CRUD API and your business and marketing team may prefer an SDK that exposes only the parts of your service they need to use.

You Own the Interface
The key point in all this is that you own the interface. You can cast your service in many different ways, aimed at several different audiences. You don’t need to stick with a OSFA approach and you don’t have to rule out major technology sectors like SOAP just because a portion of your audience prefers one interface style over another.

By focusing on your target audience and learning their skills and preferences, you can identify key metrics that can drive the selection of the right mix of API styles and accommodations that will help you meet your goals for API reach and usability.