Tyler Hunt

As I’ve been developing my Amazon FPS API, I’ve had to make some decisions along the way about how the code should be structured. Right now I’m taking the approach of a central API class that has a method for each action provided by the service. Each action, then, has its own request object, which is used to pass parameters into the API call, and its own response object, which is used to pass back the XML response from Amazon as a Ruby object. This approach sometimes seems more akin to a Java API than a Ruby API, so I’m planning to spend some time down the road figuring out a more Ruby-esque means of interacting with the API.

I’ve also been unsure along the way of whether it really makes sense to use such a heavyweight API. I suppose one alternative would be to make use of some magic to simply generate the request from a hash passed to the API. This seems kludgey to me, and having worked with some APIs in the past that operated this way, I feel that the extra effort to duplicate much of the REST service as Ruby code make a lot of sense. One of my biggest gripes with these sorts of APIs is the usage of action and parameter names from the service directly, as they often don’t follow the typical Ruby naming conventions. This alone is enough to warrant a heavier API for me.

Timely enough, Chad Fowler posted an entry on his blog yesterday about “Writing APIs to Wrap APIs.” His philosophy on the matter seems to mirror mine in a lot of ways, and his point about a wrapper API being less brittle especially resounded with me. It’s always nice to receive validation on your efforts, and even more so when it comes from someone you respect.

That being said, progress has slowed a bit as I’ve been taking some time to extract out some of the layers of the API into a library of their own. Ultimately, this will provide anyone writing a REST consumer API with a simple base from which to start, including the logic to handle the HTTP requests, build URLs with query parameters, and parse XML responses. I’m hoping to have enough of this wrapped up in time for BarCampOrlando to be able to give a short presentation on it.