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. 

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!

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.

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.