Evolving the Typical Online Catalog

Until recently, Wine.com was just a basic wine catalog. It was well designed and easy to navigate, but it was definitely a web 1.0 kind of site. As the winds of the new web started to blow, the company realized that it needed to stay on top of the wave. With competitors like Corkd, Snooth and the wildly entertaining WineLibrary.tv innovating in the wine space, the Wine.com team knew that they would have to compete for wine lover's attention and dollars.

As it turns out, the wine insdustry is highly regulated, and users may not be able purchase a particular vintage depending on where they live. Wine.com's catalog maps the vast number of wineries to geographies and ensures that the law is followed. When the company looked to leverage their assets against the competition, they realized that exposing the catalog by state to users, partners and third-party developers can help drive more traffic to the site.

Wine.com's RSS API

Not only did Wine.com open up its catalog, the company did it with elegance worthy of modern APIs like del.icio.us and Flickr. The API is implemented via RSS, where each query returns a feed. Here's a sample query (this is not exact query, it's just meant to just give you the feel for the API):

http://www.wine.com/v6/rss/rss.aspx?Ntt=+Kendall%2DJackson&State=CA

When you view the results in the browser you get this:

So to the end user the results look like a regular RSS feed. This means that the user can add the feed to his or her favorite reader and get updates when the new Kendal Jackson wine comes out in California. But if you look inside the source code of the feed, you will find that each item is augmented with complete metadata about each wine.

The included metadata contains a description of the wine, price, winery, year as well as tags done as categories. Note that it would probably be better to use a custom tag instead of overloading the meaning of the category tag. For example, <year> would be better than having year listed as a category. Nevertheless, this feed is essentially equivalent to a results of a query against the Wine.com catalog. Each item represents the matching wine and contains all of the attributes of this wine.

The interface is stateless or REST, since the entire resulting feed is returned at once. There is flexibility in the query, since the query text can be any attribute of the wine, such as name, winery or grape. That means that the query is performed against the entire catalog and is based on text matching. This makes it really easy for the end users, but may present scalability challenges for larger databases. Putting it all together, we get this diagram:

When an RSS API Makes Sense

What Wine.com has done is simple and powerful. They leveraged existing technology -- RSS -- to deliver value to both end users and developers. The reason this strategy worked for the wine retailer is because they needed to provide a read-only interface to their catalog. Essentially, all the interface does is expose a way to search Wine.com's database. Because this is the only requirement and there is no need to expose a way to manipulate the catalog by adding or updating information, the RSS API works great.

The only downside of using RSS is that all results must be returned at once. If the query is broad, for example, get me all merlot wines, returning all results is too expensive. In the case of Wine.com, the solution is to just return the most recent wines that match the results. A more generic approach found in relational databases and in services like Amazon S3 is to page through the results using a result set iterator.

It is clear that the RSS API approach would work for any catalog. It would not work for del.icio.us or Flickr because these services offer a way to modify the information, not just query it. But coming back to the concept of the Web as a database, if every retailer would offer this kind of RSS API, the web would be much more semantic, interconnected and query-friendly.

Conclusion

What Wine.com has done is both simple and interesting and it certainly deserves consideration. One might argue that there is nothing special about augmenting RSS with metadata, but there is nothing special about any format. What is special is leveraging existing technologies and making things compatible and interoperable.

The fact that RSS feed can channel metadata can lead to a lot of interesting applications including, for example, richer widgets. We hope that these early iterations of web services and APIs will give rise to a new, more connected and richer web where web sites are also web services.