Big Data: Beyond the ‘Bigness’ & the Technology (video & slides) »

Thanks to all who participated in last week's Webcast, Big Data: Beyond the 'Bigness' & the Technology. We explored moving beyond the "bigness" and technology hype of the typical Big Data conversation to how  businesses need to respond to the explosion of new, disparate and dynamic data sources as social, mobile and cloud influences shift customer interaction to the edge of the enterprise.

The video (~35 min.) and slides are below. Thanks @jhingran.

We'd love to continue the discussion on the api-craft forum.

Mobile Apps 101: Key patterns you need to know (video & slides) »

Thanks to all who participated in the Mobile Apps 101 Webinar last week about "designing apps that people want to use." The video and slides are below.

Check them out for an introduction to some key patterns for mobile app development - repeatable patterns that represent functionality for the front and back-end of mobile apps.  Thanks @edanuff, @gbrail, @timanglade.

We'd also love to hear your thoughts, insights, or questions over on the api-craft forum.

Scaling your API: Predict, Prepare for, Overcome Challenges (video & slides) »

Thanks to all who participated in last week's Webinar, Scaling APIs: Predicting, Preparing for & Overcoming Challenges, in which we examined common bottlenecks and hurdles when scaling your API. We discussed some tips and tricks for how to overcome those challenges as your API traffic grows 10x, 100x, 1000x . . .

The video (~50 min.) and slides are below. Thanks @gbrail and @brianpagano.

We'd love to continue the discussion and get more of your thoughts, insights, or questions on the api-craft forum.

Why APIs? (video & slides) »

Thanks to all who participated in last week's Why APIs Webinar in which Brian explored why APIs are important to your organization, which strategy is right for you (Internal, Partners, Customers or Open API), as well as how to map your API strategy to your objectives and target channels.

The video (~30 min.) and slides are below. Thanks @landlessness.

As always, we'd love more of your thoughts, insights, or questions on the api-craft forum.

API Facade Pattern: Webinar shorts full series »

In March, we tried something a little different with our Webinars - a series of short presentations (~30 min. each).

Our first "shorts" series covered the API Facade Design Pattern. Here's a roll-up of the links to the video and slides for all 4 Webinars. 

As always, we'd love more of your thoughts, insights, or questions on the api-craft forum.

Check out the full series of blog posts around API Facades.

HATEOAS 101: Introduction to a REST API Style (video & slides) »

Thanks to all who participated in the HATEOAS 101 Webinar this week. 

The video (~30 min.) and slides are below. Check them out for an introduction to the core principles, examples, and a look at the value of the approach for API providers and app developers. Thanks @landlessness.

As always, we'd love more of your thoughts, insights, or questions on the api-craft forum.

The API Facade Pattern: People »

Thanks to all who participated in the fourth and final episode in the Webinar Shorts series on the API Facade pattern.

The fourth episode covers people considerations - the team structures, the roles and responsibilities and the politics - for building and using an API facade. The video (~22 min.) and slides are below. Thanks @landlessness.

Check out the videos and slides for all 4 episodes.

As always, we'd love more of your thoughts, insights, or questions on the api-craft forum.

“APIs: A Strategy Guide” O’Reilly author webinar & free chapter »

Last week O'Reilly hosted a webinar by the authors of the new O'Reilly book "APIs: A Strategy Guide."  Video and slides are below. 

The book is an overview of API strategy for business executives and this webinar dives into both public and private API strategies.

Thanks to O'Reilly, @daniel_jacobson, @gbrail and @danwoodscito.

Courtesy of O'Reilly, a free book chapter is posted here.

The API Facade Pattern: Technology »

Thanks to all who participated in the third episode in the Webinar Shorts series on the API Facade pattern. The third episode covers technology for an API facade. The video (~15 min.) and slides are below. Thanks @landlessness. 

Check out the videos and slides for all 4 episodes.

As always, we'd love more of your thoughts, insights, or questions on the api-craft forum.

API Product Management: Driving Success through the Value Chain (slides & video) »

Thanks to all who attended the API Product Management: Driving Success through the Value Chain Webinar.

Video and slides are here. Thanks to @jenmazzon, @sramji and a big thanks to our special guest host, Michael Hart @michaelhart. As always, we'd love more of your thoughts, insights, or questions on the api-craft forum.

The API Facade: Common Patterns »

