Retail APIs and Garden Hoses: Making Things Grow in the Enterprise »

APIs are like a garden hose. They can make things grow.

Well that's what I was thinking as I tried to save my roses from the blistering summer heat here in Dallas, Texas. It really started to make sense when I snapped off my trigger nozzle in favor of a sprinkler. I have the quick connect system so it's a piece of cake to swap out attachments. The 104 degree heat was getting to me, and I started to imagine the hose being connected to retail information and inventory - the API being the quick connect and the nozzles being the interface to consumers.

I'm sitting on the patio at this point, the sprinklers doing the work now, and I'm thinking I should grab a beer and really see where this analogy goes. I watch the sprinkler go back and forth, spraying a pattern of precious water across the lawn - and on my FENCE!

No, the source of life cannot be wasted on a board-on-board fence. I get up and carefully plan my assault on the sprinkler, careful not to get wet (note to self: cold water pelting your body when its 104 is not something you should avoid). The sprinkler has all kinds of adjustment mechanisms. I can adjust the spray pattern left or right, long or short. I can control the amount of water going through the valve and of course there's a timer.

Ahhhhh, this like API infrastructure, the control panel for APIs. Crystal clear. Just like the mechanisms of the garden hose nozzle let your control and target different areas of your lawn, API infrastructure lets you optimize your API for various sections of the market - from mobile developers to affiliate marketers. And just like a great sprinkler system, an API infrastructure lets you scale up to cover your whole "lawn." Finally, API infrastructure provides visibility, letting you see where your services are going and how they are being used.

At its core, an API infrastructure lets you harness and control the power of an API and grow your market, just like a garden hose lets you harness the power of water to grow your lawn.

So you know what I did? The next time I went to talk to a prospect I carried a garden hose, quick connect and sprinkler with me (at least they will remember me).

Analogy complete. No!

