A friend of a friend told me that “APIs are the biz dev of Web 2.0,” and there’s some real truth to that, especially if you mean open APIs. (An API, or application program-ming interface, is a set of protocols for interacting with an application from without.)

Internal APIs are essential to the development of any true platform, but open APIs unlock the potential of a third-party developer community, taking your project into realms far beyond what you could commission or build yourself.

The Internet has always thrived on openness: the open (and social) process by which its fundamental protocols (such as the TCP/IP stack) were developed (on the basis of “rough consensus and running code”), the open source operating systems and programming languages that have fueled and sustained its growth, the open interlinking of netnews nodes to create the anarchic and resilient Usenet, the open linking customs of the World Wide Web, the open editing norms of successfully wikis.... I could do this all day.

Of course, today everybody pays homage and lip service to the concept of openness. Everyone says they’re open, or trying to be open, or getting more open, but there are many ways to be open and there are many degrees of openness, and frankly, “open” isn’t the ultimate value that inherently trumps all other concerns. As with any software architecture of a user experience design project, there are inevitable trade-offs. Great fortunes have been built on lock-in, by keeping switching costs high, and by not allowing users complete control over their own data.

For the sake of this discussion, let’s look at four clusters of open patterns and principles:

To be clear, we’re not religious about any of this: if a proprietary protocol or technology or model works best for you, then use it in good health and gain whatever benefits you can get, but be aware of what you may be giving up in exchange. Where possible, though, we’ve found that the more you can build your app upon the rock of proven, well-implemented, open standards and technologies, the easier it is to participate fully in the social potential of the Web and the always-on digital environment we now live in.

The Open Stack, the Social Stack

Throughout this book, we’ve lamented the Password Anti-Pattern and the pain of re-friending the same people on multiple networks. Over the last few years, many community-developed protocols have arisen to facilitate interoperability, building upon each other wherever possible. There are several ways to visualize this stack, and it’s still a work in progress (Figure 17-1). But to the extent that you can leverage the solutions that are already out there, you’ll be able to focus on the value you’re trying to add to the ecosystem: the unique killer service your app provides.

Figure 17-1. One articulation of the “open stack” (also known as the “social stack” to distinguish it from the existing open stack that already powers the Internet).

Often the first step in “going open” is to open out to the rest of the Web, to make your content and features available elsewhere. It can be easier to sell the idea of extending the reach of your data than perhaps to permit others to play in your own sandbox. As always, there are trade-offs.

When you enable your content to appear in contexts you don’t control, you lose a little bit of mastery over the presentation of your brand. You’ll have to weigh the pros and cons to determine what to do, but recent history—as in the great success of RSS as a simple syndication format—tells us that limiting your expanse to the servers and hosts and sites you control directly is a risky proposition when the rest of the Web feels more and more like a free-for-all.

Successfully opening out means providing ways for external applications to consume and add value to your data, either public data or data your users have affirmatively authorized for this additional service.

What

Badging out is one of the easiest openness patterns. It involves packaging up information, frequently personalized information, in a portable format that can be copied and pasted into the template of another site so that content from your service can cleanly appear elsewhere on the Web (Figure 17-2).

Figure 17-2. Generating a badge is a simple way to make your content available away from your own site.

Perhaps the canonical example of this pattern’s success is the way YouTube’s simple embedding code enabled it to piggyback on the popularity of MySpace as members of the latter site shared videos with one another (having found it much easier to embed YouTube videos than those from any other service). MySpace briefly considered banning YouTube embeds from its service, but by then it was too late.

Also known as “(External) Module,” “Badges,” “Badging Out,” “Embed Codes,” “Codes,” and “Widgets.”

Use when

Use this pattern when the user wants a way of taking his content from your social site and sharing it elsewhere.

How

Why

Giving your users a simple snippet of code for embedding in another site is one of the easiest ways to facilitate organic awareness of your site. Any user who creates a badge and embeds it on her blog or Facebook page is in effect advertising your site for you. Users provide an invitation for their visitors to explore the data or content being shared from your site by clicking through the badge and visiting.

Related patterns

Embedding in Embedding

What

Microformats and other established semantic markup and data-structure formats enable third-party developers to write applications that consume and manipulate the data you’re generating (Figure 17-3).

Figure 17-3. By the simple virtue of marking up your presented data with microformats, you can enable machine reading and semantic interpretation of that data by third-party developers.

Use when

Use when designing templates and parsers for your data feeds, streams, sources, and pages.

How

Why

Third-party developers will improvise unreliable screen-scraping routines in order to consume, structure, mash up, and distribute your content if it is displayed in public dressed in semantically meaningless markup.

Related patterns

Authorize in Authorize

Incoming interoperability is the mirror image of outgoing. It involves the ways in which you support bringing in and building on data generated externally to your system and either found in public or authorized by your own users.

Just as providing badges enables site users to export content from your site and have it appear elsewhere on the Web, openness is a two-way street, so you can strengthen the appeal of your own environment if you enable your users to import their own data from elsewhere on the Web into your site (see Figure 17-4).