Thanks to all who attended the second episode in the Webinar Shorts series on the API Facade pattern. The second episode covers common patterns for an API facade. The video (~20 min.) and slides are below. Thanks @landlessness.

Check out the videos and slides for all 4 episodes.

As always, we'd love more of your thoughts, insights, or questions on the api-craft forum.

The API Facade: Overview »

Thanks to all who attended the first episode in the Webinar Shorts series on the API Facade pattern.

The first episode is an overview of the idea and theory of API facades. Here are the video (20 min.) and slides. Thanks @landlessness

Check out the videos and slides for all 4 episodes.

As always, we'd love more of your thoughts, insights, or questions on the api-craft forum. 

Visibility at the Edge - Deep Insights from your API (video & slides) »

Thanks to all who participated in last week's strategy webinar:
Visibility at the Edge - Deep Insights from your API

Thanks to our speakers @jhingran and @brianpagano.

Here are the slides and video. Also, check out our follow-up posts this week in which our speakers further explore the topics of this Webinar hour. 

We'd love more of your thoughts, insights, or questions on the api-craft forum.  Or tune in to the new IRC channel #api-craft.

The Anatomy of Apps »

Thanks to all who participated in last week's strategy webinar:
The Anatomy of Apps - How iPhone, Android & Facebook Apps Consume APIs

Thanks to our speakers @edanuff, @landlessness and @sramji.

Here are the slides and video. We'd love more of your thoughts, insights, or questions on the api-craft forum.  Or tune in to the new IRC channel #api-craft.

HUGE: Running an API at Scale »

Thanks to all who participated in last week's strategy webinar - HUGE: Running an API at Scale.

And thanks to our speakers @sramji, @brianpagano, and @edanuff.

Here are the slides and video. We'd love more of your thoughts, insights, or questions on the api-craft forum.  

API Trends: What to expect in 2012 »

Thanks to all who participated in last week's webinar:  "API Trends: What to expect in 2012" with Sam @sramji, Anant @jhingran, and Brian @brianpagno.

Here are the video and slides. Thanks for a great interactive session.

We'd love to hear more of your thoughts and questions; please join the conversation on the api-craft forum.

“Bigger, Better Business with OAuth” API strategy webinar - video & slides »

Thanks to all that attended yesterday's webinar "Bigger, Better Business with OAuth."  

Unfortunately, we had a Webex outage which cut the webinar audio off after a few minutes, but thanks to @sramji and @landlessness for finishing out the webinar for the video (and slides below) after the outage.

“RESTful API Design: Second Edition”  Webinar - Video & slides »

Here are the slides and video for last week's RESTful API Design webinar, thanks again to everyone for joining.

Check out some additional tips and advice for designing Pragmatic RESTful APIs on the API Best Practices blog.

We'd love more thoughts or questions - there is a thread on the api-craft forum.  

Video and Slides - “Developer segmentation for your API”  strategy webinar »

Thanks to all that attended last week's API strategy webinar "Developer Segmentation for your API" on developer community and market size. (And thanks to our speakers @sramji  and @landlessness).

Here are the video and slides (and as always, you are free to use under Creative Commons).

“Your API is not a website!” - webinar video and slides »

Thanks to those that joined us for last week's API how to webinar presentation "Your API is not a website".   (and thanks to our speakers @gbrail and @brianpagano)

Video and slides are below!

Video and Slides - “Boss, we need an API!”  strategy webinar »

Thanks to all that attended last week's API strategy webinar "Boss, we need an API". (And thanks to our speakers @sramji, @brianpagano, and @landlessness).

Here are the video and slides (and as always, you are free to use under Creative Commons).

Join us this Thursday for our next API webinar "Your API is not a website!" by @gbrail - you can sign up here!

Q&A for OAuth and API Best Practices Webinar »

Thanks to all that attended last week's webinar:  OAuth: The Big Picture (slides and video here).

There were great questions  - here are thoughts on those we didn't have time to discuss.

Q: Would you recommend only using oauth for passwords and usernames?  What about more confidential items like card numbers? (John G)

 I'm not sure I completely understand - but are you asking - if a user can authenticate to OAuth using a credit card number rather than a username/password?

That's theoretically possible but I'm not sure it's a good idea. Also, keep in mind that most credit-card authorization systems use a unique ID to map your transaction to an actual credit card, and for PCI compliance the actual number itself is stored in a PCI-compliant card system. In other words,  I'm not sure that OAuth would be solving a new problem here.

