One of the biggest time sinks I encountered while hacking the CoffeeScript Tracker 0.0 was errors with response data. The CoffeeScript that hit dedicated APIs for the most part just worked, and the closer the interaction was to pure RESTful http the better. But problems arose when querying rss and atom feeds due to inconsistencies between the formats.
The YQL or Yahoo Query Language was what I attempted to use to provide a standard feed interface. Response formats returned to the callback functions varied at the top with data.response.entries or data.response.results. Then within these json structures the entries and results had keys to describe urls. This lead to a variety of handlers and comparisons like obj.link.href, obj.link[0].href, obj.origLink, etc. The differences arise between atom, rss, version releases, and the particular provider. In theory I could write or find a JavaScript/CoffeeScript Swiss army knife of feed parsing, much like the fine Nokogiri Ruby gem I long took for granted.
It's sad when feeds, the open "lingua franca" of the Internet, are such a mess that hitting unique APIs is both simpler and more reliable. At least with feeds the formats have a slower divergence rate compared to one shot APIs, but middleware is advised when juggling with variations.