Piping your API not considered harmful
My buddy Mathieu wanted to display his Praized user’s “recent votes” on his personal website (kindo.net) so he asked me “Is there a place that I can grab an RSS feed of my user’s votes on Praized?”
Mathieu uses magpie to grab RSS feeds from round and about and renders them in his pages (preferably in French).
Unfortunately, we do not provide such feeds on Praized as of yet, but that shouldn’t stop you from reading the rest of this article to figure out how we solved this little issue using the wonderful magical mashup tool that is Yahoo Pipes!
It’s a good idea before moving along through this project to familiarize yourself a bit with the Pipes interface if you haven’t. You should also read up on the Yahoo Pipes module documentation and try out a few tutorials, play with it!
The most precious bits of advice I can offer to help you on your Pipes exploration would be save often and turn off firebug. The Pipes interface gobbles up a lot of juice and is a bit glitchy at times, but don’t let that stop you… it’s worth it!
I’ll start off by dumping a heaping portion of pretty much self-explanatory text and imagery, and then proceed to a little more detailed explanation of the tricky bits. Of course, you can follow along by cloning our pipe.
User Inputs::The Private Text Input Module ( documentation)

The Private Input Modules
Here is where the fun begins. You’re going to need user inputs, and you’re going to need default values. In some cases, you might want to use some secret api keys or protect your confidentiality, that is what the “private” checkbox is for. The API key you see is a public key we use for demos, it connects on the behalf of the praized.com community and you can use it to try out stuff, but if you clone our pipe… you’ll notice that the ones who are marked as “private” in the screenshot above will appear empty in your cloned pipe. So basically, these are fancy html input fields with a label and a default value. Let’s move on…
URL::Url Builder Module ( documentation)

Building The API call...
The URL builder module allows us to build our API call. It’s pretty obvious once you see it pre-filled.
Sources::Fetch Data Module ( documentation)
You’ll notice in the previous screenshot, there was the “Fetch Data” module. This module basically uses the URL that was output by the URL builder module and does an HTTP GET request expecting some sort of xml collection. Now this is where it gets a bit abstract…
Operators::Sub-element module (documentation)
The sub element module was used to pick out the proper collection of items to parse through on out the rest of the pruning…
Operators::Regex module ( documentation)

The Regex Module saves teh day!
Ahhh pruning shears! This is the swiss army knife of strings. A lot of people use this in their pipes i’ve noticed and have very creative uses for it. Anyways, the Praized API outputs a XML node called “rating” which outputs either “pos” for a positive vote or “neg” for a negative vote. Yahoo Pipes interprets collections as “items” and the single “item” otherwise with properties using the dot notation. The screenshot above is in french but I think you’ll get the gist of it, let’s break it down a bit:
- look for the the property “rating” in every “item” and if it matches “pos” replace it with “positive”
- look for the the property “rating” in every “item” and if it matches “neg” replace it with “negative”
Next, we loop!
Operators::Loop Module ( documentation)
As you’ll see bellow, the Loop Module is simply a wrapper that allows you to do various operations to each item in a collection, in this case we use them to rewrite some of the api output into something more RSS-like.
String::String Builder module ( documentation)

Building our title
So the goal here was simple. The String builder allows us to concatenate any junk we type in with our item’s properties and build it into some other string. In this case — above — we build the title with a mix and match of quotes and spaces and item properties as below we do for the description.

building our description
Date::Date builder module ( documentation)

setting us up the bomb
This one little mashup is a pain in the asphalt really, but I’m leaving it here like this because it shows you the kind of work-arounds you have to figure out sometimes. At the moment of this writting, the vote nodes comming from the API have no created_at timestamp. The ticket has been issued and this API has or will probably be fixed by the time you read this but nonetheless: we need a pubDate in order to generate a somewhat valid feed. So Using the Date builder normally, we loop through the items’ created_at properties and filter them through the date builder to make sure they’re pipes compliant, and we then check that if the value is empty, we set a default hardcoded date set wayyy in the future for the heck of it.
Sources::Item Builder ( documentation)

The Finishing Touch!
- title: We map the title we’ve built earlier
- description: We map the description we’ve built earlier
- y:published: This is what translates best into a RSS pubDate through the pipe’s internals (it appears)
- link: The “permalink” to the RSS entry
- y:location.lat & y:location.lon: You set these up with some geographic coordinates if you want to generate a YAHOO map in the end.
April 24th, 2009 at 4:48 pm
[...] Piping your API not considered harmful. A detailed post about combining the power of Yahoo Pipes with API outputs (or own in this example). [...]