Q: Can you talk about the practices around validity periods of tokens, given that their decoupled from password validity? (Eve Maler)

 Sure. First, why do OAuth tokens need to be refreshed at all?

For one, when an OAuth 1.0a or 2.0 "mac" signature is used without the benefit of SSL, it could theoretically be cracked given enough time and computing resources. However when SSL is in use, you can't do this by just sniffing the network, although if you can intercept a request some other way then you could theoretically do this. So, one reason to refresh the token is so that it can't be cracked.

Another reason is just because as users pass their computers around, phones, etc, it's possible that they won't realize that they contain OAuth tokens. This is a much more subtle and undefined reason than the first.

Some applications give out tokens that never expire, which leads to the theoretical "cracking" example if you are not using SSL. On the other hand, I've seen applications with tokens that expire in 15 minutes, which is not very user-friendly. I don't have a specific recommendation right now and I'm not sure if I have seen another as well.

I actually think that this is a good area for some new research if there's someone out there looking for a project -- I don't think that we've quantified this well.

Q: If the user is entering the user/pass on the browser, even though it may be a trusted website URL, it is still vulnerable for some client to sniff the credentials as it is on the machine itself!! (Kaushik)

 Sure -- nothing on a computer can be completely trusted, and the person operating the machinery can be trusted least of all!

What OAuth does for a web app, is keep the passwords from the server that you are using and prevents your password from being spread around the Internet from server to server. Given the number of security breaches in which servers are compromised and user accounts exposed,  this fixes a big problem.

What OAuth does for a mobile app is keep the password from the application that you are running. I think you can trust the browser embedded in your OS more than you can trust the application built by a developer that you don't know, but I know that others here disagree. (And yes, I realize that an app can put up a fake browser screen. I wonder if such an app can get through the Apple App Store? Does anyone have knowledge about how real a threat this is?)

Q: What options does Apigee support for server-to-server API calls where we want to verify the caller is a valid caller?  i.e. request signature? (Mark Visosky)

 We can support two-way SSL, WS-Security with UserNameToken profile or X.509 profile, SAML, XML encryption / digital signatures, and of course HTTP basic authentication.

Q: if i change my password on twitter, then try to use a previously working app, it makes me reauth (Daniel)

 I didn't know that about Twitter and should have tried before the call.

Q: Thanks for the webinar, you've clearly thought a lot about authentication and security issues.  However, I cannot grant you the point that opening up a web browser where you enter your password to the service provider keeps the user's password secure.  A malicious desktop or mobile application will be able to trick the user into divulging their password by spoofing the oAuth page in some way. oAuth sign in page, I mean (Kevin)

Thanks for the questions. There are certainly other ways to trick a user into divulging their password even beyond what you suggest... That doesn't mean that we have yet abandoned passwords completely.

However, an API provider that DOES want to abandon passwords and replace them with some sort of multi-factor authentication, VPN, SAML, hardware dongle, whatever, can do that by replacing the authentication screen in OAuth with one that requires whatever that API provider wants WITHOUT requiring any change at all on the client. This is a lot harder to do once there are clients out there that have hard-coded username/password authentication.

Q: if it again asks for reauth then does that mean it is using the changed password somehow..? (Kaushik)

An API has the option of revoking the OAuth tokens at any time, and some may choose to revoke them whenever the password is changed. However, OAuth doesn't require or specify that.

Q: Isn't the full OAuth dance only necessary if a user needs to authorize another application to perform actions on their behalf?  i.e. giving authorization to bit.ly to submit tweets through my twitter account.  What about API's where we just want to validate callers are who they say they are but no end-user is involved. (Mark V)

 For server-to-server communications, two-way SSL, or "regular" SSL with HTTP Basic and a long, random password are fine ways to solve this IMHO.

For applications that need to authenticate themselves as "the app" rather than as a particular user,  you can assign each app a unique and random "application key" and include that in each request. Use SSL as well if keeping the app key a secret is important to your business.

Q: Do services need to store/control which third-parties can retrieve your OAuth credentials? Or is it generally the rule that if you expose OAuth, any app can use it? (Kenneth)

 In order to build an application that uses an API via OAuth, the application needs a set of application credentials -- that's the case for OAuth 1.0 and 2.0.

