Observations on API and Mashup Management API and Mashup Blog

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.

Comments (0)  |  Add a comment

*required Add a Comment

Test Driven Development with Web APIs

Often when automating test driven development we don't take the time to create a solid log of what is happening in each test. This is especially troublesome for tests that involve live connections to web APIs.

Development teams can use a free Apigee web API proxy to help give visibility into those tests that fail.
Here is an example of what is needed to use Apigee in a test driven development environment. In this case we use Ruby, but the concepts are applicable to any language.

 

  1. Setup a new proxy (or multiple proxies) at Apigee



  2. Setup your test initialization code to use the Apigee proxy URL
    require 'test/unit'
    require 'uri'
    require 'open-uri'
    require 'rubygems'
    require 'json'
    require 'active_support'
    require 'htmlentities'
    require 'twitter_search'
    class TwitterApiTest < Test::Unit::TestCase
      
      SEARCH_URL = 'http://twitter-growl-unit-test.apigee.com'
      TwitterSearch::Client::TWITTER_SEARCH_API_URL = "#{SEARCH_URL}/search.json"
      
      def test_twitter_search_api
        q = '@apigee'
        @search_tweets_client = TwitterSearch::Client.new 'Twitter Growl'
        @search_tweets_client.query(:q => q).each do |r|
          assert r.text.include?(q)
        end
      end
    end
  3. Run your tests
     


  4. use Apigee to better understand how your tests are using web APIs when they succeed and debug things when tests fail

 

As Apigee evolves we will provide more granular views of each request. In the meantime, happy testing.

 

Comments (0)  |  Add a comment

*required Add a Comment

On Availability

We've built Apigee as a highly available (HA) service because Apigee's users depend on us to deliver their traffic. More than anything we have to ensure that our services and proxies are as transparent and as light as possible. Much of the magic behind our proxying technologies comes from our cluster of Sonoa's ServiceNet boxes, which efficiently balance the proxy load and in worst-case scenarios failover to other parts of the cluster. And to test the responsiveness of our systems and people, Brian, Apigee's GM, sometimes conducts surprise fire drills in the middle of the night.

image

Manoj debugging during the holiday party

In mid-December, we noticed some strange patterns in our daily traffic reports, and we set out to investigate. While the ServiceNet proxies are highly available, other parts of the system, while important, are somewhat less mission-critical. Eventually we discovered that one customer's database tables were impacting the performance of our analytics server—to the point that it was unable to keep up with all the traffic statistics, making it appear as if traffic had dropped. It appeared like we had suffered a big dip in traffic, even though no proxies had been directly affected. This may have affected other accounts as well, so if in mid-December you noticed any unexpected fluctuation in your Apigee analytics, it may have been related to this.

So what have we done to address this? First, we scrambled to work with the customer who had the massive table in our database. That traffic comes from an iPhone app, which means that lots of dynamic IP addresses were blowing the table out of proportion. We worked directly with them to find a better way to identify the traffic, and this fixed things for everyone. It also taught us more about the needs and use-cases of our developers.

Even more importantly, we've identified a weakness in our architecture, and we're moving to address that with engineering. First, we're building a redundant system to make the handoff from the proxy cluster to the analytics server more robust (and also essentially highly available). Furthermore, we're planning to implement technologies to distribute the database queries to better serve analytics report generation. These changes will start to rollout over the next month or so.

The good news is that we're growing and getting better all time. If you have any questions or comments about our response or how you'd prefer us to handle these situations in the future, please comment or post in our support forum. We're listening, and we really want to hear from you.

Comments (0)  |  Add a comment

*required Add a Comment

Flickr Photosets: Monitoring the Flickr API

Because Apigee is a tool used by people who build things on top of APIs, we get to see a lot of cool mashups and tools — Flickr Photosets is one of them, built using the Flickr and Facebook APIs proxied through Apigee.

It's easy to see why this app has so many fans. It's the fastest and most intuitive Flickr app we've seen on Facebook. You can also view and share your comments.  And it's an impressive example of how community can make an app better — with both open source code available for any facebook developer and a rich community discussion forum for users to suggest improvements.

