Saturday, December 31, 2011

First impressions of the Zappos API

I thought of an idea for a web application when I was browsing the Zappos store recently, and was pleased to find out that external developers have access to a tremendous amount of information via the Zappos API.  I decided to jump right in and explore what it has to offer.

Signup was easy and the license agreement didn't contain anything I found terribly upsetting.  After signing up I created an API key.  I had a small issue generating a key initially, but Will Young of the API team at Zappos solved my problem literally five minutes after I sent an email requesting help.

I followed some of the examples in the documentation and had no problems as I poked around the API.  Reading unformatted JSON string responses got old pretty quickly so I installed the JSON formatter extension for Chrome and that made running ad hoc requests in the browser more pleasant.  After perusing the documentation and executing several exploratory requests I was sure that I had access to enough information to build my application, so I got to work on it right away.

My application is only interested in Zappos' shoe inventory.  Since Zappos sells a wide variety of products in addition to shoes, most of my searches have to use filters to narrow the scope appropriately.  It took some trial and error with the Search API before I fully understood "facets" and how they are used to describe products, but with that understanding I am now making a lot of headway.  Of the available APIs that I've used in my application so far, the Search one is by far the most powerful (and complex).  I use it to retrieve the distinct shoe sizes, shoe sub categories, and colors.  For these kinds of requests I exclude product results.  Once the user selects among those facets I then retrieve matching product results.

At first I considered writing my entire application without any server-side scripting, using JSONP to overcome the Same Origin Policy, but I eventually decided to route all my AJAX requests through a server-side script in order to keep my API key private and also to have more control over the requests.  During development I am finding the 2500 daily request limit more than sufficient, but when I make the application public I will need to implement a caching strategy in the server-side layer in order to keep the number of requests as low as possible.

On the server-side I use PHP/cURL to perform HTTP requests to the Zappos API.  I wrote a couple wrapper classes around requests to their Product and Search APIs in order to make URL/parameter generation easier.  Most of my application code will sit on the front-end as JavaScript/HTML/CSS, but I decided to write separate actions inside my server-side controller to field each request type.  This way I can hide some of the complexities (particularly of the Search API) from my JavaScript.  Eventually I think I would like to build some of this abstraction into a separate JavaScript library, but for the time being I'm keeping it in PHP so that I can reuse it if I need to execute non-XHR requests.  This is starting to sound like another perfect use case for Node.js...

I am happily using Backbone.js to organize my JavaScript on the front-end.  With it I have been able to rapidly assemble a functioning interface and try out my initial application design using real Zappos data sooner than I expected.  That has been quite helpful, and pushed me to refine several features and design elements that didn't mesh with the data as well as I originally imagined.  For example, some features of my application work perfectly under the assumption that there are always several matching products for each request the user performs.  As I tested various filter combinations I realized that it's easy to limit yourself to only one or two products in the less populated categories.

As I delve further into the APIs I realize that Zappos stores a lot more information about each of their products than I anticipated.  At the outset I thought it would be trivial to retrieve all the different categories of shoes.  But if you take a close look at their store you'll notice that there are many other ways to group shoes -- by brand, occasion, theme, materials, etc.  While it can be a little overwhelming, the availability of all this normalized information about the products opens up a lot of possibilities.

No comments:

Post a Comment