One more beer (my answer to Job's "One more thing").

API.... A Profit Interface. Another entry on that soon.

Zen and the Art of an API Ecosystem: Building Platforms Through Partnership »

This week MySpace launched the Developer Services program to make it easier for developers on their API to use cool tools for creating, deploying and managing their apps. Through the new portal, developers get better and discounted access to frameworks, hosting, monetization and mobile tools and analytics. We're excited to be one of the partners along with services like PushButton Engine, Microsoft BizSpark and PayPal. 

The Developer Services program highlights the new business imperative for API providers- building an ecosystem- and the ways partnerships support that goal.   

From Tech to Platform 

An open API isn't just about making a technology available- it's about building a platform. The new web economy means billions of devices, millions upon millions of users and thousands of APIs. When your API is deeply hooked into the fabric of the internet, the developer world and the ongoing evolution of tools, devices and services, it gains both greater immediate value and longevity.  

Developers are going to use your API with other APIs, they're going to use monetization and analytics tools, and they're more and more likely to use cloud services that make it easy to scale their stuff. There's a growing opportunity for API providers to form partnerships that simultaneously simplify and improve the development process while enriching the API ecosystem. 

This approach to community and ecosystem is both philosophy and business strategy- a belief that empowering developers to access the tools they want is beneficial to all; and a model that supports adoption, innovation and ROI. 

Sam Ramji discusses Apigee’s new Twitter API Tools with Robert Scoble. »

Robert Scoble of Rackspace caught up with Sam Ramji to discuss the latest release of Apigee and all the new Twitter centric features. Check out the full interview below!

Why modern applications need an API proxy »

Structures of control are spontaneously generated in every environment and every wave of computing.

Today on the web we have a model where browsers are the single point of control for much of what happens, not just at the level of applications, but at the meta-application level as well. Not simply usage (“point-click-type”), but things about usage – who is the user (browser cookie), what are they using the app through (user agent), where did they come from (referrer), what can we infer about their behavioral state, and so on – as well as modifications of usage (browser add-ins, content filters, security modes, local caching for performance). To be sure, some of these things can be and are performed using infrastructure between the browser and the website (such as content filtering, security, and caching), but the guaranteed component is the browser.

This is one of the reasons that Google Analytics is so popular and useful – you can rely on it to tell you useful things about your traffic because it can rely on the browser as a predictable point of control. Including an invisible piece of content on your web page makes the browser fetch data from Google, implicitly sending information that enables Google to report on your usage.

For web and cloud APIs, what is the equivalent structure of control?

Currently there is no one point like the browser. This is for great reasons – APIs are all about reusing application or service logic and rendering it to different form factors: pure logic (built into an internal application computation), web UIs (part of a mashup), and most notably, client applications on a wide range of devices (from PCs to mobile phones, set-top boxes, and tablets like the iPad). These devices are in the early part of a boom that will see over 10 billion individual units in use, representing at least hundreds of unique hardware/software designs. The sheer utility of these internet-connected devices predicts that their usage will drive high demand for APIs rather than standard websites. There are initial specifications like BONDI that suggest a standard contract across all of these for “mobile web applications” that include interaction with the features of the local device (such as a camera or GPS) but they are years from broad adoption and don’t attempt to unify all API access down to a common control point.

Given that APIs are to application logic what RSS is for content, we know they will be very important; at least as important as the visible web that we use today and possibly more important. This suggests that the other things that are spontaneously generated in value-exchange environments like user/customer management, behavior analysis, content filtering, caching, and security – will show up for APIs as well.

The web API equivalent of the browser’s control structure is an API proxy.

This is a control point which unlike a web proxy is fully aware of API content, communications patterns, and able to drive the meta-application controls discussed above. An architecture like Google Analytics which is founded on a browser’s predictable algorithms cannot work in an API setting. The same rule applies to add-ons that modify usage – they can’t do so relying on the local device if they are to be widely adopted. But an API proxy – a server or service on the internet, sitting between the client (regardless of type) – is able to be that point of control. As traffic runs through it, meaningful data can be captured for immediate outcomes (block access, change the message, or respond from a cache) and later used for behavior analysis and business planning. Add-ons that modify usage of the API can be installed at this point (content filtering, adding new information such as advertising, or identity management). All of this can be done while adhering to the contracts of the APIs and supporting the web architecture and rules of HTTP-based applications, and without attempting to solve the logarithmically complex problem of modifications to all the world’s clients.

So API proxies are likely to be necessary for the sustained growth of web and cloud API usage. There are likely to be several nuances that end up differentiating the different implementations and providers of API proxies. The key is to start experimenting with them now in order to build better apps and stay ahead of the competition.

Telco API Management whitepaper with Alan Quayle »

Why aren't Web developers adopting Telco APIs?

We recently teamed up with Alan Quayle on a new Telco API Management whitepaper that discusses issues around API management adoption issues specific to telcos.  

As Alan points out, APIs have been fundamental to telcos for a long time- even the first switch in 1878 exposed an interface for people to make requests to set up telephone calls. 

But because Telco APIs aren't usually presented in a web-centric way, developers have been slow to adopt them vs. some of the other Web APIs.  Telcos need to adapt by making their APIs, tools and processes simpler and more suited to serving much larger numbers of web developers than before.    

We'd love your feedback, you can download the whitepaper here.

APIs as Dark Matter: our vision for Apigee »

We'd like to share some of our thinking about APIs and why it motivates us to build Apigee into the world's best website for API analytics and management. 

The API Economy 

Web APIs are not mainstream, but they will be. The money being made from Amazon, Facebook and other APIs is just the beginning. Today, APIs are measured in hundreds - about 1,400 listed on ProgrammableWeb. Web UIs, on the other hand, are measured in tens of millions.

In the future, many more websites will provide APIs. And new companies will be formed with revenue models exclusively focused on web APIs. If we look 10 years out it's easy to imagine millions of web APIs.

Because APIs, by their nature, are networked together each additional API will amplify the value of existing APIs. That network effect will create an explosion of value that matches or exceeds the magnitude of today's web economy.

That's the API economy. It's going to be big. But we need some important stuff before it becomes a reality. 

APIs are the dark matter of the web 

We know they're out there. We know they're important. We can infer their existence from mashups and integrations - if we update Twitter on an iPhone it shows up on Facebook. However, we're not directly observing or effecting APIs. And until we do, APIs won't have the massive economic impact that websites have had.

Today, there are hundreds of ways to understand websites, privately (Omniture, Hubspot, Google Analytics, etc.) and publicly (Alexa, Compete, Comscore, etc.). In 1995, when Urchin was founded, that wasn't the case. Back then, there were few ways to understand how websites behaved or what people did with them. As a result, websites were often unreliable, they changed slowly and didn't always have the content people wanted. As the tools for understanding the web evolved, the web itself evolved and became more valuable.

Web APIs are about 10 years behind web UIs. Today, we can't benchmark APIs, we can't see which APIs are popular and we can't effect the way APIs behave without writing a bunch of code. 

APIs at Web Scale 

With Apigee we want to fix these problems. We want to make APIs at web scale a reality.

Our initial set of Apigee features is focused on protection and visibility. API providers can setup policies that enforce their terms of use and ensure uptime, acting as a circuit breaker that protect servers from overloading. Mashup developers can create heartbeat policies that monitor the APIs they rely on. With reports and analytics, API providers and mashup developers will gain visibility into their APIs.

Apigee users will be able to anonymously share their API data. Once API data are public, all of us will benefit from a global understanding of the API web. Just as we use Alexa, for example, to understand the UI web, we envision people using Apigee to understand the API web.

It's important that Apigee be a website and follow the rules of the web: Apigee has a simple pricing matrix with a free version, getting started takes about 2 minutes and Apigee will get better as more people use it.

To make the API economy happen we need tools like Apigee to work at web scale. Our company DNA and the technology Apigee uses - Sonoa ServiceNet's API Router - is all about high-scale networking. We've learned a lot from Sonoa enterprise customers about doing this at carrier grade levels of reliability and scale. 

Our Vision 

Apigee gives API providers and mashup developers the visibility, control and scale they need for their APIs. They will be able to share their data publicly so that all of us benefit from a better understanding of the API web. Once we evolve our tools for understanding APIs, we will see APIs themselves evolve and become more valuable.

We are at the beginning of the web API era. In the future, the value created by the API economy will rival that of today's web economy. 

Try it! 

You can take a look at how Apigee works now with YouTube demo videos: one for API providers and one for API Consumers - developers and mashup artists. You can also request an invitation to try the preview of Apigee today.

Case Study: Sonoa on-demand and RightScale »

  RightScale just published a case study on Sonoa's ServiceNet's on-demand API Management service. 

Sonoa's API management solutions ship not only as on-premise (hardware and software) but also as an on-demand service as well.  Many of our customers appreciate the time-to-market benefits of getting started with an on-demand or fully managed service, with the added assurance that they can bring the solution on-premise as their needs change.

For our on-demand service,  RightScale has helped us accelerate the time in which we can to provision a new Sonoa on-demand customer down to less than a day.    It also provides an additional monitoring and management framework that is critical to customer satisfaction.  

Another great business benefit - RightScale helps us provide flexibility for a customer to deploy on multiple clouds, such as Amazon EC2.

RightScale has a great product and a super team.  Again here is the case study!