Video and Slides: 10 Patterns in Successful API Programs »

Thanks to all that attended last week's API Best Practices webinar #3, 10 Patterns in Successful API Programs (and thanks to our presenters @gbrail and @landlessness). The video, slides, and Q&A is below.

Our next API webinar, "API Metrics: What to Measure" with @landlessness and @brianpagano, is June 2nd at 11am PST (sign up here!)

Questions and Answers from the Live Webinar 
 

Q: What is the best way to throttle/rate limit, software vs hardware?

A: If you’re talking about rate limiting at the API level, based on IP address, OAuth token, username, etc., then there are a bunch of good software solutions, including the Apigee Gateway. Some companies, like us, offer their software packaged inside a hardware appliance as well, but there’s nothing special that hardware can offer when it comes to this kind of rate limiting.

Q: Which OAuth do you recommend - 1.1, 2.0 or wait?

A: It’s hard to answer generally for all APIs, but the latest drafts of OAuth 2.0 are pretty mature, and include options that support a lot of use cases. A big advantage of OAuth 2.0 is that you can secure an API using just a security “bearer token” and SSL, or you can use a signature like OAuth 1.0 supported.

Q: What if I am in a big enterprise that has adopted SOAP as a standard for APIs, but I want to expose as REST.  How deadly, weird, etc... is protocol translation?

A: It’s not deadly or weird at all - lots of our customers are doing it. It’s very common to have internal services based on SOAP that meet the needs of the internal needs, but which don’t necessarily make sense to expose to the Internet in that form.  Putting a translation layer in front that can make use of protocol mediation and data transformation to make the SOAP API look like a REST API that supports JSON makes a lot of sense. The performance impact will be minimal unless you are talking about large data volumes (in the 10,000s of requests/second and above) and in that case you can horizontally scale if you need to throw CPU at the problem.

Q: Does it make sense to provide some kind of "notification" to users, which would  inform that certain part of the data is changing?

A I think it depends on the API! Twitter is a good example (I realize that we keep using them) -- they started with an API that requires you to poll, and they evolved to also offer a streaming API that pushes data out with less latency. But keep in mind that any kind of streaming or push API, including a full streaming API like Twitter, Webhooks (a little less complex), or Web Sockets, is going to be more work for a developer to adopt -- if you choose to offer this it should be in addition to something simpler to use that might offer slower performance.

Q: Does Apigee have insight to Cloud Computing Providers exposing API and the adoption of that by users (both individual consumers and businesses)?

A:  In general we’re seeing that every cloud computing provider is offering an API at some point, and that they’re getting used. I’m not sure that we have any more specifics...

Q: Do you have good example of content API ?

A:  We know of some great APIs in the works that are coming out from some leading media providers. In the UK, the Guardian newspaper is a good example of a content API.

Q: Do you recommend any framework (Python or PHP) for a content API ? 

A: There are many and we should do another webinar on this topic. I (Brian) personally like Ruby on Rails because you will get an excellent RESTful API design for free. There are frameworks for Java like JAX-RS. And for PHP there is FRAPI.

Q: Our API is a paid product. Does it make sense to make it free for developers?

A: You should at least expose some of the API methods for free - also known as a freemium model. It’s a really good way to promote adoption. Related to that it’s also good to have API methods that do not require any authentication - usually a simple read-only method.

Q: Is anyone familiar with open source rate limiting software?

A I know that some of the big guys like Twitter build frameworks on top of memcached -- it’s horizontally scalable and it has an atomic integer increment operation that works well.

Q: Do you recommend any developer community for mobile telecom services, like SMS, billing, etc?

A: Twilio has a good developer community with meetups. Also check out what AT&T is doing. They are starting to put together a solid developer community.