Q: i want to write an OAuth2 *provider* - what libraries are available to me? (Kevin H)

There is a long list of open-source projects at oauth.net under "Code." It's not something that can usually be just "plugged in" to a server, however, because it depends on how you want to authenticate users, where you want to store credentials, etc. At this point in time I should mention that an API gateway product such as Apigee Enterprise is one great way to get it done quickly.

Q: If oAuth requires SSL in 2.0, the request signing step becomes useless, no? (Kevin W)

When OAuth 2.0 is used with a "bearer token," then there is no secret and no request signing -- you use SSL instead.  When OAuth 2.0 is used with a "Mac token" then it is just like 1.0a.

Q: Are the specs for SSL ,SAML assertion available to be used or implemented for my server..? (Kaushik R)

Absolutely. Check ietf.orf and search for "OAuth." There are active groups working on all these specs.

Q: If you're requiring SSL, why not just trade un/pw for a token set and be done with it?  This assumes that the oAuth sign in page is security theater, which I maintain that it is. (Kevin)

@Eve but you can use any RSA spec, as long as the client and server know what to do. (Dan)

un/pw/api key or whatever? (Kevin)

Even the father of OAuth, Eran Hammer-Lahav, says using SSL as a means of authentication is broken (ie, OAuth 2.0 is broken) - (Dan)

 Yes, he is wary of SSL.  That's why he personally ensured that OAuth 2.0 also includes the "mac token" option, which is a way to use OAuth 2.0 with a signature and without SSL, just like 1.0a. This particular spec is newer and changing more quickly but it'll be an important option soon. Given the amount of work he is doing on the spec I don't think he thinks it's broken.

Q: How complex it is to implement OAuth in our own servers..? (Kaushik)

 The hard part is integrating the OAuth flow with your existing authentication mechanisms, so that the browser is redirected and all that. There is also a bunch of work involved in implementing the various authentication flows, and there are quite a few of them. I think there are much more complex things to implement but OAuth does have its challenges.

Q: Where is the OAuth token stored? is it Server side in your example Twitter, or client side BIT.LY or BOTH? I think you mentioned in case of mobile apps it is stored on mobile. (Arpit)

 It depends who is accessing the API on your behalf. The bit.ly web site, for instance,  must store them on the server since it's a web site. The Twitter mobile apps, however,  store it on the mobile device itself.

Q: So are they saying that banks shouldn't use OAuth for banking transactions? (Kenneth K)

 If a bank has a fiduciary responsibility, for example, to sign every transaction with an RSA key that is stored on a hardware key store and managed by a PKI with tight policies and procedures around key distribution, then OAuth isn't going to be used in such an environment any more than plain old username / password combinations. That's the case for financial applications that deal with individual transactions worth millions or billions of dollars.

Seeing that many of us bank on our mobile phones or web browsers using just a username and password for authentication, I think that OAuth is just fine for a wide variety of other financial apps.

Q: The oAuth login screen is security theater - I can spoof it or otherwise trick the user if I am a malicious mobile or desktop app developer.  If you can't force me (the third party app developer) to NOT store the un/pw, why make me goof around with an embedded browser page in my desktop/mobile app?  Thoughts? (Kevin)

 I think I tried to answer this elsewhere, but in general if you really want to do this then OAuth 2.0 actually includes an authentication flow that lets you get a token by simply sending the username / password to the server.

Q: oAuth gives a false sense that your transactions is secure, but the spec really does not mandate any message level security?? (Praveen)

 Well the spec strongly recommends it but the spec can't force it -- it is up to each individual API to require message-level security in the right places.

Q: Advanced talk should have a topic on usage of the "SCOPE" parameter (Vladimir)

I think that the whole "scope" thing would be an interesting seminar,  yes. Let's consider it,  but we'll need a lot of good examples!

Thanks again to everyone and hope to see you on our next webinar:   "Boss, we need an API!"

Video and Slides - OAuth: The Big Picture »

If you weren't able to attend last week's API Best Practices Webinar #8 "OAuth for Your API: The Big Picture," or if you just want to review, here are the slides and video! 

OAuth is taking off as a standard way for apps and websites to handle authentication. But OAuth is a fast-moving spec that can be hard to pin down. In this webinar, our CTO Greg Brail and Sr. Architect Brian Pagano give the "big picture straight talk" on the business and operational benefits of OAuth, different OAuth flavors and which one you should choose. 

