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:
Ways in which they can make their web sites and content mashable without even producing a formal API
Ways in which they can shape their API (features that are friendly to mashups)
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]](../docbook_images/tip.png) | 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.