Chapter 12. Making Your Web Site Mashable

Table of Contents

Why Make Your Web Site Mashable?
Using Techniques That Do Not Depend on APIs
Use a Consistent and Rich URL Language
Use W3C Standards to Develop Your Web Site
Pay Attention to Web Accessibility
Consider Allowing Users to Tag Your Content
Make Feeds Available
Make It Easy to Post Your Content to Blogs and Other Web Sites
Encourage the Sharing of Content with Explicit Licenses
Develop Extensive Import and Export Options for User Content
Study How Users Remix Your Content and Make It Easier to Do So
Creating a ­Mashup-­Friendly API
Learn From and Emulate Other APIs
Keep in Mind Your Audiences for the API
Make Your API Easy to Learn
Test the Usability of Your API
Build a Granular, Loosely Coupled Architecture So That Creating an API Serves You As Much As It Does Others
Embrace REST But Also Support SOAP and ­XML-­RPC If You Can
Consider Using the Atom Publishing Protocol As a Specific Instantiation of REST
Encourage the Development of API Kits: Third Party or ­In-­House
Support Extensive Error Reporting in Your APIs
Accept Multiple Formats for Output and Input
Support UI Functionality in the API
Include a Search API for Your Own Site
Version Your API
Foster a Community of Developers
Don’t Try to Be Too Controlling in Your API
Consider Producing a ­Service-­Level Agreement (SLA)
Help API Users Consume Your Resources Wisely
Consider Open Sourcing Your Application
Easy-to-Understand Data Standards
Summary

This chapter is a guide to content producers who want to make their web sites friendly to mashups. That is, this chapter answers the question, how would you as a content producer make your digital content most effectively remixable and mashable to users and developers?

Most of this book is addressed to creators of mashups who are therefore consumers of data and services. Why then should I shift in this chapter to addressing producers of data and services? Well, you have already seen aspects of APIs and web content that make it either easier or harder to remix, and you’ve seen what makes APIs easy and enjoyable to use. Showing content and data producers what would make life easier for consumers of their content provides useful guidance to service providers who might not be fully aware of what it’s like for consumers.

The main audience for the book—as consumers (as opposed to producers) of services—should still find this chapter a helpful distillation of best practices for creating mashups. In some ways, this chapter is a review of Chapters 1–11 and a preview of Chapters 13–19. Chapters 1–11 prepared you for how to create mashups in general. I presented a lot of the technologies and showed how to build a reasonably sophisticated mashup with PHP and JavaScript as well as using mashup tools. Some of the discussion in this chapter will be amplified by ­in-­depth discussions in Chapters 13–19. For example, I’ll refer to topics such as geoRSS, iCalendar, and microformats that I discuss in greater detail in those later chapters. Since I don’t assume that you will have read any of those chapters, I will give you enough context in this chapter to understand the points I’m making.

Specifically, in this chapter, I will outline what content producers can do in two major categories:

Before content producers can decide how to act on any of this advice, they need to consider how remixability fits in with what they’re trying to accomplish. We look at some of these issues first.

[Tip]Tip

 For detailed notes on how to create, run, and maintain an API from the perspective of a seasoned API creator, please consult Chapter 11 of Building Scalable Web Sites (O’Reilly Media, 2006), written by Cal Henderson of Flickr.

Why Make Your Web Site Mashable?

To decide on how remixable you want to make your content, you need to understand what you want to accomplish. There is a wide range of interest with respect to making APIs. Some content producers (such as Amazon, Google, and Yahoo!) set out to develop a platform and therefore invest huge amounts of effort in creating an API. Others are interested in making things convenient for users of their content and create an API if it’s not too difficult. Other content producers want to work actively against any remixing of their content. The course of action you take as a content producer will certainly depend heavily on your level of interest in the mashability of your content to others as well as the resources you have at your disposal to create an API.

Here are some arguments for why you might want to make your content remixable (in other words, why it’s good not only for content users but also for you as a content producer):

  • With a good API, developers and users can extend what you provide. Look at how the vast majority of the API kits for Flickr are developed by third parties rather than Flickr.

  • Third-party developers can develop applications you haven’t even thought of or are too busy to create. (I’d say geotagging is a huge example of this for Flickr—it opened up a whole new vein of activity for Flickr.)

  • APIs appeal to users who are concerned about ­lock-­in and want to use their content in places other than your web site.

  • Many users are starting to expect to have APIs; as a result, having an API is a selling point to prospective users.

  • With an API, you might be able to extend your presence and point others to you (for example, Flickr photos are distributed all over the Web, but they all link back to Flickr). Indeed, Flickr is the platform for photo sharing on the Web. But Flickr’s attribution requirement (in other words, the photos served from Flickr need to link back to Flickr) keeps Flickr from being commoditized as a ­file-­hosting service.

  • If the API is of sufficient economic value to your users, it is possible to charge for using your API.

  • In some cases, you might be able to create something like Amazon.com, which as a platform for ­e-­commerce takes a cut of purchases built on top of its platform.

  • Making your data more open is contributing to the common goals of the entire Web.