Once again, it’s time for Tech Talk Tuesday here at Layer 7 Technologies. I’m particularly excited about this latest one, as we’ll be welcoming back Mike Amundsen, a Principal API Architect at Layer 7 and an in-demand thought leader on API design and implementation.

This time around, Mike will be talking about Applying the USE Paradigm When Designing Your APIs.  The USE (Usable, Scalable, Evolvable) paradigm provides an extremely useful guide when creating high-level interfaces for your existing business objects and data storage.

Mike will be taking live questions on the USE paradigm and API design generally, so get ready to get involved. Tweet questions with the hashtag #layer7live or email techtalk@layer7.com. On the day, you can watch and chat live on the Tech Talk page.

This looks set to be a very special Tech Talk for anyone interested in API architecture and design – so don’t miss out; join us on Tuesday!

I speak about the power and flexibility of hypermedia quite often. I explain the general idea behind hypermedia, discuss its historical roots and show how it can help client applications adapt to changes in data input and application flow. Essentially, a hypermedia-based approach aims to take key elements often placed into the client’s source code and move them into the actual response messages sent by the server.

I also point out that using a hypermedia-based approach to building client and server applications takes a different kind of effort than using RPC-style approaches. And I explain that, currently, there is a limited amount of tooling available to support the process of designing, implementing and maintaining hypermedia-style systems.

If your work involves designing, building, testing and deploying a mobile client application, it is likely you need to deal with an “application store” or some other process where your packaged application must be submitted for review and approval before it is available to users for download. This can happen not only with well-known public offerings such as the Apple Store but also within any organization that provides its own application repository aimed at ensuring the safety and consistency of user-available mobile apps.

In an environment of quick-turnaround, agile-style implementations this “app store” approval can be a real bottleneck. It may be not just days but weeks before your app is tested, approved and posted. This can be especially frustrating when you want to deploy a rapid-fire series of enhancements in response to an engaged user community.

A hypermedia-based client design can often support UI, data transfer and workflow modifications by altering the server messages rather than altering the client source code. By doing this, it is possible to improve both the user experience and the system functionality without the need for re-submitting the client code for “app store” review and re-deployment. This also has the potential to reduce the need for interrupting a user’s day with download and reinstall events and can, in the process, cut down on the bandwidth costs incurred during the repeated roll outs of code modifications to a potentially large user base.

Improved agility, a better user experience and reduced bandwidth costs are all tangible benefits that are possible when investing in a hypermedia-based implementation for your mobile client application.

I’m happy to announce the release of the first API Academy video shorts. I’ve been working with my colleague Ronnie Mitra to create a series of short (five-minute), informative videos on topics related to the Web, APIs and solution design/implementation.

These first few videos are just the start. We plan on doing more of these shorts on a wide range of topics, over the coming weeks and months. And we need your help. Please take a look at these first vids and send us your feedback.

You can comment here, on YouTube or by emailing me directly. We’re looking for feedback on the format, suggested topics and even how we could improve upon this model (hosting a separate site, adding interaction, badges etc.)

Any time you can spend on watching these and sending comments will be most appreciated. Our aim is to do something helpful, engaging and – above all – enjoyable. Thanks for your help and let’s see what this can become!

The API Interaction Model – An Introduction

—

Three Common Web Architecture Styles

—

Handle Errors on the Web

Attend any Web API presentation and you are likely to see a graph like this one, demonstrating the growth of  publicly-available Web APIs. Speakers (including me) love using these graphs for good reason: they succinctly capture the explosive growth of APIs that has taken place over the last two years.

It’s a great story but it’s really only half the story. Web API experts regularly acknowledge the existence of a “private” or “closed” API market. In fact, many of us believe that if the number of private APIs in use could be cataloged it would dwarf the 7,000 or so APIs that are published on the ProgrammableWeb site.

As with many of the terms in the API world, there isn’t a concrete definition of  “private API”. In general, a private API has these characteristics:

1. It provides a language-independent interface that is made available via Web protocols.
2. It’s access is limited to a specific set of known developers or organizations.
3. It is not marketed to the general public nor is its documentation made publicly available.

Further to this, we can divide private APIs into three major buckets:

1. Internal APIs that exist within the organization’s borders (for example, SOAP-based interfaces within an internal Service Oriented Architecture).
2. Business-to-business (B2B) APIs that enable organizations to integrate with external companies.
3. Backend APIs that drive mobile, Web and device-based applications.

With this definition we can see that there are a great many integrations that must already exist. Enterprises have been building SOAP and B2B-based connectivity for years and have accumulated healthy inventories of private APIs.

In addition, the headlong rush towards the world of mobile is driving the creation of new externally-facing APIs to help corporations reach their customers. As I’ve talked about before, many organizations wish to retain control over the development of these applications and they can do this with private APIs.

If IT teams have been building these types of in-house connectivity solutions for so many years, there shouldn’t be much room left for innovation or improvement, right?

Not quite. Unlike those who build private APIs, public API designers are motivated by the need for their interfaces to be chosen out of the mass of APIs that are available to their prospective users.  This difference in motivation has created a massive impact on how public APIs are designed and managed. Architects responsible for private APIs have a great opportunity to learn from the public API world by adopting design strategies devised to drive adoption, in a controlled manner.

A good reason to take a developer-centered approach to private API design is the development cost associated with building applications that utilize the interface.  A well-designed private API can reduce the project costs for application development as well as for maintenance and upkeep of the integration.  Good design isn’t easy but it pays off – even when the audience is limited.

Many enterprises are implementing a “private for now and public later” API strategy.  It is a great idea but that doesn’t mean architects shouldn’t strive to incorporate great API design and a solid management solution.

In my next post, I’ll dive into private APIs in more detail and talk about some of the specific challenges that arise when building closed interfaces and how these challenges can be addressed with management solutions.

I’m excited to welcome back our API Evangelist Alex Gaber to do his second Tech Talk. Back by popular demand, Alex will take your questions on Optimizing Cloud-Driven Mobile Apps. Alex is a dynamic speaker who knows the app economy inside and out, has built several of his own mobile apps and regularly host hackathons all over the globe.

Building cloud- and API-driven mobile apps introduces complex challenges around syncing, caching and securing data. So, connect live with Layer 7 on Tuesday November 20, at 9am Pacific Time, when Alex will be answering your questions about how to address these challenges. Alex will also provide insight into a range of related best practices, including techniques for building cross-platform applications in HTML 5.

Click here to get the full event details and a reminder in your calendar. On the day of the event, join the event at layer7.com/live and tweet questions to #layer7live.