Brad Dougherty, the app developer, uses Apigee to monitor usage, errors, and response time from the Flickr API. We appreciate Brad's great feedback such as making it easy to identify (and rate limit) different URLs by API method calls specified by parameters - we've heard that across a few users, and we are working on it. We asked Brad for his comments on working with Apigee and for what he's learned through this project.

Although my app hasn't had any downtime since I started using Apigee, it's a great way to monitor that calls to the Flickr API are actually working, something I haven't been able to see in the past. The biggest lesson I've learned from this app is that it can be very taxing to keep up with the changes in Facebook's API. It's a battle to keep adding new features when you keep having to change things to keep up-to-date with Facebook.

Comments (0)  |  Add a comment

*required Add a Comment

Screencast: Creating your first API proxy

The first in a series of how to get started using Apigee to proxy API traffic (looks best in HD).

Comments (0)  |  Add a comment

*required Add a Comment

New features:  SSL support and “Remember-me”

Recently we rolled out two new Apigee capabilities.

First, we've added SSL support for APIs that support the HTTPS protocol. Now you can create an Apigee proxy for an API secured by HTTPS—such as the PayPal API—just specify 'https' in the API URL when creating a proxy. You could also change an existing HTTP proxy to an HTTPS proxy. (Of course, the API in question must support HTTPS, else you'll get an error.)

We're also working on adding SSL support for API providers that want to map to their own domain URL (and therefore their own certificate). Stay tuned, and you can review and comment on our proposed SSL Solution at anytime on our community area.   (You will see that we've completed sections 1 and 4 of the proposal to date..)

Secondly, we've added 'remember me' functionality on log-in.  We'll remember your login for 2 weeks so you don't have to specify your password, just head to app.apigee.com to see your proxies. This also means you can bookmark a favorite chart.

Thanks for the continued feedback—we're prioritizing features based directly on your input!

Secondly, we've added 'remember me' functionality on log-in.  We'll remember your login for 2 weeks so you don't have to specify your password.  This also means you can bookmark a favorite chart.

Comments (0)  |  Add a comment

*required Add a Comment

The Snow Report from the North Face: iPhone API monitoring

As a bunch of skiers, we were excited to see the this app's traffic taking off when our first early winter storm moved in.

The Snow Report from the North Face gives you the best ski conditions around the world, while making it easy to quickly focus on what's local through favorites. 

We love the  UI, feature set, and use of notifications in this app.  The Twitter integration is killer - is a great way to plug into what's really happening so you can doublecheck the official reports.

FactoryLabs - the app developers - use Apigee to monitor API performance and usage for snow conditions, weather, and other data.  They've had great feedback on Apigee - specifically, we'll eventually let you specify fields in the payload that help you ID the developers or consumers using your app. 

We'd love to hear what's on your wish list also on our feedback forum and in the meantime check out the app!

Comments (0)  |  Add a comment

*required Add a Comment

Is Apigee ready for your Production App?

One frequent question over the last six weeks is "if Apigee is still a preview product can I use it for my production app?"