Questions we address: 

• What is OAuth (in plain English) and when should you use it for your API? 
• The Pros and Cons of different OAuth flavors (1.0a, 2.0, two-legged, three-legged) 
• "Big Picture" OAuth considerations, best practices, and decisions to make 

Video and Slides: Developers Hate Marketing! Launching Your API and Attracting Developers »

Thanks to all that attended last week's API Best Practices Webinar #7 "Developers Hate Marketing! Launching Your API and Attracting Developers." Here are the slides and video! 

In this webinar we share our experience, best practices and toolkit for API and platform adoption. We cover creating a beautiful developer experience, audience segmentation, offline and online community, the top 10 things you need to launch your API and more.

Join us next week for the next webinar, OAuth for Your API: The Big Picture with our CTO Gregory Brail and Senior Architect Brian Pagano. We'll discuss business and operational benefits, the different versions of the spec, and answer your questions.  

Developers Hate Marketing from Apigee on Vimeo.

Video and Slides: Your API Sucks!  Why Developers Hang Up and How to Avoid That »

Thanks to all that attended last week's API Best Practices Webinar #6 "Your API Sucks!: Why Developers Hang Up and How to Avoid That" (and thanks to our presenters @earth2marsh and @landlessness).

We apologize for the audio problems during the actual webinar - but Henry - our amazing filmaker - did a great job of cleaning it all up for the video below. 

Need to transact credit card information with your API?  Then check out our next API webinar, "Does your API to be PCI Compliant" with @brianpagano, our Sr. Architect, and @scottmetzger, our VP of engineering,  is July 14th at 11am PST (sign up here!)

(for our entire video series, check out the rest of our API best practices webinars)

Video and Slides: Is your API naked?  API Platform and Ops Considerations »

Thanks to all that attended last week's API Best Practices Webinar #5 "Is your API Naked? API Platform and Operations Considerations" (and thanks to our presenters @gbrail and @landlessness). Video and slides are below.

Our next API webinar, "Your API Sucks!  Why developers hang up and how to stop that" with @landlessness and @earth2marsh, is June 14th at 11am PST (sign up here!)

(And you can see all our API best practices webinars to date here)

Video and Slides: API Metrics - What to Measure »

Thanks to all that attended last week's API Best Practices Webinar #4, API Metrics - What to Measure (and thanks to our presenters @brianpagano and @landlessness). Video and slides are below.

Our next API webinar, "Is your API Naked? API Technology and Ops Considerations" with @landlessness and @gbrail, is June 14th at 11am PST (sign up here!)

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.

Video: RESTful API Design (Pragmatic, not Dogmatic) »

Recently Brian Mulloy (@landlessness) and Marsh Gardiner (@earth2marsh) hosted a webinar on API design and Pragmatic REST. The video of the recording and the slides are below.

Our next API webinar - 10 Patterns in Successful API Programs - is this Thursday, May 19th at 11am PST, with Brian and Greg Brail @gbrail. Interested in the topic? Then you should sign up now!

RESTful API Design:  Webinar slides and recording »

Thanks to everyone that attended yesterday's RESTful API Design Webinar (and thanks to our presenters @earth2marsh and @landlessness).

The slides are below and here is the full recorded webinar.   (We'll also post a video next week.)

Our next API webinar is "10 Patterns in Successful API Programs" with @landlessness and @gbrail, May 19th at 11am PST (sign up here!) 

Mapping out your API Strategy: Webinar slides and recording »

Thanks to everyone that attended yesterday's API Strategy Workshop Webinar (and thanks to our presenters @sramji and @landlessness)

The slides are below and here is the full recorded webinar. 

Join our next API webinar, "Pragmatic REST:API Design Fu", May 5th at 11am PST.  You can sign up here. 

Free Webinar: Mapping Out Your API Strategy »

Ever need to explain why APIs are so powerful to someone at your company?  Need an easier way to think about the different API strategy options?

Join us for a Webinar - “Mapping Out Your API Strategy” - this Wednesday, April 20 at 11 am PST / 2 pm EST.

It's free (of course) and you can sign up at this registration page.

Brian Mulloy and Sam Ramji will talk about the API market, and propose some ways of thinking (and cool frameworks) for how you can think about API strategy vs. your objectives.