Figure 17-4. An application on Facebook enables status updates from Twitter to be imported systematically, consumed, turned into Facebook status updates (with some rules and exceptions), and displayed on Facebook, giving Facebook users the benefit (or annoyance) of additional information that would otherwise not flow to them.

Also known as “Consume Feeds.”

What

Much as we may dream of building one site to rule them all, it’s much more likely that our site participants will continue to live at least part of their lives elsewhere, creating content and forming relationships outside of our site.

Use when

Use this pattern when designing the formats and structures of your social objects. Allow the flexibility of open content and data modules to enhance the overall user experience. Allowing offsite content to intermix (even if only with side-by-side widgets) lets your users truly make the experience their own.

How

Why

Instead of trying to fight or ignore the sad fact that our users have lives outside of our site, we can instead invite them to aggregate their content inside of our site by providing easy ways for them to import content generated elsewhere.

What

Making your own content and services available “off network” is beneficial, but it’s only half the story. Without opening your own environment to third-party modules, you deny your users opportunities for experiences that can be improved by greater inventiveness and competition (Figure 17-5).

Figure 17-5. Hosting a module from an external site on yours can feel risky. It’s the reverse of the badging out role, but the experience for the user is the same.

Use when

Use this pattern when your core services are strong and healthy, you’ve given outside developers the ability to build on and enhance all of your incoming and outgoing hooks, and you feel confident enough to permit external developers to create services mixing your sources with others that are hosted on your own site.

How

Another site creates a module/app that includes access rights to data.

The module is uploaded to your site, scanned for safety, and stored for later use.

As you can see, opening out and opening in involve much of the same thinking, but from the opposite side of the table. To fully embrace the “flow” of the Web (and perhaps avoid being routed around), explore the possibility of being open in and open out.

Be the Glue

Don’t try to own everything. Create more value than you capture. Don’t build an application when a feature will do. (See Figure 17-6.)

Figure 17-6. Fireball, a prototype that mashed up Twitter for its social graph, Upcoming for its calendar of Web 2.0 Expo events, and Fire Eagle for its location-awareness.

What

You have a suite of interesting solutions and a collection of data. You recognize that others can create new and unforeseen solutions with the data if it is exposed through an API (Figure 17-7).

Figure 17-7. Exposing your APIs to outside developers is a fundamental form of openness that can enable your social service to operate as part of a larger ecosystem, rather than as a backwater unto itself.

Also known as “Data Sharing.”

Use when

Use this pattern when developing your site’s architecture, when conceptualizing the ecosystem your service will live in, and when deciding which APIs or which aspects of your existing APIs to expose to the public.

How

Wherever possible, expose APIs that enable outside developers to extend the value of your core service.

Each case will have its own issues of data security, privacy, what gets shared, authentication, authorization, and so on. Terms of Service provide a legal framework for safe data sharing practices, but a rule-based permission system must be in place to enforce rules mechanically.

Some services must be opened on a read-only basis. This may frustrate your third-party developers, but if it can be justified as better than no access at all to data and connection information, then it may still be worth offering.

Why

What’s good for the goose is good for the gander. If your site can be enriched by the import of data from outside sources, your data can also provide value to your users when you allow them to take it into their environments and experience it in convenient contexts.

As seen on

Facebook API (http://maps.google.com/help/maps/getmaps/advanced.html)

Flickr APIs (http://www.flickr.com/services/api/ and http://code.flickr.com/)

Google Maps APIs (http://apiwiki.twitter.com/)

Twitter API (http://wiki.developers.facebook.com/index.php/API)

Yahoo! APIs (http://developer.yahoo.com/everything.html)

What

Many opportunities for social design experimentation online involve adding incremental new features to existing services, but the effort involved in duplicating those services just to add one more feature is prohibitive or wasteful. (See Figure 17-8.)

Figure 17-8. A trusted middleman can broker data exchanges and profit by understanding the flow of information and social gestures that pass through the utility.

Also known as “Middleman, “Middleware,” and “Utility.”

Use when

Use this pattern when you are designing a system that can enhance existing social behaviors but you don’t see the value in trying to launch your own ecosystem just to support your idea, because it’s more of a feature than a complete application.

How

Build an open, interoperable service with clear opportunities for data input and retrieval, clear privacy and security rules and permission structures, and adequate documentation. Then, support the developer community as if it is your primary customer (because it is).

Why

If you want to be seen as a utility (as Facebook describes itself), then you cannot be perceived as self-dealing. Bakers put that 13th cookie in the bag to prove to you that they don’t have their thumb on the scale.

How to Build the Open Mesh (presentation),

http://www.slideshare.net/marccanter/how-to-build-the-open-mesh-09-1427980 How to Build the Open Mesh (unbook wiki), http://buildtheopenmesh.com/ Joseph Smarr at Web 2.0 on the New “Open Stack,”

http://therealmccrea.com/2008/09/19/joseph-smarr-at-web-20-on-the-new-open-stack/ Microformats.org, http://microformats.org OpenSocial, http://code.google.com/apis/opensocial/ The Open Stack: An Introduction (YDN blog),

http://developer.yahoo.net/blog/archives/2008/12/the_open_stack.html The Open Web Foundation, http://openwebfoundation.org/