Skip navigation

I once had to build a shopping cart framework for a friend’s company in about three days. It was a challenge considering all the complexities involved in pretty much any instance of a shopping cart. Most shopping cart solutions would hardcode predefined rules or configurable options for determining tax, shipping, and promotional discounts. This was kind of ridiculous since those are usually the points where it varies quite a bit from cart to cart. My solution was to provide hooks because I knew these guys were programmers and were smart enough to implement their own callback functions to define whatever rules they wanted. It turned out to be very powerful, one of their favorite features of the framework, and it was trivial to implement.

So how does an architecture like that translate to a hosted e-commerce checkout solution? Obviously, web hooks! Amazon recently figured this out as they just announced a Callback API for their Checkout solution under their Amazon Payments arm. It lets people use their hosted “checkout solution” while letting them customize the rules for calculating taxes, shipping, and promotional discounts in the most powerful way: code.

This is a fairly significant example of web hooks because it breaks away from the notification use-case that people seem to be caught up with. By actually processing the results of a hook callback request, you’re opening up your application logic to the end user. This is user contributed logic, an under appreciated and mostly unrecognized trend for the emerging service platform aspect of the web.

I don’t want to tangent too much into a rant on the web I want (and I think we all want, but don’t realize it). Instead, I’ll summarize some details on this new Amazon announcement of web hooks. The full documentation for which can be downloaded in PDF format.

You define the callback endpoints in a configuration XML document used for setting up Checkout. They use HMAC authentication for hook requests with added timestamp nonsense, very similar to the way they do Amazon Web Services. The payload is somewhat surprisingly not XML, but instead a URL encoded key/value pair format. The strange thing is that they try and do nested data structures this way, which makes me think JSON would be the better choice. And just to confuse you slightly, in the documentation they use XML to describe the data structures they pass to you and expect back, even though XML is not actually involved. Nevertheless, the documentation is quite good.

Anyway, I’m happy to see a use-case emerge in a way that starts to hint at the aspect of this model I’m more interested in: customization via code. Notifications, or “push,” are really just something along the way. Although this is a trivial example, you should be able to start imagining how it could be used to build a plugin architecture for your web app. The ability to allow your users to extend and build new functionality they can share with others does not seem like an empty value proposition!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: