Clearly, there is business value to be attained by companies who utilize an API, and an accessible web API is a requirement for modern corporations.  For companies looking to launch an API, there is a temptation to focus on the technological aspects of implementation.  Good API design, architecture, and infrastructure are vital to the success of a company’s API, but there are other areas to address first.  I am currently reading the book “Why Nations Fail”, and recently read “Thinking Fast and Slow” by Daniel Kahneman.  Although the former is a geopolitical study whereas the latter focuses on the human mind, both share an identical observation that is the foundation of their arguments: a great amount of economic study is flawed because it fails to account for human behavior and tendencies.  I feel the same way about technology.

Every paradigm shift in technology has been driven by both innovation—the new technology itself—and application—how that technology can be used.  In other words, there is a machine side and a people side to every technology change.  The technologists responsible for implementing these changes often bias towards their comfort zone—the machine side—and overlook the people side.  This has led to frustration for companies who invest significantly in new technology only to miss the intended benefits of the change.  For APIs, the people side of the change is especially important.  In fact, the social nature of the API world means there are even more groups of people to consider.  Ultimately, the success of a company’s API will depend on the creation of a diverse community for that API—end users, partners, developers, and more—as well as the adoption of a business model that allows the API to contribute to the company’s bottom line.  Taking the community and the economics together, this means you will need to build a nation for your API.

Some of the biggest companies on the web have taken this approach with their APIs, and I recently explored some of their winning tactics in this VentureBeat article.  Please have a read and let me know your thoughts, and perhaps your own API lessons

However, the article clearly misstates the capabilities of an API Management solution founded on an API Gateway. I am going to assume that the author only had exposure to API Gateways second hand or through a competitor of Layer 7. Here are the misconceptions propagated by the article, along with some corrections:

“These API gateway services can be prohibitively expensive for small-scale applications…  ‘You can replicate the API gateway by creating a set of proxy services in their data center in an application container in their DMZ.’”

Trying to create your own homegrown set of proxy services is expensive and risky. The Layer 7 API Management Suite’s Gateway technology includes 10 years of functional enrichment and optimization. Such robustness cannot be hacked together on the fly.

“An API gateway still runs on the notion that you have to be careful not to block what might be legitimate traffic. So that could cause some openness – some attacks might slip through using Web application firewall evasion techniques.”

An API Gateway is not a typical web application firewall. Layer 7’s Gateway (evident in the company’s name) has full access to all layers of the data stream and can apply protections at any of these layers.

“Of course, if they can retrieve a developer key, attackers can slip past API gateways until their activity is noticed…  That’s why it’s important to encrypt any data stored on the device, including developer keys[.]”

API keys are not treated as security tokens by an API Gateway. The term “API key” is equivalent to a “database key”, not a security key, so don’t mistake it for a robust access control mechanism. It is mainly an identification mechanism. It is a gross misunderstanding to equate API developer keys with a standard access control cryptographic mechanism like PKI public/private keys.

“But keys have other ways of getting into the wild besides breaking into the application code.”

Right, so you should not rely on these keys for access control. The good news is that the API Management Suite’s Portal/Gateway combination makes it easier to revoke and reissue developer keys.

“For enterprise applications, an API gateway isn’t always enough – users need to get access to content on servers inside the firewall that may not be easily exposed through a Web API.”

And this is where the API Gateway really adds value. The Layer 7 API Management Suite allows companies to turn those backend interfaces from their native protocols into REST APIs or other formats that are friendly to mobile devices.

So, thanks to Ars Technica for flagging up this important aspect of mobile security and here’s hoping that this corrected information is included in the next article.

In order to optimize the performance of mobile apps or browsers, some computation-heavy functions have been offloaded to cloud-based resources, which in turn access backend resources and Web pages. This creates a middle ground in the cloud that is exploited in the attack, which the authors call “Browser Map Reduce (BMR)”. In reading the paper, it’s clear that this is a legitimate threat. The authors actually carried it out using free resources, although they limited the scope in order not to be abusive.

Aside from questions of curiosity around the mechanics of the vulnerability, the obvious question is this: How can we mitigate this threat? Here are a few perspectives here as well as a method for each.

Apps – This “cloud offload” architecture has arisen because of the processing limitations of mobile devices. When a backend resource is requested by a mobile user, it makes sense to have the data returned in the most consumable format, in order to optimize user experience. Whenever possible, instead of doing this through “browser offload”, data should be returned as JSON objects. This API approach is a proven method that works for mobile devices and is not subject to the BMR threat.

Cloud Services – This threat should not be viewed as a dismissal of the “cloud offload” approach. Cloud-based resources are necessary for handling caching, data indexing and other key functions in the mobile paradigm. However, it serves as a warning that these dedicated cloud-based resources cannot be considered part of a walled garden that includes the associated mobile app. The resource’s entry point must be protected against attackers. Layer 7’s SecureSpan Mobile Access Gateway is an ideal choice for this access control, as it uses identity-based measures to ensure that only requests from legitimate sources are serviced.

Web-Based Resources – Although the backend Web resource was not exploited in this scenario, the study is a reminder that the topology of the mobile Web is changing and increasing in complexity. P2P app-to-API connections cannot be assumed and therefore inbound API calls cannot be implicitly trusted. API access must be controlled and the SecureSpan API Proxy is a leading solution for this purpose.

To sum up, this is a legitimate threat but not a reason to abandon the use of cloud-based resources for mobile app optimization. Be aware of the threats, employ the mitigations and then you can continue to enjoy the exciting growth of the mobile Web.

1. Solve the basic functional use cases – The 80% in the 80-20 rule
2. Solve the remaining, more complex use cases – The 20%
3. Deploy the basic functions on an enterprise scale – Back to the 80%

In Phase 3, it’s all about performance, scalability, operability, security, availability and consumability. The problems are very complex but the goal is to make the resulting solution as usable and simple as possible, given the wide range of users, developers, testers and operators that will be involved in its execution. As technology vendors, we are often guilty of focusing inwardly on bells and whistles, rather than outwardly on interoperability. This works well for phases 1 and 2 but brings a reckoning in the third phase. Fortunately, at Layer 7, we’ve spent the past decade working with enterprise clients and have evolved our products to meet their adaptability, reliability and automation needs.

The Layer 7 Management API is at the core of this capability. The Management API ships with all Layer 7 Gateways, to enable automated administration of policies, resources and access control that can plug into enterprise configuration management, deployment and monitoring systems. It can be accessed programmatically through a Java API, on the network through a Web service API or built into command line scripts. For the clients I have worked with, this capability and the assurance it provides on moving through the systems development lifecycle is quite simply a must have.

Recently, we’ve added a number of industry experts to our full-time team, in order to deepen this expertise and expand our delivery. Services have become an increasingly important part of our business and we have just launched a new Services section on our Web site in order to provide details of our service offerings.

Training Services are always the right starting point for new clients and we have a number of courses we can tailor to meet any customer’s needs. Following training, we can customize IT Services to provide consulting, configuration and any implementation activity. Our Business Services help companies explore new opportunities through technology. The current focus is on the many possibilities offered by APIs and we’re very excited to have noted industry experts Mike Amundsen and Ronnie Mitra leading this practice.

Please have a look at all the services we offer and let us know if any of these would help your company out. No matter what phase of a project you’re in, we will be happy to be at your service!

I recently read Daniel Kahneman’s book Thinking Fast & Slow, a fascinating study of how the human mind works. With the new capabilities offered by big data and Cloud computing — the dual themes for next week’s event — and the increasing personalization of technology through Mobile devices, I think we have an opportunity to make our digital systems more human in their processing. What does that mean?  Well, more intuitive in user experience, more lateral through caching of unstructured data and more adaptive to changing conditions. API-Aware Traffic Management certainly reflects this potential.

If you are going to be (or hope to be) at the event, add a response in the comments box or tweet to @MattMcLartyBC. Hope to see you there!

Many people are familiar with Layer 7’s industry-leading security functionality, so it’s no surprise that I’d recommend using our Gateway technology to protect connections from on-premise infrastructure to off-premise Cloud services. The flexibility of deployment options we offer makes it possible to create a network of secure on- and off-premise endpoints to meet the most stringent requirements. This covers security but what about availability?

People seem to be less familiar with Layer 7’s routing capabilities. Our Gateway technology is optimized to perform flexible, content-based routing with negligible impact on overall transaction times. In the context of the Cloud, this means that traffic proxied by a Layer 7 Gateway can be re-directed using intelligent algorithms and even dynamic, state-based awareness. This routing capability, which I call “API-aware traffic management”, brings huge benefits in ensuring availability when connecting to multiple API instances – on-premise, off-premise, in multiple Clouds… anywhere on the hybrid network.

I’ll be discussing this topic in detail at the upcoming Cloud Expo 2012, June 11-14 in New York City. This promises to be a great event, so I hope you can make it and attend my discussion!

It will be interesting to see whether or not big enterprises buy into this “21st century mainframe” concept but what’s clear is that enterprises now want to migrate critical workloads to the Cloud, en masse. To realize the true benefits of Cloud, many of these workloads will have to be running off-premise. But since many will remain on-premise, enterprises will be relying on hybrid Cloud infrastructure for their most significant IT services.

Security remains a major area of concern for organizations looking to leverage the Cloud. Increasingly, availability and reliability are also significant concerns, particularly since Amazon has had a few outages recently. In addition to addressing these concerns, enterprises are evaluating how they can optimize processing volumes to get maximum cost benefit from their Cloud deployments.

Please join me at the Cloud Expo, June 11-14 in New York, where I’ll be discussing solutions for each of these considerations. Hey, we should have blue skies by then!

Up to this point, apps have focused mainly on consumers. But with the BYOD (“bring-your-own-device”) movement’s unstoppable momentum driving mobile devices into the center of the enterprise IT landscape, there is a growing need for enterprise apps that give employees the user experience they are used to with consumer apps. That means a decent chunk of the $3.8 trillion spent on enterprise IT this year could be heading to mobile app developers like you.

Building mobile apps for the enterprise is going to create some new challenges, though. Perhaps most significantly, you will be much more reliant on enterprise data and applications. That’s going to mean a lot of work integrating the functional requirements for your apps and even more work nailing down the non-functional areas like security, scalability and availability. Nevertheless, these challenges are well worth accepting, given the stakes.

The good news is that Layer 7 will be out there making things easier for you. We help enterprises expose data and applications as RESTful APIs, significantly simplifying integration with mobile apps. Additionally, our API Portal product helps developers discover and get maximum value from enterprise APIs. It’s an exciting time for mobile developers and we’re excited to be laying the foundation upon which a generation of enterprise apps will be built.

First of all, in the three-tier architecture of the Web, the line was typically blurry between the presentation and logic tiers and concrete between logic and data. Big data now blurs the line between logic and data. Combine this with the fact that the mobile app development paradigm fragments the presentation platform and it is evident that the API will become the concrete and consistent border in application processing flows. In this context, API management will prove vital in enforcing security, collecting business metrics and normalizing protocols.

Second, big data allows analytics to be performed in the scope of real-time data retrieval. This will create another wave of real-time integration needs in enterprises of every size. More real-time integration means more APIs with higher volumes. The common protocol for exposing big data on the network is REST using either JSON or XML formats. Again, this will mean a greater necessity for API management tools and techniques and a compound benefit in their usage.

Simply put, mobile, Cloud and big data are driving a new era of enterprise IT and API management will provide amplified value for companies embracing these trends.