Yes, you can use Apigee as a proxy for production APIs. Dozens of production apps run on Apigee today. (many of which we'll keep showcasing on this blog)

The current Apigee preview is built on a proven platform and architecture that delivers carrier-grade levels of uptime. Some specifics:

  • Apigee's core is our Sonoa ServiceNet enterprise platform. This is the same API Infrastructure that runs over 60 financial services, media, and SaaS companies running critical apps at high traffic levels.
  • From the load balancers to the database and everything in between, we built redundancy into every level of Apigee.
  • We designed Apigee for zero downtime upgrades so that your proxies will stay up and running even as we apply fixes for bugs and enhance Apigee with new features.
  • Our uptime targets for the preview are 99.9% for API proxies and 99% for the Apigee website.
  • And we have operational teams in San Francisco, USA and Bangalore, India constantly monitoring Apigee so that we can respond 24x7 to any issues.

So even though Apigee is currently in private preview, we take your business very seriously and we've built the service to be enterprise-grade from the ground up.

Comments (0)  |  Add a comment

*required Add a Comment

Turbocharged Twitter Followers : A killer tool using Yahoo Pipes and YQL

Who needs Twitter follower notifications clogging up their inbox? Why doesn't Twitter provide an RSS feed? And why isn't it easier to identify spam-followers?

Turn off those pesky emails and get your updates in RSS with Twitter Follower Notifications.

This tool uses Yahoo! Pipes to create an RSS feed that gives a ton more info about your new followers, like:  

-Their bio and location
-Their last five tweets
-Whether or not they follow you, too
-Whether their updates are private or public

Bonus: you could use this tool for any Twitter user, which could be useful for seeing whos following friends or other 'persons of interest'.

Walk through the code and see how amazing Yahoo Pipes is - instant mashups without the need for tools or a server, all in a beautiful UI that makes it easy to share, clone and build on other ideas.   And YQL makes the web a huge database for your app. 

Twitter Follower Notifications was built by Marsh Gardiner (@earth2marsh), who uses Apigee to give him traffic stats and alerts to help him better understand how people use this tool. He's also been very active in the Apigee feedback forum, pushing us to make Apigee even better. Thanks Marsh, we're listening!

Comments (0)  |  Add a comment

*required Add a Comment

Recent Apigee upgrades and fixes

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!

Comments (0)  |  Add a comment

*required Add a Comment

Social Mention: API monitoring for social sentiment and alerts

Warning: don't try Social Mention unless you have 20 minutes - it's addicting.

Social Mention is a social media search platform that aggregates user generated content from across the universe into a single stream of information. 

It analyzes content on terms like apigee (score to the left) or Sam Ramji (screenshot below) and gives you alerts, feeds data and a sentiment scorecard. 

Think Google Alerts but for social media.

Jon, who built Social Mention, uses Apigee to monitor their social media API.

We're working hard to get per developer quota enforcement in soon for Jon and the rest of Apigee users that have been asking for this feature on our feedback forum.

Check it out!

 

Jon, the developer of Socialmention, uses Apigee for reporting on the outbound API.

Comments (0)  |  Add a comment

*required Add a Comment

Birdwatching on Facebook: Eyeing API response and error rates for a social app

We spotted a great Facebook app in the wild.

Bird.im's Facebook app - apps.facebook.com/birdwatching - brings birdwatchers together to share and discuss their latest finds. 

This is a very well designed and full featured app - enabling sharing of bird photos, locations, discussions and connecting passionate enthusiasts with similar interests.   The Facebook platform at it's best.

The Birdwatching Facebook app provides an API for Facebook to consume when the user performs 'one-click' AJAX actions such as adding a bird, a country, or a photo for a spotting.  This streamlines entry creation by offering an alternative over a simple form and directly improves user engagement as users create and share more entries.   In the future, an iPhone app that enables entries from the field will also consume this API.

Hugo and the bird.im team (@birdim) use Apigee to measure API response rates and errors.  (see how Apigee calculates API response rates and API error rates in previous entries).

Thanks to Hugo for all the great feedback on our Apigee Feedback forum!

Comments (0)  |  Add a comment

*required Add a Comment

How to Setup DNS

Comments (0)  |  Add a comment

*required Add a Comment

How to Setup an API

Comments (0)  |  Add a comment

*required Add a Comment

Shopdiggity.com:  API monitoring for user experience and monetization

Need to compare prices for a blueray DVD ?  Or baby car seats?

Shopdiggity.com offers a streamlined comparison online shopping experience across hundreds of product categories and brands.

Shopdiggity has a fast, clean UI that makes browsing Shopzilla's massive product catalog more approachable.   It's a great example of an app that adds value and monetizes a publisher API and affiliate marketing program.

Christopher, Shopdiggity's owner, uses Apigee to monitor performance and response times from Shopzilla's API.

Some great feedback from Christopher -  we need to add more email alerts so that developers can respond to changes in API behavior.  For example, if the Shopzilla API has slow response time, an alert would help him adjust ad campaigns to balance between user experience and monetization.

Thanks to Christopher for the great example and the feedback on Apigee.   If anyone has more,  please hit us on Apigee's Get Satisfaction forum.

Comments (0)  |  Add a comment

*required Add a Comment

mLocal:  iPhone app API monitoring and analytics

Apigee isn't only for API providers - if you use APIs in your mashup, mobile, or social app you can monitor those APIs as well.

Why?  You might want to find out before your users if an API is slow or down, leaving big holes in your app where content should be.  Or verify any terms of use or bill you get from an API provider.

For example, if you're an iPhone developer you know nobody will use a slow iPhone app.

Shorepoint systems is one iPhone shop using Apigee for this purpose on their iPhone apps. Their mLocal app is great for creating and sharing local listings.

mLocal makes heavy use of RESTful APIs for content and especially to communicate to a back-end content app hosted on AWS. Shorepoint uses Apigee for monitoring and debugging of these API calls between the iPhone client and AWS (in both QA and production), and especially to monitor response times and proactively find out if any API call is slowing down iPhone app performance. 

Thanks to Rajan of mLocal for all the feedback on Apigee and check out mLocal here!

Comments (0)  |  Add a comment

*required Add a Comment

How Apigee calculates API error rates (featuring Twitter Growl and the Detroit Tigers)

Last time we showed how Apigee calculates API response time. This time we want to discuss how Apigee calculates API error rates.

Apigee provides charts and tables with API error rates by day, hour or minute with drill downs by API URL. 

The 'error rate' calculation itself is simply # of errors divided by # of requests. Errors include both any Apigee error (including those that you might configure) or any target error (such as a rate limit error from the Twitter API).

Let's show this with Brian's Twitter Growl mashup.  Twitter Growl provides alerts on topics using Mac's Growl alerts.   For example, Brian gets alerts for Tweets on Detroit and Michigan news.

Brian monitors Twitter Growl API activity using Apigee.  You can see he had some stretches in mid August and early September with high error rates.  


You can also drill into the days or hours where these spikes in errors occurred, such as this 3 day period in September - high error rates on a single IP that was being rate limited by the Twitter API.



What was happening over this time?   The Detroit Tigers - in a pennant race for the AL Central -  were swept in a 3 game series with the Royals, resulting in rate-limit busting volumes of angst-ridden tweets from the Detroit Twitterati.

So there you have it.  The Tigers are behind all the errors.   (not sure we needed Apigee to tell us that.) And they still have a 4 and 1/2 game lead, FWIW.

If you'd like Twitter Growl to keep you up to date about the Tigers or any other topics on Twitter, thanks to Brian - his version is a fork of a project by visnup on github

Comments (0)  |  Add a comment

*required Add a Comment

How Apigee calculates API response time

API response time and latency

Earlier this week we showed how to caculate the latency that Apigee adds to your total API transaction (vs. not using Apigee as a proxy).

This is different than the API 'response time' that you see in your Apigee API analytics dashboard graphs and tables.

If you've set up your Apigee proxy and have run some traffic, you'll see graphs for "response time" in your Apigee dashboard.  (If you haven't seen a dashboard yet, these metrics include messages, developers, error rates, data in/out, and response time)

For example, the widget above and charts below are some of the data I see for the before/after latency test I ran against the Yahoo Local API in the previous  API latency blog entry, API response time and latency

This 'response time' is the roundtrip latency from time time your request enters Apigee - hits the target - waits for the target's response and that response leaves Apigee on the way back to your client.

Here is how your Apigee dashboard cacluates "response time".       For the timestamps:

    • T1 – when message arrives at Apigee
    • T2 – when message leaves Apigee to go to the target (in this case the Yahoo Local API)
    • T3 – when message arrives at Apigee from the taget
    • T4 -  when messages leaves Apigee to the Client

The Apigee 'response time' graph/table shows  T4 - T1 = Response times of the Apigee Proxy including time taken by the Target.  In this case, the Yahoo Local API response time was about 23 ms.

Hope this is useful and we'd love your comments or questins here or on our support and feedback forum.

Comments (0)  |  Add a comment

*required Add a Comment

Testing API latency and response time with Apigee

There were some good comments last week on TechCrunch on the pros and cons of using a proxy for analytics and protection (or any operational or business policy) on your API.

Biggest concerns discussed were: latency, single-point-of-failure, and loss-of-control.   All great points.

We wanted to talk about latency first.  (and address the other two in a later post.)

A proxy definitely adds latency.   Both for the additional server hop and processing time of the proxy software.    So any proxy needs to minimize latency and add enough value (capability, time-to-market, etc.)  to justify this extra hop.
 
Our conservative estimate for Apigee is to expect 200-400 ms of latency.   This is mostly due to the extra hop and includes the 20-40 ms of latency due to Apigee's proxy 'think time.' (More detail our latency FAQ)

Your mileage might vary based on message size, the policies you are enforcing, and where you are hosted.  For example, our estimates are based on a 5K message size.  If you proxy Twitter with it's small messaages, your latency will likely be less, and if you are processing big message sizes (such as inserting ads into email), it will likely be higher. 
 
Test it yourself

Soon we'll introduce a tool to test your Apigee proxy's latency during the proxy setup process. In the meantime, you can test this yourself with Apache Workbench (or cURL) by:

1. Set up your Apigee proxy (or feel free to use my Yahoo Local API proxy in the steps below)
2. Open up a terminal.
3. Run a *before* test -  get the latency *without* apigee.  Run this Apache Workbench command (for 10 test requests). 

For this example, I'm using the Yahoo Local API's example API methods.
 
ab -n 10 http://local.yahooapis.com/LocalSearchService/V3/localSearch?appid=YahooDemo&query=pizza&zip=94708&results=2

(This is an apache workbench command where -n 10 specifies 10 iterations)

You should get a results set in this format (where the "10" was for running the test 10 times). 

 So you can see - just hitting Yahoo Local without a proxy I get a latency of 250ms for all 10 requests.

4. Next, I get the latency *with* Apigee using my Apigee proxy URL.  (Feel free to use this URL yourself, don't worry, I rate limited it in Apigee)
 
ab -n 10 http://yahoo-local-1.apigee.com/LocalSearchService/V3/localSearch?appid=YahooDemo&query=pizza&zip=23662&results=2
 
In this case my results are:

In this case, my longest response with Apigee is 357ms.

5.  Subtract (3) from (4) and there is your approximate latency for the proxy.   Here the latency was roughly 357 ms - 250 ms = 107 ms for my 10 requests, on my verizon card outside Berkeley's Cafe Roma.  (thanks to Yahoo Local's great API for the recommendation.)
 
Run this a couple times to make sure your responses are consistent, and also mixing up your API query parameters so you don't accidentally compare a cached vs non-cached response time. For example, I changed zip codes in my Yahoo Local requests.

Comments (0)  |  Add a comment

*required Add a Comment

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.

Comments (0)  |  Add a comment

*required Add a Comment

Setting up DNS

Comments (1)  |  Add a comment

*required Add a Comment

Troubleshooting

Comments (0)  |  Add a comment

*required Add a Comment

Docs

Comments (0)  |  Add a comment

*required Add a Comment

Available

Comments (0)  |  Add a comment

*required Add a Comment

API protection and control

Comments (0)  |  Add a comment

*required Add a Comment

API analytics

Comments (0)  |  Add a comment

*required Add a Comment

buttons

Comments (0)  |  Add a comment

*required Add a Comment

Price

Comments (0)  |  Add a comment

*required Add a Comment

For

Comments (0)  |  Add a comment

*required Add a Comment

How long does it take to set up?

Comments (0)  |  Add a comment

*required Add a Comment

Pricing

Comments (0)  |  Add a comment

*required Add a Comment

Welcome to Apigee!

Welcome to the Apigee Blog! 

Apigee is a website that can give you analytics and throttling for APIs.  Think of it kind of as a cross between “Google Analytics for APIs” and an API circuit-breaker that will protect your app from any traffic spike on your API.  It’s ‘freemium’ , self-service API management.

Apigee works by giving you a proxy that takes metrics and enforces rate-limiting and other policies on your API traffic as it flows.  So if you offer an open API - you can use Apigee between your API and customers to provide usage statistics and protect your back end with API throttling.  Or if you have an application that uses an API, such as an iPhone app or a mashup - you can create a proxy for an API you are using in the app (such as Yahoo Local’s search API) and hit the API through your Apigee proxy to get alerts if that API is not working as it should.  Or to double-check if your service is delivering to SLA or if someone is billing you for API usage.

Apigee is currently in a private preview and we’re hoping you’ll sign up for an invite.  We’re adding a few accounts every day, so it might be a few days. It would be a big help if you can tell us about your API and what you’d like to do.

Apigee is built by Sonoa Systems on our Sonoa ServiceNet platform - this is the same technology platform that we use for our enterprise customers doing high scale, complex API and policy management.  We try to write everything we’ve learned about API technology and management over on our API Infrastructure blog.

And there’s more about Apigee on the FAQ, we’re @apigee on twitter, and you’ll also see a ‘feedback’ tab floating around the margin of this page as well - so we hope you will tell us what you think and give Apigee a spin !

Comments (1)  |  Add a comment

*required Add a Comment

Blog

Comments (0)  |  Add a comment

*required Add a Comment

Sign Up

Comments (0)  |  Add a comment

*required Add a Comment

How can I keep in touch with Apigee?

Comments (0)  |  Add a comment

*required Add a Comment

What happens if I want to cancel my account and move off of Apigee?

Comments (0)  |  Add a comment

*required Add a Comment

Who is Sonoa and how does Apigee technology relate to Sonoa products?

Comments (0)  |  Add a comment

*required Add a Comment

Can I move Apigee in-house if I ever need to?

Comments (0)  |  Add a comment

*required Add a Comment

Is there support for Apigee?

Comments (0)  |  Add a comment

*required Add a Comment

What are Apigee’s availability levels?

Comments (0)  |  Add a comment

*required Add a Comment

Is my data private and secure?

Comments (0)  |  Add a comment

*required Add a Comment

What is the expected latency that Apigee adds?

Comments (0)  |  Add a comment

*required Add a Comment

How much traffic will my Apigee account support?

Comments (0)  |  Add a comment

*required Add a Comment

What problems can I solve with Apigee?

Comments (0)  |  Add a comment

*required Add a Comment

Can I get a demo?

Comments (0)  |  Add a comment

*required Add a Comment

What does Apigee cost?

Comments (0)  |  Add a comment

*required Add a Comment

How do I sign up for Apigee?

Comments (0)  |  Add a comment

*required Add a Comment

Who is Apigee for?

Comments (0)  |  Add a comment

*required Add a Comment

What is Apigee?

Comments (0)  |  Add a comment

*required Add a Comment

What types of APIs does Apigee support?

Comments (0)  |  Add a comment

*required Add a Comment

Does Apigee work with my existing API keys or existing security scheme?

Comments (0)  |  Add a comment

*required Add a Comment

Do I have to use an Apigee URL as my API endpoint?

Comments (0)  |  Add a comment

*required Add a Comment

Freemium and self-service

Comments (0)  |  Add a comment

*required Add a Comment

Industrial-strength

Comments (0)  |  Add a comment

*required Add a Comment

For API and mashup developers

Comments (0)  |  Add a comment

*required Add a Comment

API control

Comments (0)  |  Add a comment

*required Add a Comment

API protection

Comments (0)  |  Add a comment

*required Add a Comment

API analytics

Comments (0)  |  Add a comment

*required Add a Comment

FAQ

Comments (0)  |  Add a comment

*required Add a Comment

Features

Comments (0)  |  Add a comment

*required Add a Comment

Home

Comments (0)  |  Add a comment

*required Add a Comment

Back to top