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.

July 11th, 2013

Federation Evolved: How Cloud, Mobile & APIs Change the Way We Broker Identity

Identity Federation WebinarThe adoption of cloud by organizations looking for more efficient ways to deploy their own IT assets or as a means to offset the burden of data management drives the need for identity federation in the enterprise. Compounding this is the mobile effect from which there is no turning back. Data must be available any time, from anywhere and the identities accessing it must be asserted on mobile devices, in cloud zones, always under the stewardship of the enterprise.

APIs serve federation by enabling lightweight delegated authentication schemes based on OAuth handshakes using the same patterns as used by social login. The standard specifying such patterns is OpenID Connect where a relying party subjects a user to an OAuth handshake and then calls an API on the identity provider to discover information about the user thus avoiding having to setup a shared secret with that user – no identity silo. This new type of federation using APIs is easier to implement for the relying party as it avoids parsing and interpreting complex SAML messages with XML digital signatures, both of which tend to suffer from interoperability challenges.

Now, let’s turn this around. Sometimes what needs to be federated is the API itself, not just the identities that consume it. For example, consider the common case of a cloud API consumed by a social media team on behalf of an organization. When the social media service is consumed from mobile apps, the cloud API is consumed directly and the enterprise has no ability to control or monitor information being posted on its behalf.

Cloud api consumption by mobile - not federated

In addition to this lack of control, this simplistic cloud API consumption on behalf of an organization by a group of users requires that users share the organization account itself, including the password associated with it. The security implications of shared passwords are often overlooked. Shared service accounts multiply the risk of a password being compromised. There are numerous recent examples of enterprise social media being hacked with disastrous PR consequences. Famous examples from earlier this year include Twitter hacks of the Associated Press leading to a false report of explosions at the White House and Burger King promoting competitor McDonalds.

Federating such cloud API calls involves the applications sending the API calls through an API broker under the control of the organization. Each of these API calls is made through an enterprise identity context, that is each user signs in with its own enterprise identity. The API broker then “converts” these API calls into API calls to the cloud provider using the identity context of the organization.

Cloud api, federated

In this case, federating the cloud API calls means that the enterprise controls the organization’s account. Its password is not shared or known by anybody outside of an administrator responsible for maintaining a session used by an API broker. Users responsible for acting on that cloud service on behalf of the organization can do so while mobile but are authenticated using their enterprise credentials. The ability of a specific user to act on behalf of an organization is controlled in real time. This can, for example, be based on attributes read from a user directory or a predefined white list in the broker itself.

By configuring policies in this broker, the organization has the ability to filter the information sent to and received from the cloud provider. The use of the cloud provider is also monitored and the enterprise can generate its own metrics and analytics relating to this cloud provider.

On July 23, I will be co-presenting a Layer 7 webinar with CA’s Ehud Amiri titled Federation Evolved: How Cloud, Mobile & APIs Change the Way We Broker Identity. In this webinar, we will examine the differences between identity federation across Web, cloud and mobile, look at API-specific use cases and explore the impact of emerging federation standards.

April 16th, 2013

Webinar Tomorrow: How to Choose the Right API Management Solution

Written by
 

API Management WebinarOn Wednesday morning, Layer 7 will be hosting a webinar on How to Choose the Right API Management Solution. There are many solutions that cover one or two aspects of API Management – just a portal or just a Gateway or just access control. However, a truly comprehensive API Management platform needs to provide a broad range of functionality in the management of four distinct areas: identity, developers, interfaces and operations. We’ll delve into each of these areas and discuss what to look for from your solution.

We’ll also talk about the “-ilities” of an API Management platform: scalability, manageability, extensibility etc. We will illustrate each of these with a real-world Layer 7 customer example. You’ll see why these and other non-functional requirements matter just as much as the solution’s technical capabilities.

So, please join me and Layer 7 Product Manager Dana Crane as we discuss these key API Management criteria tomorrow. There will be time for questions – both technical and conceptual – and all attendees will receive a free copy of the recently-published Forrester Wave for API Management Platforms. See you tomorrow!

Register now for How to Choose the Right API Management Solution >>

March 7th, 2013

API Business ROI

API ROI WebinarNumerous measurements exist for APIs. On the technical level, these metrics are fairly well understood. However, on the business level, there is a great deal of confusion over how the effectiveness of an API program can be accurately measured.

Layer 7’s March 14 webinar, ROI for APIs – which will feature input from TechCrunch and AT&T – should help to clear up some of this confusion. In particular, the webinar will focus on how hackthons can be used to gather valuable data for API ROI measurement.

How you measure your API ROI will depend on the purpose your APIs play in the greater business picture. Therefore, to provide a little primer for the webinar, I thought it would be helpful to give examples of a few API business models and how they might generate revenue.

  • Per API Call
    Text messages sent via an API are billed at $0.01 per message
  • Per API Payload
    Voice transcriptions via an API are billed at $0.01 per word
  • Transactional Revenue
    An API call delivers a purchase
  • Firehose API
    A monthly subscription provides unlimited API access
  • Platform API
    An existing SaaS platform provides an API for partner integrations

To learn more, register for the webinar – ROI for APIs: Using Hackathons to Evaluate Your API Program featuring TechCrunch and AT&T.

December 11th, 2012

Clarifying “Hybrid Mobile App”

Hybrid Mobile AppsTomorrow, I’ll be presenting a webinar called 5 Ways to Get Top Mobile App Developer Talent for Your Open APIs. Preparing for this webinar got me thinking about different types of mobile app and how they relate to APIs. One thing that occurred to me was how loosely the term “hybrid mobile app” is used – I’ve seen it used to define two very different types of app.

1. Hybrid HTML5/Native Mobile Apps
The term “hybrid mobile app” is often employed to describe an app that is created using a WORA (write once run anywhere) framework like PhoneGap or Appcelerator. These frameworks basically make it simple for developers to generate mobile apps using HTML5, Javascript and CSS.

In the case of Phonegap this app will essentially be a “wrapped” Web site. For PhoneGap apps, developers will often use a UI framework as well, such as JQuery Mobile or Sencha. These UI frameworks look “good enough” on mobile devices, although they should not be confused with the true native UI controls of iOS, Android etc.

In the case of Appcelerator, the generated app can actually leverage the true native sliders, scrollers, date pickers etc. of the device OS. The limitation to this approach is that a developer is fully locked in to what Appcelerator provides. Currently it offers builds for native iOS and Android as well as an HTML5 build, which could potentially be run through PhoneGap.

2. Hybrid API-Driven/Thin-Client Mobile Apps
The term is also used to describe apps that are installed on and run entirely on the mobile device – similar to how a totally native, offline game or other app might work – but which rely on a data connection for presenting Web-based resources, enterprise application functionality or other information assets.

Of course, these information assets are made accessible to the apps via APIs, which is where Layer 7 comes into the equation. In tomorrow’s webinar, I’ll be mainly focused on hybrid mobile apps that are powered by APIs and discussing aspects that are important to address when developing an HTML5 hybrid native app that is also a hybrid API-driven native app. Click here if you want to find out more about the webinar or if you’d like to register.