This past Saturday we collaborated with Heroku and Twilio to put on Social App Workshop, an all-day hacker event in San Francisco focusing on people building applications with the Facebook and Twitter APIs. Over 130 developers gathered early in the morning to hack, learn and collaborate. 

We heard some cool presentations and Twitter launched their bridge code for the @Anywhere service! Documentation is coming soon but you can check out some of it here. The Twitter team had been up working on it until 1:00 am the night before! 

Here's some top trends from the event: 

1. Simplicity is everything

Presentations by Oren Teich of Heroku on cloud services and hacker advocate Abraham Williams on minimalism in feature design shared a common theme: simplicity is key - both for applications and the infrastructure, tools and languages that are used to build them. With the immediacy of social tech, increasing mobility, and intense app competition, fast and easy is the new imperative. 

"Make it as easy to use as possible. Then make it easier." - Oren Teich

"Users are lazy…. Make your web app like AAA - only there when you need it" - Abraham Williams 

2. Innovate Faster

A big buzz topic during afternoon coding was the need for speed- and languages, cloud services and developer tools that let people build and deploy applications quick. As presentations on the Twitter API by Matt Harris and the Facebook API by Matt Kelly showed, simple, logical APIs with easy-to-understand structures are a critical element for fast innovation. API providers who align with developers' mission to build-and-deploy in lightspeed are more likely to succeed.  

3.  The Mashup New School 

The concept of "mashups" that combine services and APIs from multiple sources has been around for awhile- but the new school of mashups is all about taking different capabilities from across industries and putting them together to create entirely new functionalities. Take Twilio- which provides an open API for building voice and SMS applications and can bring the world of telephony into your apps. We're seeing more and more industries- health care, 3D, semantic analysis- innovating with APIs and making a whole new school of mashups possible. 

4. Ruby is HOT

Social app developers love Ruby! Tons of attendees were either Ruby experts or trying to learn- there was even a "Ruby N00bs" informal group that got together in the afternoon to collaborate on getting up and running. Developers like Ruby because it lets them build fast- especially when combined with cloud platforms like Heroku. 

Thanks to everyone who participated! You can see more pictures on Flickr and we hope to see you at an event soon. In the Bay area and have ideas on developer events? Shoot us an @ sign on Twitter. 

The top news from the API geek-sphere this week. Enjoy!

Skype released its SkypeKit SDK for Windows and Mac, giving developers access to Skype APIs and some really cool functionality- like embedding chat, voice calling and video into their apps. SkypeKit was originally released for Linux and we're glad to see more developers will now be able to share in the fun!

Evernote - the popular service to store, organize and access information across, well... your life - released the Evernote Trunk- a place that highlights cool apps and services built using the Evernote API. We love this idea- great best practice for API providers!

Apple has reportedly acquired Poly9, a mapping API provider that has built APIs for companies like Microsoft and Yahoo. Interesting news- the geolocation revolution has been largely driven by APIs and we're interested to see what Apple does with Poly9 now.

New APIs and Opportunities

• The Health 2.0 Developer Challenge, an initiative supported by the US Department of Health and Human Services, announced a developer competition for apps built off Practice Fusion's new open API for real-time health data between patients and providers. APIs for healthcare are a big space to watch. 
• Microsoft released its developer tools beta for the Windows Phone 7 and announced that the API available with it is in near-final form for the official launch.
• Sekai Camera, an augmented reality app by Tonchidot, has added an API that makes it possible to deliver content within the application. Augmented reality is the new hotness- go Sekai Camera!

If we missed something great, hit us up on Twitter!

In our daily talks with customers about their APIs, OAuth has become a major consideration. It's quickly replacing the various proprietary "authentication token" schemes used by early APIs (such as the Amazon Web Services APIs) with a flexible standard; and it solves for new use cases emerging from mashups and Web 2.0. Still, there is a lot of confusion about OAuth out there.

Based on the current state of the technology, we know that there are different API use cases. Depending on your security needs, sometimes OAuth is the only security technology an API can realistically support. In others cases, it may be overkill, or something to add alongside another scheme.

OAuth Overkill?        

OAuth is overkill for an API that doesn't require strong authentication. Many "catalog" and "search" APIs that access public data fall into this category. The goal of an API like this is to gain adoption. There's no reason for such an API to require individual users to authenticate to retrieve information from a product catalog, or search public data. (Unless, of course, your API's business model revolves around data that is so valuable that you can get away with charging for every data access. In today's world, that's not common.) A simple API key, however, is a great idea for these kinds of APIs, integrated into your API analytics so you and your developers can see what's going on.

The Case for OAuth

OAuth is the only realistic choice for a web application that itself uses another web application's API on behalf of the user. For instance, consider a web application that integrates with Twitter. (Perhaps it's a geolocation app like Foursquare that offers the ability to tweet where you are and what you're doing.) Today, it is unacceptable for such a web application to store its users' Twitter passwords. OAuth was designed precisely for this use case -- it gives the web app a secure way to get an access token for Twitter, which the user can revoke at any time, without ever revealing that Twitter password to the web app.

Basic Auth- Still Important

In most cases OAuth should be one of two or three security choices for most APIs. Again, consider Twitter. It makes perfect sense for OAuth to be used by other web apps as a way to access Twitter. But Twitter has long supported "Basic" HTTP authentication as well, using a username and a password. While this is bad news for a web application client, for a mobile or a desktop client that is used by an individual user, it's just fine as long as the client takes some care with the password.

And importantly, Basic authentication is easy. If your API requires secure authentication, and you want it to be easy to integrate and test, then offering Basic authentication means that the barrier to entry is low.

Now, once the decision to use OAuth has been made, the question is whether to use the current version 1.0a, or the still-under-development OAuth 2.0. We'll talk about that next.