Launch

Apigee was launched in late August 2009 based on a vision of "APIs Everywhere." We think that this decade will be dominated by APIs in the way that the late 90s were dominated by web pages. We saw how powerful APIs were for building some of the world's most useful services and how they were letting developers and providers innovate faster. We believed that the burning need for the growing API Economy was to enable powerful analytics on APIs - in the same way that Google Analytics powers the web economy. We focused on late-stage API providers who already had APIs in production and needed to measure them ASAP.

We attracted hundreds of users, learned a great deal, and made changes in our interface and architecture. We are indebted to the people who gave our service a try, sent us their thoughts on improving the service, and came back for more. We listened very hard and found we'd attracted not just providers but developers as well, and that it was now our responsibility to serve them well.

Learn

The most striking thing we realized was that as great as APIs are, they're still harder for developers to use than they should be.

Many people write about APIs as if the providers are the supply and developers are the demand, competing for the providers' bandwidth and attention. We think that it's exactly the opposite: developers are the supply, and providers are demanding developers' attention, competing for developers who they are relying on to make their service successful.

We believe that developers power the innovation that everyone is asking for. Making developers' lives easier becomes the shortest path to enabling the API Economy.

Simultaneously we saw that getting the attention of API developers was not easy. You can't go into a tech conference and say "raise your hand if you're an API developer" and expect anything but blank looks. However, specific APIs have very loyal communities. Going into that same conference and asking for "Twitter API developers" will get a very different response.

This brings me to the Twitter API. In a relatively short time this API has grown enormously and attracted tens of thousands of developers who are recognized as collaboratively growing Twitter's presence. It's a rich and well-designed API, and a great one to apply tools to support in testing, debugging, and analysis.

Launch @Chirp

So we've dramatically expanded the Apigee platform. Today we're launching two new tools specifically for developers: the API Console and the API Debugger.

The API Console enables developers to learn the structure of an API, send and received test messages, and share snapshots of those messages with other developers on forums, in email, or anywhere a URL is welcome. For our Chirp release, the API Console supports the Twitter API only, including all of the methods listed at http://api.twitter.com including basic authentication and OAuth (the technology under the "sign in with Twitter" feature on so many sites). We'll continue to expand our support for Twitter over the coming weeks and months.

The API Debugger lets developers drop into calls to any API - including their own - and record all of the requests and responses. These can be filtered out to isolate messages from a specific IP address, those that include a particular header, or all messages that generated errors (400+ return codes). This means no mysteries about whether messages were sent or not, no questions about the parameters or the formatting of the response - it's all displayed on a web page in a readable way. This should greatly reduce the effort required in building and launching API-driven applications.

We've also evolved our previously release tools for API Analysis and API Protection. API Analysis has gained a geolocation report to show where in the world API calls are coming from and a "most popular methods" list for a given API. Appropriate to the Chirp launch, we've also added reports for the number of Tweets and Retweets sent by a given application if it's using the Twitter API. For API Protection we've quintupled the rate limit for our free platform - now supporting up to 50,000 calls per hour per API used by a given application.

Finally, we've learned enough from our users that we are ready to drop the "private preview" from Apigee's service and make it a public beta. If you're interested, sign up and get rolling for free.

Thank you to all our users for their support of Apigee so far, and a special thanks to the Twitter team for their help and inspiration in bringing in the new phase of our service. We think developers deserve "a better way to API" and we are working hard to make our API platform as useful and as fun as possible.

Apigee team members will be at Chirp - both at the conference sessions and Hack Day. You can send a message to @sramji or @earth2marsh if you have feedback or want a hands-on demo. We look forward to seeing you there!

As a web developer, I can't tell you how many hours and brain cells I've burned trying to make something that somebody else has already done. As a fan and proud member of the Apigee team, I can't tell you how happy I am that I'll never go down that road again. And neither should you.

If it's not your core competency, somebody's doing it better somewhere else. One of the promises of the web is that our ability to link will allow us to find that improved implementation, the wittier comment, a more pure experience. To a great extent, this promise has been realized in the blogging world; it's not uncommon to see a blog post written in response to someone else's article, quoting still another, with a sidebar full of links to related sources all over the internet. With that in mind, it's intriguing that there's far less evidence of this kind of collaborative notion in the world of web development.

To be sure, whenever we developers implement a JavaScript library or search the web for a way to get around what Internet Explorer is doing to our CSS, we're standing on the shoulders of giants. Using tools provided by others in this way is a step in the right direction, and can provide momentum for a more interesting web, but more needs to be done to disassemble the notion of website-as-silo. We've all seen that attempt to do things that WordPress, Flickr, or Wufoo have already implemented.

I've been just as guilty as any other silo builder out there. It took me a long time to realize, for example, that I could either build a custom movie player, and wrestle with controls and accessibility, not to mention server-side issues like bandwidth and storage, or I could put the videos on YouTube, embed them in the client's site, and deliver a better experience all the way around. That's the point: A federated web application is economical in every sense of the word, but especially because it frees me up to focus on what is truly unique and interesting about my project.

I'm certainly not the first person to make this observation. Not only does the very nature of the web suggest a collaborative approach, but the work done by Peter Nixey in 2006 serves as an excellent proof-of-concept. Nixey's eventsites application allows users to create mini-sites centered around events such as parties or conferences, but does so without storage or server logic of any kind. Instead, eventsites is a single-page JavaScript application that acts as a client to eventful, Google Maps, and Flickr. The genius here is not in the ability to schedule an event, find it on the map, or see photographs related to it. The brilliance is in the aggregation and presentation.

 This is just the tip of the iceberg. Since 2006 we've seen the rise of the API as a valid tool, opening the door to better, easier, and more creative implementations. What we need now is a way to monitor our usage of federated services, and, perhaps most importantly, a way to make them more reliable. That's where Apigee comes in.

Creative and responsible use of the work done by others helps us to fulfill the promise of the web, and empowers us to do work that is interesting, progressive, and inspirational. I'm happy to be a part of that effort, and I can't wait to see what you'll do with the tools we provide.

Earlier this week we released significant UI upgrades for Apigee. We also fixed some bugs identified in our feedback forum.

(We should mention that you won't lose API messages during our planned upgrades - we use a HA architecture so we don't have to schedule downtime.)

The big one is that now the cool screens in the demo video - the animated API setup and proxy rate limiting dialogues (as in this video) - are now live for everyone.  They include some usability tweaks identified by our preview members - thanks.

We also fixed some bugs you found in the API Requests Table and with editing API nicknames.

Here's an overview of the  UI highlights and below are details on more features coming soon.

What's coming next

We're prioritizing our backlog directly based on your feedback.  Coming up soon:

Support for HTTPS & SSL. Thanks to everyone that commented on the solution proposal.

Proxies will come in 2 flavors -  consumer and provider, and we're including Apigee status info in the response header

Finally, we're thrilled when one of our community members suggest a better solution than we had planned.   We love this idea to make IP addresses human friendly.

Thanks again and please keep the ideas coming!